This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Getting glibfortran to build on newlib targets aka. missing stdint.h (PR 14325)
"Joseph S. Myers" <joseph@codesourcery.com> writes:
...
>
> This makes sense to me for <limits.h> and <stdint.h> at least (subject of
> course to it working with glibc's <limits.h> which for GCC expects to get
> the standard limits from GCC's header, but will use #include_next if it
> somehow gets included first). <stdbool.h> is a header unlikely to cause
> problems either way; likewise <iso646.h>; as the standard defines their
> contents exactly and the only GCC-specific thing is how C++ is handled.
> <stdarg.h> and <stddef.h> have GCC-specific contents. It also makes
> fairly clear, regarding the suggestion that was made to include
> <tgmath.h>, that the proper place for <tgmath.h> would be include-fixed,
> i.e. it is a fix if the library doesn't provide a suitable header.
>
> <float.h> is an interesting case where some systems define FLT_ROUNDS to
> call a function to determine the current rounding mode - but while that's
> something we don't want to lose and do lose at present, the headers may
> well need fixing to add the C99 definitions they may not have.
>
> Any change to the strategy for these headers will need thorough testcases
> that the headers used - both hosted and freestanding - follow the relevant
> standards.
Where the C library provides a version of a given header, I don't
think we should force that header to conform. As long as GCC is
itself a conforming freestanding implementation (when used in that
mode), as long as the combination of gcc and glibc is a conforming
hosted implementation, and as long as it is possible (via clear
documentation and cooperation with maintainers of free C libraries)
for gcc to be used as one component of a hosted implementation whose
other components are not from GNU, I think we have fulfilled our
obligations.
In particular I do not think we should fix a non-C99 conformant
system-provided float.h, and I am dubious about continuing to
enable glibc to provide an incomplete limits.h.
I agree that stdbool.h and iso646.h are unlikely to cause trouble
either way, but I would still put them in include-freestanding,
allowing a C library to override. And I'd like it to be possible to
put stddef.h there too.
zw