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