* Using glibc headers with non-GCC compilers which define _Float32 etc.
@ 2023-04-03 8:07 Florian Weimer
2023-04-03 8:43 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2023-04-03 8:07 UTC (permalink / raw)
To: libc-alpha
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using glibc headers with non-GCC compilers which define _Float32 etc.
2023-04-03 8:07 Using glibc headers with non-GCC compilers which define _Float32 etc Florian Weimer
@ 2023-04-03 8:43 ` Andreas Schwab
2023-04-03 9:03 ` Florian Weimer
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2023-04-03 8:43 UTC (permalink / raw)
To: Florian Weimer via Libc-alpha; +Cc: Florian Weimer
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."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using glibc headers with non-GCC compilers which define _Float32 etc.
2023-04-03 8:43 ` Andreas Schwab
@ 2023-04-03 9:03 ` Florian Weimer
2023-04-03 9:10 ` Andreas Schwab
0 siblings, 1 reply; 5+ messages in thread
From: Florian Weimer @ 2023-04-03 9:03 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Florian Weimer via Libc-alpha
* 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using glibc headers with non-GCC compilers which define _Float32 etc.
2023-04-03 9:03 ` Florian Weimer
@ 2023-04-03 9:10 ` Andreas Schwab
2023-04-03 9:54 ` Florian Weimer
0 siblings, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2023-04-03 9:10 UTC (permalink / raw)
To: Florian Weimer; +Cc: Florian Weimer via Libc-alpha
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."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Using glibc headers with non-GCC compilers which define _Float32 etc.
2023-04-03 9:10 ` Andreas Schwab
@ 2023-04-03 9:54 ` Florian Weimer
0 siblings, 0 replies; 5+ messages in thread
From: Florian Weimer @ 2023-04-03 9:54 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Florian Weimer via Libc-alpha
* 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-04-03 9:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-03 8:07 Using glibc headers with non-GCC compilers which define _Float32 etc Florian Weimer
2023-04-03 8:43 ` Andreas Schwab
2023-04-03 9:03 ` Florian Weimer
2023-04-03 9:10 ` Andreas Schwab
2023-04-03 9:54 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).