Re: Getting glibfortran to build on newlib targets aka. missing stdint.h (PR 14325)

[Zack Weinberg <zack at codesourcery dot com>]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> We do need better tracking of which fixes are actually being used, on what 
> systems.  Perhaps the instructions for sending build status reports should 
> be changed to include sending some file fixincludes is made to create with 
> a list of the fixes that got used and on what headers.

Yes, that sounds like a good idea.

> va_list is the most problematic case in general, given that for ISO
> C <stdio.h> must use the type (under some other name) but not define
> it, while SUS requires <stdio.h> to define it.  Fixing systems not
> to define it unconditionally in <stdio.h> is something I do think we
> should get out of, as providing <stdio.h> has not traditionally been
> something we do; it's ensuring the correct type, in the presence of
> <stdio.h> that might define it itself under some reserved name
> rather than deferring to the system's <stdarg.h>, that's the problem.

I wonder if we can figure out a way to make __builtin_va_list
type-compatible with the private definition, as long as it really is
the appropriate definition - the underlying form is specified by the
ABI, so normally it ought to be, and if it isn't we have bigger
problems.

(I'm not sure exactly what notion of type compatibility would be
required here.)

zw