This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS
- From: "corsepiu at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Nov 2004 15:02:33 -0000
- Subject: [Bug regression/18643] [3.4 Regression] fixincludes breaks RTEMS
- References: <20041124041207.18643.corsepiu@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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