This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]