Some probably fixincludes-related change between 2004-11-17 and 2004-11-23 on has broken gcc-3.4-branch for all RTEMS-targets and may-be for all newlib-based targets in general. Unlike before 2004-11-23, now bootstrapping GCC-3.4.x + newlib one-tree style, produces a limits.h that is unusable for RTEMS. This is the diff between the limits.h from of GCC-3.4.4pre (2004-11-23) and a GCC-3.4.4pre (2004-11-17) toolchains: diff -u \ /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.4/include/limits.h \ /opt/rtems-4.7/lib/gcc/m68k-rtems4.7/3.4.4/include/limits.h --- /opt/rtems-4.7/lib/gcc/avr-rtems4.7/3.4.4/include/limits.h 2004-11-23 19:10:36.000000000 +0100 +++ /opt/rtems-4.7/lib/gcc/m68k-rtems4.7/3.4.4/include/limits.h 2004-11-18 06:39:55.000000000 +0100 @@ -1,3 +1,15 @@ +/* This administrivia gets added to the beginning of limits.h + if the system has its own version of limits.h. */ + +/* We use _GCC_LIMITS_H_ because we want this not to match + any macros that the system's limits.h uses for its own purposes. */ +#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */ +#define _GCC_LIMITS_H_ + +#ifndef _LIBC_LIMITS_H_ +/* Use "..." so that we find syslimits.h only in this same directory. */ +#include "syslimits.h" +#endif #ifndef _LIMITS_H___ #define _LIMITS_H___ @@ -101,3 +113,13 @@ #endif #endif /* _LIMITS_H___ */ +/* This administrivia gets added to the end of limits.h + if the system has its own version of limits.h. */ + +#else /* not _GCC_LIMITS_H_ */ + +#ifdef _GCC_NEXT_LIMITS_H +#include_next <limits.h> /* recurse down to the real one */ +#endif + +#endif /* not _GCC_LIMITS_H_ */ As it seems to me, before this change, fixincludes was run, and now it doesn't seem to be run anymore. AFAIK, theoretically newlib targets are supposed not to require running fixincludes, so a bug that might have been present before might have been fixed and now might break newlib for RTEMS.
Nothing in fixincludes look wrong. The new fixincludes do not apply to limits.h at all. These were the only changes on the 3.4 branch: 2004-11-21 Roger Sayle <roger@eyesopen.com> * fixinc/inclhack.def (alpha_pthread_init): Fix technical problems with the last check-in caused by CVS variable substitution. * fixinc/fixincl.x: Likewise. * fixinc/tests/base/pthread.h: Likewise. 2004-11-21 Roger Sayle <roger@eyesopen.com> Bruce Korb <bkorb@gnu.org> Synchronize with mainline * fixinc/inclhack.def (alpha_pthread_init): New fix. * fixinc/fixincl.x: Regenerate. * fixinc/tests/base/pthread.h: Update for new test. 2004-11-17 Ramana Radhakrishnan <ramana.radhakrishnan@codito.com> PR target/18263 * config/arc/lib1funcs.asm (___umulsidi3): Change use of cmp to the equivalent on the A4. Does this work on the mainline, 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.
(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? I am seeing further substancial differences in the build-log, but the diff above seems to be the origin of this breakdown.
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. >
(In reply to comment #3) >> So the actual question is: >>What has set LIMITS_H_TEST to "true" before, and why isn't it set true >> anymore? I believe to have found the cause (testing is still in progress). LIMITS_H_TEST is being set true in config/t-rtems, but a typo in my patch has prevented config/t-rtems from being picked up (cf. below). > Is fixproto being set to yes somehow in > config.gcc for avr-rtems? Yes, there is a second, bogus use_fixproto for avr-*-* in config.gcc. I'll propose it to be removed, soon. > Do you have a special stanza > in your config.gcc for that target that is not checked in? No, the versions I was comparing actually were my local version before having commited the patch and the version after I commited the patch. However, this hint was the key to the cause: A typo had crept into the patch I had checked in (tmake_files= instead of tmake_file=), probably having crept in when having transferred the patch from my testing cvs-tree (with further patche s applied) to my submission cvs-tree.
Patches applied to gcc-3_4-branch and CVS-trunk.