[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS

["joel at oarcorp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joel at oarcorp dot com  2004-11-24 15:50 -------
Subject: Re:  [3.4 Regression] fixincludes breaks RTEMS

corsepiu at gcc dot gnu dot org wrote:
> ------- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-24 15:02 -------
> (In reply to comment #1)
> 
>>Nothing in fixincludes look wrong.  The new fixincludes do not apply to
> 
> limits.h at all.
> 
> But the old one probably did. The limits.h gcc-3.4 < 2004-11-17 produced,
> contains fragments of limitx.h, which I presume to be having been added by
> fixincludes and friends.
> 
> 
>>Does this work on the mainline,
> 
> I don't know, it's been a while since mainline built successfully for me.
> Yesterday's mainline did not build at all.
> 
> 
>>I assume so as HP could build MMIX just recently, earlier today.
>>Are you sure that this is not a newlib bug but then again HP built MMIX with
> 
> the combined tree.
> 
> I would not want to exclude this possibility. Throughout the years, there
> repeatedly had been issues with RTEMS/newlib's limits.h.
> 
> Also, note: RTEMS limits.h-machinery is not identical with generic newlib's
> limits.h machinery. RTEMS has custom limits.h and syslimits.h in newlib's sources.
> 
> Furthermore, diffing the gcc-sources didn't reveal anything obivous.
> 
> However, I noticed the following when diffing my build-logs:
> 
> @@ -10319,7 +10327,7 @@
>  chmod a+r include/syslimits.h)
>  Fixing headers into
> /users/rtems/src/rpms/BUILD/rtems-4.7-avr-rtems4.7-gcc-newlib-gcc3.4.4newlib1.12.0/build/gcc/include
> for avr-unknown-rtems4.7 target
>  echo timestamp > stmp-fixinc
> -if true ; then \
> +if [ -f
> /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.4/../../../../avr-rtems4.7/sys-include/limits.h
> ] ; then \
>    cat ../../gcc-3.4.4/gcc/limitx.h ../../gcc-3.4.4/gcc/glimits.h
> ../../gcc-3.4.4/gcc/limity.h > tmp-xlimits.h; \
>  else \
>    cat ../../gcc-3.4.4/gcc/glimits.h > tmp-xlimits.h; \
> 
> So the actual question is:
> What has set LIMITS_H_TEST to "true" before, and why isn't it set true anymore?

gcc/config/t-rtems in gcc 3.3.5 and the version on the 3.4 branch are 
the same example the 3.3.5 version has this:

# RTEMS uses newlib which does not require prototype fixing
STMP_FIXPROTO =

There was a patch about 15 months ago moving that logic
to config.gcc.  Is fixproto being set to yes somehow in
config.gcc for avr-rtems?  Do you have a special stanza
in your config.gcc for that target that is not checked in?
The checked in source only has avr-*-* and ends up setting
fixproto=yes.

That would explain this.  Does this happen on other targets?

--joel


> I am seeing further substancial differences in the build-log, but the diff above
> seems to be the origin of this breakdown.
> 




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18643