[Cfp-interest] Fwd: interchange types, equivalence, basic types

[Jim Thomas]

On Mar 13, 2013, at 3:04 PM, Ian McIntosh <ianm at ca.ibm.com> wrote:

> What we talked about earlier wrt types being equivalent was that it would act as if:
> 
> The _Float32, _Float64 and other optional types like _Float16, _Float128, _Float32x, _Float64x, etc. would be treated by the compiler as built in types.
> The type float would be treated the same as a typedef to a built in type, normally _Float32.
> The type double would be treated the same as a typedef to a built in type, normally _Float64.
> The type long double would be treated the same as a typedef to a built in type, normally one of _Float64 or _Float64x or _Float128.
> 
> I don't think we resolved all the issues and I'm not sure we adopted that approach.

Right, we knew that adding types would have to be done carefully but (at least some of us) weren't clear on what all the issues were.

> 
> One concern is that as mentioned if long double and double are both typedefs to _Float64 then all three become the same type.  Another is that programs could be nonportable because of implied multiple definitions.  Maybe a "weak typedef" is needed, where they are not the same type but conversions between them are automatic, free and unrestricted.
> 
> An alternative is for them to be separate types with identical implementations including size, layout, endianess, library functions, etc.

I believe this is the approach finally proposed below.

-Jim

> 
> - Ian McIntosh          IBM Canada Lab         Compiler Back End Support and Development
> 
> 
> <graycol.gif>Jim Thomas ---03/12/2013 02:18:35 PM---Begin forwarded message: > From: Jim Thomas <jaswthomas at sbcglobal.net>
> 
> <ecblank.gif>
> From:
> <ecblank.gif>
> Jim Thomas <jaswthomas at sbcglobal.net>
> <ecblank.gif>
> To:
> <ecblank.gif>
> CFP <cfp-interest at ucbtest.org>
> <ecblank.gif>
> Date:
> <ecblank.gif>
> 03/12/2013 02:18 PM
> <ecblank.gif>
> Subject:
> <ecblank.gif>
> [Cfp-interest] Fwd: interchange types, equivalence, basic types
> <ecblank.gif>
> Sent by:
> <ecblank.gif>
> cfp-interest-bounces at oakapple.net
> 
> 
> 
> 
> 
> Begin forwarded message:
> From: Jim Thomas <jaswthomas at sbcglobal.net>
> Subject: interchange types, equivalence, basic types 
> Date: March 12, 2013 11:16:23 AM PDT
> To: Joseph S. Myers <jsm at polyomino.org.uk>
> Cc: SC22 WG14 <sc22wg14 at open-std.org>
> 
> 
> On Mar 7, 2013, at 11:53 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> …
> On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <jsm at polyomino.org.uk> wrote:
> ...
> * There are references to such things as _Float32 being equivalent to 
> float.  What does "equivalent" mean here?  The types could be the same 
> type (like "long" and "long int").  They could be compatible types (like 
> "int" and an enum for which the implementation-defined compatible integer 
> type is int), but not the same.  They could be distinct (like "char" and 
> "unsigned char", even if char is unsigned) but have the same 
> representation and alignment.  Or one might imagine float having one 
> endianness and _Float32 the other (both being binary32); is that intended 
> to be ruled out?
> 
> If various possibilities for whether types are the same / compatible / 
> distinct but with the same values and (apart maybe from bit ordering) 
> representation are intended to be allowed, I think the TS should make 
> clear exactly what possibilities are permitted, rather than just using a 
> vague "equivalent".
> 
> Their being the same type seems most direct. A possible problem is that this might allow more mixing of type nomenclatures and result in more confusing code. Also, if double and _Float64 were the same type and long double and _Float64 were the same type, then double and long double would be the same type, though they aren't.
> 
> 
> Is there any reason to require a stricter sense of "equivalence" than in the following?
> 
> An implementation that defines __STDC_IEC_60559_BFP__ shall provide:
>  _Float32 and _Float64 as interchange floating types with the same representation and alignment requirements as float and double, respectively
>  _Float16 as a data-interchange type
> and may provide:
> _Float16 as an interchange floating type
> 
> If the implementation’s long double type supports an IEC 60559 interchange format of width N, then the implementation shall provide the type _FloatN as an interchange floating type with the same representation and alignment requirements as long double.
> 
> 
> ...
> 
> * Are all the new types basic / fundamental types, so that malloc must 
> return memory suitably aligned for them (see my reflector message 12832 on 
> 9 Jan for more on the issues there)?  C11 6.2.5#14 says "The type char, 
> the signed and unsigned integer types, and the floating types are 
> collectively called the basic types.", leaving open the question of 
> whether data interchange types are also basic types.
> 
> Issue: how to assure that malloc can handle data-interchange types.
> 
> 
> Any problem with including data-interchange types as basic types?
> 
> The type char, the signed and unsigned integer types, the floating types, and the data-interchange types are collectively called the basic types.
> 
> 
> -Jim Thomas
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20130313/6861b125/attachment.html