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

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

[bugdal at aerifal dot cx]

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

            Bug ID: 15720
           Summary: stdc-predef.h wrongly defines __STDC_IEC_559_COMPLEX__
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
                CC: drepper.fsp at gmail dot com

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.

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

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

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
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.)

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

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

[bugdal at aerifal dot cx]

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.

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

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
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.

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

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

[bugdal at aerifal dot cx]

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

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
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.

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

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

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
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.

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

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

[jsm28 at gcc dot gnu.org]

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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
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.

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

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

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

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

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