Using glibc headers with non-GCC compilers which define _Float32 etc.

Using glibc headers with non-GCC compilers which define _Float32 etc.

[Florian Weimer]

We have a downstream bug that points out that if __GNUC__ is not
defined, glibc assumes that it's necessary to define _Float32 as a
typedef to float:

  glibc: _FloatN and _FloatNx problem if _GNUC__ is not defined
  <https://bugzilla.redhat.com/show_bug.cgi?id=2183212>

That does not work if the compiler already defines _Float32.

What should we do about this?  The suggestion to provide the definition
for __STDC_WANT_IEC_60559_TYPES_EXT__ requires additional glibc header
file changes, I think.  Other headers assume that _Float32 is available,
one way or another, and if __STDC_WANT_IEC_60559_TYPES_EXT__ is defined
and the compiler does not _Float32 (say Clang, or old GCC), then those
headers will break.

Thanks,
Florian

Re: Using glibc headers with non-GCC compilers which define _Float32 etc.

[Andreas Schwab]

On Apr 03 2023, Florian Weimer via Libc-alpha wrote:

> We have a downstream bug that points out that if __GNUC__ is not
> defined, glibc assumes that it's necessary to define _Float32 as a
> typedef to float:
>
>   glibc: _FloatN and _FloatNx problem if _GNUC__ is not defined
>   <https://bugzilla.redhat.com/show_bug.cgi?id=2183212>
>
> That does not work if the compiler already defines _Float32.
>
> What should we do about this?

I don't think we should support that use case.  It's probably not the
only thing that will break in this situation.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Using glibc headers with non-GCC compilers which define _Float32 etc.

[Florian Weimer]

* Andreas Schwab:

> On Apr 03 2023, Florian Weimer via Libc-alpha wrote:
>
>> We have a downstream bug that points out that if __GNUC__ is not
>> defined, glibc assumes that it's necessary to define _Float32 as a
>> typedef to float:
>>
>>   glibc: _FloatN and _FloatNx problem if _GNUC__ is not defined
>>   <https://bugzilla.redhat.com/show_bug.cgi?id=2183212>
>>
>> That does not work if the compiler already defines _Float32.
>>
>> What should we do about this?
>
> I don't think we should support that use case.  It's probably not the
> only thing that will break in this situation.

The -U__GNUC__ option is just a shortcut for reproduction.  I think the
fundamental issue is that our headers do not work if the compiler does
not define __GNUC__, but predefines types like _Float32.  I think our
goal is to support non-GCC compilers, so this seems to be fairly broken.
It also blocks defining _Float32 et al. in Clang.

Thanks,
Florian

Re: Using glibc headers with non-GCC compilers which define _Float32 etc.

[Andreas Schwab]

On Apr 03 2023, Florian Weimer wrote:

> The -U__GNUC__ option is just a shortcut for reproduction.  I think the
> fundamental issue is that our headers do not work if the compiler does
> not define __GNUC__, but predefines types like _Float32.

That's a different case.  We should identify those specific compilers,
and adjust the expression accordingly.  But we can only support
compilers that we can identify.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Using glibc headers with non-GCC compilers which define _Float32 etc.

[Florian Weimer]

* Andreas Schwab:

> On Apr 03 2023, Florian Weimer wrote:
>
>> The -U__GNUC__ option is just a shortcut for reproduction.  I think the
>> fundamental issue is that our headers do not work if the compiler does
>> not define __GNUC__, but predefines types like _Float32.
>
> That's a different case.

It's what I wanted to discuss, per the subject line.

> We should identify those specific compilers, and adjust the expression
> accordingly.  But we can only support compilers that we can identify.

That's a reasonable position.  I'll try to figure out which compiler
this is actually about.

Thanks,
Florian