Bug 2183212
| Summary: | glibc: _FloatN and _FloatNx problem if _GNUC__ is not defined | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Paulo Andrade <pandrade> |
| Component: | glibc | Assignee: | glibc team <glibc-bugzilla> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-tools-bugs |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.7 | CC: | ashankar, codonell, dj, fweimer, mnewsome, pbhosale, pfrankli, sipoyare, tuliom |
| Target Milestone: | rc | Keywords: | Bugfix, Triaged |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-04-24 10:35:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
__STDC_WANT_IEC_60559_TYPES_EXT__ does not seem to be quite the right macro here. I expect this to cause problems elsewhere, particularly with -D_GNU_SOURCE or with Clang. I think we need a way to override the type availability check that's not dependent on GCC versions. It's going to be cumbersome to use. Basically, the user will have to define macros for all built-in compiler types. As a workaround, the customer can probably use additional macro definitions like -D_Float32=_Float32_renamed etc. to hide the GCC-defined type, or use Clang, which does not define _Float32 yet. Raised this on libc-alpha: Using glibc headers with non-GCC compilers which define _Float32 etc. <https://sourceware.org/pipermail/libc-alpha/2023-April/146861.html> Upstream suggests that we should enable support for compilers on a case-by-case basis. If the customer has a compiler that does not work due to this (and they used -U__GNUC__ with GCC just to demonstrate the issue), we should fix that upstream and consider a backport. If they want to use -U__GNUC__ to test compatibility with hypothetical compilers that do not define __GNUC__, I think they need to use one of the workarounds I suggested. We do not consider this a bug. As explained, building with -U__GNUC__ with a compiler that defines the _Float* types (such as GCC itself) is not supported. There are no plans to change that upstream or downstream. If this causes compatibility issues with a specific compiler, we can fix the glibc headers upstream to recognize that compiler (like it presently recognizes GCC). But this requires information about the specific compiler for which header file support is requested. The customer has a workaround, so I'm closing this bug. |
Sample reproducer: $ cat > test.c <<EOF #include <stdio.h> #include <stdlib.h> void foo(void) { } EOF $ gcc -c -U__GNUC__ test.c User wants to preprocess source files with __GNUC__ undefined. Ignoring possible ABI or unrelated issues, maybe a good approach would be to change /usr/include/bits/floatn-common.h from: # if !__GNUC_PREREQ (7, 0) || defined __cplusplus typedef float _Float32; # endif to: # if (!__GNUC_PREREQ (7, 0) && __STDC_WANT_IEC_60559_TYPES_EXT__) || defined __cplusplus typedef float _Float32; # endif or similar pattern as appropriate. Quoting https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/compilers-and-development-tools_considerations-in-adopting-rhel-8 """ The _FloatN and _FloatNx type names specified by the ISO/IEC TS 18661-3:2015 standard are now recognized by the C front end. """