Based on the comment in stdc-predef.h, somebody apparently assumed __STDC_IEC_559_COMPLEX__ means the implementation supports complex arithmetic. This is not what it means. Complex arithmetic is mandatory in C99, and in C11 implementations that lack complex arithmetic must define __STDC_NO_COMPLEX__. The meaning of __STDC_IEC_559_COMPLEX__ is that the implementation conforms to Annex G, which among other things, requires the existence of the otherwise-optional _Imaginary types which GCC does not support. This is a fairly serious issue for applications, since on an implementation conforming to Annex G, I*INFINITY is interpreted as intended, whereas on an implementation lacking _Imaginary types and defining I as _Complex_I, I*INFINITY results in a NAN due to the 0*INFINITY term.
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). The main issue with implementing _Imaginary support in GCC would be avoiding the ABI mess that arose from supporting complex numbers on all targets without any thought about what the ABIs for argument passing and return should be. That is, it would be appropriate to disable it except for targets enabling it by a target hook that means any necessary target-specific ABI work has been done including coordinating with anyone 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.)
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.
On Sat, 6 Jul 2013, bugdal at aerifal dot cx 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? Not much good. You can't use __STDC_VERSION__ in practice to tell what level of C11 features is supported, can't use __STDC__ to tell if trigraphs are supported, and to the extent that you can use __STDC_VERSION__ as an indication of availability of various C99 features (albeit language features only, not library features even when defined together with __STDC_HOSTED__), it took many years after compilers started having C99 modes for there to be a reasonable consensus on a common subsets of C99 features you could expect to be supported in such a mode (which doesn't include anything from Annex F or Annex G, or UCNs in identifiers, for example). Such macros are only reliable for the standard-given semantics if the application knows it is being built by an implementation with some externally-given conformance statement covering the implementation as a whole (compiler and library) (at which point they may be used to identify which conformance options are in use). For normal compilations with implementations documented not to implement everything in the standard, the macros may be of heuristic value but may also need using together with external information about particular implementations, or information obtained from autoconf configure tests. > > 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. Of course the ABI could be defined to promote it, though I think it would make more sense not to promote it - but the fact there is a reasonable choice about the ABI in this area is sufficient reason why the "you" deciding what choice to make needs to be the ABI maintainers (or in the absence of such ABI maintainers, any de facto group that coordinates ABI issues between implementations (the ia32-abi Google Group in the case of 32-bit x86 ELF, for example)) rather than one implementor. Just look at the 32-bit Power Architecture ABI (unified version - "Power Architecture(R) 32-bit Application Binary Interface Supplement 1.0 - Linux & Embedded") for the complexities of how complex types are handled (complete with two different ABI options for them in the EABI case, matching different implementations) for what you get if you let the ABI just be what happens by chance on a particular architecture for a particular implementation without anything actually thinking about or coordinating things on a per-architecture basis.
On Sun, Jul 07, 2013 at 04:21:04PM +0000, joseph at codesourcery dot com wrote: > Not much good. You can't use __STDC_VERSION__ in practice to tell what > level of C11 features is supported, Combined with the other new __STDC_NO_*__ macros introduced in C11, you should be able to determine which features are available. > can't use __STDC__ to tell if > trigraphs are supported, This is a bug in GCC, but anybody using trigraphs intentionally or otherwise should just be taken out back anyway... Anyway, the definition of the __STDC_IEC_559_COMPLEX__ macro is just misleading and wrong, so I think this should be fixed. Defining it does not provide anything of value, and does cause problems for applications.
On Sun, 7 Jul 2013, bugdal at aerifal dot cx wrote: > > Not much good. You can't use __STDC_VERSION__ in practice to tell what > > level of C11 features is supported, > > Combined with the other new __STDC_NO_*__ macros introduced in C11, > you should be able to determine which features are available. No, because the set of macros for optional features doesn't correspond at all to the various subsets of C11 features that may or may not be implemented in compilers' C11 modes. Wait five or ten years and C11 modes may be more reliably more complete. Your "should" is only for applications known to be compiled only with compilers and libraries documented to conform in the relevant ways, not for real-world partial C11 support. > > can't use __STDC__ to tell if trigraphs are supported, > > This is a bug in GCC, but anybody using trigraphs intentionally or > otherwise should just be taken out back anyway... It's a deliberate choice dating back (and documented) to GCC 2.0 at least that __STDC__ does not reflect whether a strict conformance mode is selected.
As discussed, this macro is being defined to indicate intent rather than completeness, just like __STDC_VERSION__, and can only be interpreted as referring to completeness in the presence of external conformance documentation asserting conformance for an implementation as a whole (and if such an implementation asserted conformance for the GCC/glibc combination in a mode where this macro is defined, that would be a bug in that external documentation). After my commit 1484e65736f4cab27e5051e0f06be8470e69af82, the comment explicitly refers to intent.