------- 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
