I realize that, but what I'm saying is that right now, the build
enviornment ITSELF can't be built with gcc 4.0. I'm not interested in
upgrading the target compiler yet, rather, I can no longer build the
tools like the target compiler anymore because gcc 4.0 won't build
gcc 3.3.
I'm not complaining, mind you, just reporting the facts:
gcc 4.0 will not build binutils 2.14 but does build 2.16.1 fine
gcc 4.0 will not build gcc 3.3 (have not investigated further)
This is going to be a bit of a support issue moving forward, so it would
be a good thing (tm) to add support for alternate versions of the host
compiler in your makefiles (HOST compiler, not TARGET compiler), -or-
upgrade our build environment to not include code that doesn't break in
gcc 4.0 (either by switching the target compiler to something newer, or
by just fixing line 653 in read-rtl.c of gcc 3.3.3. Right now, when
buildtool bootstraps itself, it assumes the host compiler is just "gcc"
-- it would be nice if we could specify something trivial to buildtool
to run gcc-3.4 instead.
FWIW, this appears to possibly be a bug in gcc 4.0:
gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I.
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/.
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/config
-I/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/../include
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c
-o read-rtl.o
In file included from
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:24:
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/rtl.h:132:
warning: type of bit-field 'code' is a GCC extension
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/rtl.h:135:
warning: type of bit-field 'mode' is a GCC extension
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:
In function 'fatal_with_file_and_line':
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:53:
warning: traditional C rejects ISO C style function definitions
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:
In function 'read_rtx':
/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-3.3.3/gcc/read-rtl.c:653:
error: invalid lvalue in increment
make[2]: *** [read-rtl.o] Error 1
make[2]: Leaving directory
`/home/pst/bering-uclibc/buildtool/source/buildenv/gcc-initial/gcc'
make[1]: *** [all-gcc] Error 2
case 'E':
{
/* Obstack to store scratch vector in. */
struct obstack vector_stack;
int list_counter = 0;
rtvec return_vec = NULL_RTVEC;
c = read_skip_spaces (infile);
if (c != '[')
fatal_expected_char (infile, '[', c);
/* add expressions to a list, while keeping a count */
obstack_init (&vector_stack);
while ((c = read_skip_spaces (infile)) && c != ']')
{
ungetc (c, infile);
list_counter++;
obstack_ptr_grow (&vector_stack, (PTR) read_rtx (infile));
}
if (list_counter > 0)
{
return_vec = rtvec_alloc (list_counter);
memcpy (&return_vec->elem[0], obstack_finish (&vector_stack),
list_counter * sizeof (rtx));
}
XVEC (return_rtx, i) = return_vec;
obstack_free (&vector_stack, NULL);
/* close bracket gotten */
}
break;
Line 653 is the call to obstack_ptr_grow, it really is a function,
as is read_rtx, so I don't see an lvalue to increment. The previous
line, list_counter's increment, is just an int.
Sigh.
Paul
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
------------------------------------------------------------------------
leaf-user mailing list: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/
