<html><body>
<p><font size="2" face="sans-serif">What we talked about earlier wrt types being equivalent was that it would act as if:</font>
<ol type="1" style="padding-left: 18pt">
<li><font size="2" face="sans-serif">The _Float32, _Float64 and other optional types like _Float16, _Float128, _Float32x, _Float64x, etc. would be treated by the compiler as built in types.</font>
<li><font size="2" face="sans-serif">The type float would be treated the same as a typedef to a built in type, normally _Float32.</font>
<li><font size="2" face="sans-serif">The type double would be treated the same as a typedef to a built in type, normally _Float64.</font>
<li><font size="2" face="sans-serif">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.</font></ol>
<br>
<font size="2" face="sans-serif">I don't think we resolved all the issues and I'm not sure we adopted that approach.</font><br>
<br>
<font size="2" face="sans-serif">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.</font><br>
<br>
<font size="2" face="sans-serif">An alternative is for them to be separate types with identical implementations including size, layout, endianess, library functions, etc.</font><br>
<br>
<font size="2" face="sans-serif">- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development<br>
</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for Jim Thomas ---03/12/2013 02:18:35 PM---Begin forwarded message: > From: Jim Thomas <jaswthomas@sbcglo"><font size="2" color="#424282" face="sans-serif">Jim Thomas ---03/12/2013 02:18:35 PM---Begin forwarded message: > From: Jim Thomas <jaswthomas@sbcglobal.net></font><br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">From:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">Jim Thomas <jaswthomas@sbcglobal.net></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">To:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">CFP <cfp-interest@ucbtest.org></font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Date:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">03/12/2013 02:18 PM</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Subject:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">[Cfp-interest] Fwd: interchange types, equivalence, basic types</font></td></tr>
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Sent by:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1BEDFE45B838f9e8a93df938@ca.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">cfp-interest-bounces@oakapple.net</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<br>
<br>
<font size="3" face="serif">Begin forwarded message:</font><br>
<ul style="padding-left: 36pt"><font size="3" face="serif"><b>From: </b></font><font size="3" face="serif">Jim Thomas <</font><a href="mailto:jaswthomas@sbcglobal.net"><font size="3" color="#0000FF" face="serif"><u>jaswthomas@sbcglobal.net</u></font></a><font size="3" face="serif">></font><br>
<font size="3" face="serif"><b>Subject: interchange types, equivalence, basic types </b></font><br>
<font size="3" face="serif"><b>Date: </b></font><font size="3" face="serif">March 12, 2013 11:16:23 AM PDT</font><br>
<font size="3" face="serif"><b>To: </b></font><font size="3" face="serif">Joseph S. Myers <</font><a href="mailto:jsm@polyomino.org.uk"><font size="3" color="#0000FF" face="serif"><u>jsm@polyomino.org.uk</u></font></a><font size="3" face="serif">></font><br>
<font size="3" face="serif"><b>Cc: </b></font><font size="3" face="serif">SC22 WG14 <</font><a href="mailto:sc22wg14@open-std.org"><font size="3" color="#0000FF" face="serif"><u>sc22wg14@open-std.org</u></font></a><font size="3" face="serif">></font><br>
<br>
<br>
<font size="3" face="serif">On Mar 7, 2013, at 11:53 AM, Jim Thomas <</font><a href="mailto:jaswthomas@sbcglobal.net"><font size="3" color="#0000FF" face="serif"><u>jaswthomas@sbcglobal.net</u></font></a><font size="3" face="serif">> wrote:</font><br>
<font size="3" face="serif"><br>
…</font><br>
<ul style="padding-left: 36pt"><font size="3" face="serif">On Mar 6, 2013, at 2:36 PM, Joseph S. Myers <</font><a href="mailto:jsm@polyomino.org.uk"><font size="3" color="#0000FF" face="serif"><u>jsm@polyomino.org.uk</u></font></a><font size="3" face="serif">> wrote:<br>
</font>
<ul style="padding-left: 36pt"></ul>
</ul>
<font size="3" face="serif">...</font>
<ul style="padding-left: 72pt"><font size="3" face="serif">* There are references to such things as _Float32 being equivalent to <br>
float. What does "equivalent" mean here? The types could be the same <br>
type (like "long" and "long int"). They could be compatible types (like <br>
"int" and an enum for which the implementation-defined compatible integer <br>
type is int), but not the same. They could be distinct (like "char" and <br>
"unsigned char", even if char is unsigned) but have the same <br>
representation and alignment. Or one might imagine float having one <br>
endianness and _Float32 the other (both being binary32); is that intended <br>
to be ruled out?</font></ul>
<ul style="padding-left: 36pt">
<ul style="padding-left: 36pt"><font size="3" face="serif"><br>
If various possibilities for whether types are the same / compatible / <br>
distinct but with the same values and (apart maybe from bit ordering) <br>
representation are intended to be allowed, I think the TS should make <br>
clear exactly what possibilities are permitted, rather than just using a <br>
vague "equivalent".</font></ul>
<font size="3" face="serif"><br>
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.<br>
<br>
</font></ul>
<br>
<font size="3" face="serif">Is there any reason to require a stricter sense of "equivalence" than in the following?</font><br>
<br>
<font size="3" face="serif">An implementation that defines __STDC_IEC_60559_BFP__ shall provide:</font>
<ul type="disc" style="padding-left: 36pt">
<li><font size="3" face="serif"> _Float32 and _Float64 as interchange floating types with the same representation and alignment requirements as float and double, respectively</font>
<li><font size="3" face="serif"> _Float16 as a data-interchange type</font></ul>
<font size="3" face="serif">and may provide:</font><br>
<ul type="disc" style="padding-left: 36pt">
<li><font size="3" face="serif">_Float16 as an interchange floating type</font></ul>
<br>
<font size="3" face="serif">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.</font><br>
<br>
<font size="3" face="serif"><br>
...</font>
<ul style="padding-left: 72pt"><font size="3" face="serif"><br>
* Are all the new types basic / fundamental types, so that malloc must <br>
return memory suitably aligned for them (see my reflector message 12832 on <br>
9 Jan for more on the issues there)? C11 6.2.5#14 says "The type char, <br>
the signed and unsigned integer types, and the floating types are <br>
collectively called the basic types.", leaving open the question of <br>
whether data interchange types are also basic types.</font></ul>
<ul style="padding-left: 36pt"><font size="3" face="serif"><br>
Issue: how to assure that malloc can handle data-interchange types.<br>
<br>
</font></ul>
<br>
<font size="3" face="serif">Any problem with including data-interchange types as basic types?</font><br>
<br>
<font size="3" face="serif">The type char, the signed and unsigned integer types, the floating types, and the data-interchange types are collectively called the basic types.</font><br>
<br>
<br>
<font size="3" face="serif">-Jim Thomas</font></ul>
<tt><font size="2">_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<br>
</font></tt><tt><font size="2"><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a></font></tt><tt><font size="2"><br>
</font></tt><br>
<br>
</body></html>