[Cfp-interest 1916] Fwd: (SC22WG14.18893) fabs, copysign, representations and N2651

[Jim Thomas]

I’ll add this to the CFP Feb agenda.

- Jim Thomas

> Begin forwarded message:
> 
> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: Re: (SC22WG14.18893) fabs, copysign, representations and N2651
> Date: February 13, 2021 at 11:06:04 AM PST
> To: Joseph Myers <joseph at codesourcery.com>, Martin Uecker <Martin.Uecker at med.uni-goettingen.de>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> 
> 
>> On Feb 12, 2021, at 11:49 PM, Uecker, Martin <Martin.Uecker at med.uni-goettingen.de <mailto:Martin.Uecker at med.uni-goettingen.de>> wrote:
>> 
>> 
>> Am Freitag, den 12.02.2021, 23:50 +0000 schrieb Joseph Myers:
>>> N2651 proposes a requirement, in Annex F, that fabs and copysign preserve 
>>> all bits of the representation of a value except for the sign bit.  There 
>>> are some issues with this requirement:
>>> 
>>> * It's stronger than IEEE 754 requires.  
> 
> The purpose of the change was to match the IEEE 754 requirement.
> 
>>> Recall that "representation" in 
>>> ISO C is equivalent to "encoding" in IEEE 754; noncanonical encodings are 
>>> considered the same representation as the canonical encoding in IEEE 754, 
>>> but are different representations in ISO C.  IEEE 754 says these 
>>> operations *may* propagate non-canonical encodings; the proposed ISO C 
>>> wording would require such encodings to be propagated.  
> 
> IEEE 754 says of these operations: "they only affect the sign bit”. I understand this to mean that other bits in the bit encoding are unchanged, IEEE 754 does says they "may propagate non-canonical encodings”. I think this is not well stated, but is intended to distinguish these operations among computational operations which "generally produce only canonical significands”, and is not intended to specify an implementation option. 
> 
>>> (Likewise, 
>>> "representation" in IEEE 754 only distinguishes qNaN from sNaN rather than 
>>> distinguishing different payloads.  As a quality-of-implementation matter 
>>> it seems desirable for these operations to preserve payloads, but that's 
>>> not required by IEEE 754.)
> 
>>> 
>>> * In ISO C, "representation" includes padding bits, but operations 
>>> changing values should never be required to preserve padding bits.  
>>> Although the IEEE 754 interchange formats don't typically have padding 
>>> bits, the common x86 extended-precision format typically has padding bits 
>>> in memory but not in registers (meaning it's not practical for these 
>>> operations to preserve the value of padding bits).
> 
> The IEEE 754 encoding applies to what might be called the value bits in the C object representation. The requirement to only affect the sign bit means not to affect the other encoding (value) bits. This says nothing about padding bits.
>> 
>> Generally, a representation is the property of an object in
>> storage with a certain type. A type is a the set of possible
>> values. During lvalue conversion the representation is read
>> and converted to a value. At this time only the value can
>> matter anymore.*
>> 
>> Thus, if a value is passed to a function the representation
>> of the object must be irrelevant.
> 
>> A function that wants to
>> operate on the representation of an object must take a
>> pointer to the object.
>> 
> 
> I’ll add this, and Joseph’s points above, to the CFP agenda for this coming week.
> 
> Thank you both for checking this.
> 
> - Jim  Thomas
> 
>> 
>> 
>> This is how it works in theory and the C standard follows
>> this concept consistenly almost everywhere as far as I can
>> see.  There is only one exception: We define "indeterminate
>> value" to be "either an unspecified value or a 
>> trap representation"   This does not make any sense as
>> only objects have a representation and consequently causes
>> a lot of confusion.
>> 
>> 
>> Best,
>> Martin