This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/15720] stdc-predef.h wrongly defines __STDC_IEC_559_COMPLEX__


http://sourceware.org/bugzilla/show_bug.cgi?id=15720

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
On Sat, Jul 06, 2013 at 08:58:24PM +0000, joseph at codesourcery dot com wrote:
> I think this is no different from defining __STDC__ in GCC's default mode,
> or defining __STDC_VERSION__ to indicate the selected standards mode
> rather than to indicate full conformance to a particular standard version.
> That is, it indicates intent rather than completeness (for example,
> special cases of functions try to follow Annex G).

I disagree with this assessment. There's a big difference between
minor conformance errors (like excess ulps of error) and omitting
required types that make a valid Annex G program into a compile-time
constraint violation. If applications can't rely on the absence of
this macro to tell them _Imaginary is definitely not available, what
good is the macro?

> The main issue with implementing _Imaginary support in GCC would be 
> avoiding the ABI mess that arose from supporting complex numbers on all 

Complex numbers are already supported. Imaginary types have the exact
same representation as their corresponding real floating point types,
so they're much easier to support than complex types. Your explanation
for why GCC does not support them does not make sense. If GCC does add
imaginary type support, it should not be target-specific.

> responsible for the architecture ABI definition.  (Saying that imaginary 
> types are passed like the corresponding real types is a tempting default - 
> except that float _Imaginary does *not* promote to double _Imaginary when 
> passed in variable arguments, so an unpromoted float _Imaginary could be 
> passed there where an unpromoted float never could.)

I wasn't aware of this issue, but I don't think it matters. There's no
reason from an ABI standpoint why you can't promote it, as long as
va_arg, when passed _Imaginary float as the type, knows to perform the
actual read as _Imaginary double instead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]