Fix NetBSD native bootstrap

Hi folks,

This is a third try to fix trunk native boostrap. PR concerning this issue
are summerized in PR/38182 and PR/43952.

This issue is due to several NetBSD `machine/ansi.h' (i386, amd64, as Ralf
mentionned, but also landisk, hpcsh, dreamcast and evbsh3) not defining the
expected _ANSI_H_ or _MACHINE_ANSI_H_.

For this patch I implemented Joseph S. Myers suggestion to define USER_H in
config/t-netbsd. This may be cleaner than the last patch in PR/38182 which
affect all target. In the mean time, I removed other headers the base system is
providing. stdarg.h is still needed because the host stdarg.h still reference
the old __builtin_stdarg_start(). stdfix.h is missing from the base system, so I
kept it in the include list.

Bootstrapped on i386-unknown-netbsdelf5.99.25, regression tests pending.

2010-12-09 - Arnaud Lacombe <lacombar@gmail.com>

	* config/t-netbsd: Set USER_H.

CC: tech-toolchain@netbsd.org
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>

---
 gcc/config/t-netbsd |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

On Wed, 8 Dec 2010, Arnaud Lacombe wrote:

> For this patch I implemented Joseph S. Myers suggestion to define USER_H in
> config/t-netbsd. This may be cleaner than the last patch in PR/38182 which
> affect all target. In the mean time, I removed other headers the base system is
> providing. stdarg.h is still needed because the host stdarg.h still reference
> the old __builtin_stdarg_start(). stdfix.h is missing from the base system, so I
> kept it in the include list.
> 
> Bootstrapped on i386-unknown-netbsdelf5.99.25, regression tests pending.

You'll want to check those results carefully for any conformance test 
(gcc.dg/c[91]*) failures indicating header problems.  In particular, the 
testsuite verifies that C1X definitions are present in <float.h>; if they 
aren't present on NetBSD you'll want to keep GCC's <float.h> or fix 
NetBSD's with fixincludes.

If you always wish to use NetBSD's <stdint.h>, then the default 
use_gcc_stdint=none in config.gcc will work but you'll need to add 
configuration information to the compiler to tell it about the <stdint.h> 
types for all the c99-stdint-*.c tests to pass (this is needed for the 
Fortran C bindings, in particular); see 
<http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html> and PR 448.  This is 
best done as a separate patch.

Hi,

On Thu, Dec 9, 2010 at 6:47 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 8 Dec 2010, Arnaud Lacombe wrote:
>
>> For this patch I implemented Joseph S. Myers suggestion to define USER_H in
>> config/t-netbsd. This may be cleaner than the last patch in PR/38182 which
>> affect all target. In the mean time, I removed other headers the base system is
>> providing. stdarg.h is still needed because the host stdarg.h still reference
>> the old __builtin_stdarg_start(). stdfix.h is missing from the base system, so I
>> kept it in the include list.
>>
>> Bootstrapped on i386-unknown-netbsdelf5.99.25, regression tests pending.
>
> You'll want to check those results carefully for any conformance test
> (gcc.dg/c[91]*) failures indicating header problems.  In particular, the
> testsuite verifies that C1X definitions are present in <float.h>; if they
> aren't present on NetBSD you'll want to keep GCC's <float.h> or fix
> NetBSD's with fixincludes.
>
This definitively introduced regressions, I guess I'll split the
original patch, one addressing the bootstrap issue and one eventually
using more system provided header. What would be the better way to
proceed ? keep using gcc's headers or fixing the system one, by either
fixing that upstream or through fixincludes ?

Thanks,
 - Arnaud

On Thu, 9 Dec 2010, Arnaud Lacombe wrote:

> This definitively introduced regressions, I guess I'll split the
> original patch, one addressing the bootstrap issue and one eventually
> using more system provided header. What would be the better way to
> proceed ? keep using gcc's headers or fixing the system one, by either
> fixing that upstream or through fixincludes ?

Using GCC's own headers is definitely the safer approach as they will be 
updated as needed for new language features supported by GCC.  (My 
comments about USER_H in one of the PRs you referenced were to the effect 
that *if* you use the system headers in place of GCC's *then* USER_H is 
the way to do so - but making GCC's headers work for your target is still 
generally the safer approach that won't involve ongoing cost every time 
GCC's headers are updated, such as float.h was for C1X.)