[Bug c/108531] New: Imaginary types are not supported, violating ISO C Annex G

[Bug c/108531] New: Imaginary types are not supported, violating ISO C Annex G

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

            Bug ID: 108531
           Summary: Imaginary types are not supported, violating ISO C
                    Annex G
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

#include <stdio.h>
#include <complex.h>
int main(void) {
#ifdef __STDC_IEC_559_COMPLEX__
    printf("__STDC_IEC_559_COMPLEX__ is defined as %d\n",
__STDC_IEC_559_COMPLEX__);
#else
    printf("__STDC_IEC_559_COMPLEX__ is NOT defined\n");
#endif

#ifdef _Imaginary_I
    printf("Imaginary types are supported\n");
#else
    printf("Imaginary types are NOT supported\n");
#endif
}

The output of this program, when compiled with
"gcc -Wall -Wextra -std=c11 -pedantic-errors"
is:

__STDC_IEC_559_COMPLEX__ is defined as 1
Imaginary types are NOT supported

ISO C Annex G was informative in C99, but was made normative in C11. 
Imaginary types are optional in C11, but are mandatory for any
implementation that predefines __STDC_IEC_559_COMPLEX__.
(Complex types were made optional in C11, but that's not relevant here.)

To conform to C11 (and later), gcc should either implement imaginary types
as defined in Annex G or remove the definition of __STDC_IEC_559_COMPLEX__.

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #1 from Keith Thompson <Keith.S.Thompson at gmail dot com> ---
After I submitted this, I found that this is probably a duplicate of:

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

(I disagree with the resolution of that bug report.)

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C2x changes this ... (so does TS 18661-1 ) so ....

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #3 from Keith Thompson <Keith.S.Thompson at gmail dot com> ---
In the latest C2X draft,
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
Annex G still requires imaginary number support for any implementation
that defines __STDC_IEC_60559_COMPLEX__ or __STDC_IEC_559_COMPLEX__.

I don't see anything relevant in TS 18661-1
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2314.pdf

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #4 from Sam James <sam at gentoo dot org> ---
LLVM side: https://github.com/llvm/llvm-project/issues/60269

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[Keith.S.Thompson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #5 from Keith Thompson <Keith.S.Thompson at gmail dot com> ---
FYI, I've sent an email to the C standard editors (the addresses at
the top of the N3054 draft) suggesting that imaginary number support
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60559_COMPLEX__ are defined.

It's probably too late to make such a change in C23.

(__STDC_IEC_60559_COMPLEX__ is replacing __STDC_IEC_559_COMPLEX__,
which is obsolescent.)

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
My only real addition to my previous comments in the referenced glibc bug 
report is that, given we defined _Float32 which has the same "not promoted 
at language level in variable arguments" property as _Imaginary float and 
let it have the ABI arising naturally from the back ends in the absence of 
target maintainers / ABI maintainers choosing something different, it 
would probably be reasonable to do the same thing for imaginary types; 
this case is rather different from _BitInt where there are significant ABI 
choices to be made for each architecture (and I've filed bugs on various 
ABI repositories to request that such ABIs be defined).  It would be good 
if psABI maintainers kept up more with C standard features, however.