This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Getting glibfortran to build on newlib targets aka. missing stdint.h (PR 14325)
"Joseph S. Myers" <joseph@codesourcery.com> writes:
> On Sun, 7 Nov 2004, Zack Weinberg wrote:
>
>> In particular I do not think we should fix a non-C99 conformant
>> system-provided float.h, and I am dubious about continuing to
>
> If we don't fix it, then we regress in that regard. Now, I follow a very
> wide definition of what counts as a regression, but the fix is at least a
> simple one of adding
>
> #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> #undef FLT_EVAL_METHOD
> #define FLT_EVAL_METHOD __FLT_EVAL_METHOD__
> #endif
>
> to a system float.h that doesn't define FLT_EVAL_METHOD, and likewise for
> DECIMAL_DIG.
I construe this as papering over a bug in the C library in question,
and therefore not a regression if we stop doing it. That's not a
reason _to_ stop doing it, though.
As we've been discussing off-list, all else being equal it is
desirable to edit as few library-provided headers as possible, because
fixincludes edits are inherently fragile, and because it interferes with
changes to that C library after GCC is installed (e.g. the well-known
inability to use a gcc installation built against Solaris 2.x after a
system upgrade to 2.(x+1)). This I do think is a reason not to mess
with a library-provided float.h.
> The problem with <stddef.h> is really the definition of offsetof, though
> the C++ definition of NULL to __null comes into things as well, since by
> design our types should always agree with those of the system header.
Here's a half-baked idea for dealing with this. Suppose we add to
cpplib a notion of built-in invisible macros. These have the
following semantics:
1) Before an explicit #define of the macro in question, the macro is
not expanded.
2) An explicit #define is compared against the invisible definition,
in a manner similar to what we do now with an explicit declaration
of a built-in function. However, the invisible definition
overrides the explicit one if they don't match - with a warning,
which is suppressed in system headers as usual.
3) In order not to drive people nuts trying to debug, -save-temps/-E
prints out the invisible definition as a #define, with a comment
reading "definition overridden by intrinsic", at the point where
-dD would have printed a #define line for the explicit definition
if it hadn't been overridden. (These will be silently ignored by
-fpreprocessed mode reread.)
We would need to be very careful with these; it'd be wrong to use them
for anything where the name-as-macro was not reserved by the C
standard, and it'd be wrong to use them except in cases where a
GCC-specific definition absolutely must be used. However, I think it
would correctly handle offsetof, NULL, and possibly va_*.
I'm not all that excited about this idea - perhaps it is best to
continue forcing everyone to use our stddef.h and stdarg.h.
zw