In http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01345.html there are treelang test suite failures like this: Test Run By chj on Mon Jul 25 03:19:50 2005 Native configuration is sparc64-unknown-linux-gnu === treelang tests === Schedule of variations: unix/-m64 unix Running target unix/-m64 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /usr/local/src/branch/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/compile.exp ... set_ld_library_path_env_vars: ld_library_path=:/usr/local/src/branch/objdir/gcc:/usr/local/src/branch/objdir/gcc/64 set_ld_library_path_env_vars: ld_library_path=.::/usr/local/src/branch/objdir/gcc:/usr/local/src/branch/objdir/gcc/64 Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree -S -m64 -o autofunc.s (timeout = 9000) /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0: error: -mlong-double-64 not allowed with -m64 compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0: error: -mlong-double-64 not allowed with -m64 FAIL: treelang/compile/autofunc.tree (test for errors, line 2) FAIL: treelang/compile/autofunc.tree (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0: error: -mlong-double-64 not allowed with -m64 Maybe a mulitlib problem hitting only 4.0 branch and not mainline...
$(DRIVER_DEFINES) needs to be added to when compiling spec.c.
(In reply to comment #1) > $(DRIVER_DEFINES) needs to be added to when compiling spec.c. Would that be done in gcc/Makefile.in or does such a thing belong to gcc/treelang/Make-lang.in?
gcc/treelang/Make-lang.in
I don't think treelang had it's own driver in 4.0.
uhm... well, what needs to be added to what then in treelang/Make-lang.in? btw, the 4.0 branch's variant does not differ that much from trunk... there's a toplev.h difference... and a gcc version in texi...
Created attachment 9439 [details] Copy stuff from gfortran's makefile Please try this patch.
well, applied it to mainline, no problema caused... however, the bug was reported for the 4.0 branch... applying there "Hunk #1 succeeded at 114 with fuzz 1." will test later today, resources bound today, yay, football (or, if you like, soccer) with my sons
(In reply to comment #7) > yay, football (or, if you like, soccer) with my sons It is football, Americans don't know what they are missing.
I here murderball is a real sport up there with Aussie rules football.
bugger, it didn't work for the 4.0 branch... this is from the build log file.... does the patch look correctly applied to you? (SHLIB_LINK=' ./xgcc -B./ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -L/usr/local/src/branch/objdir/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=@shlib_base_name@.so.1 -Wl,--version-script=@shlib_map_file@ -o @multilib_dir@/@shlib_base_name@.so.1.tmp @multilib_flags@ @shlib_objs@ -lc && rm -f @multilib_dir@/@shlib_base_name@.so && if [ -f @multilib_dir@/@shlib_base_name@.so.1 ]; then mv -f @multilib_dir@/@shlib_base_name@.so.1 @multilib_dir@/@shlib_base_name@.so.1.backup; else true; fi && mv @multilib_dir@/@shlib_base_name@.so.1.tmp @multilib_dir@/@shlib_base_name@.so.1 && ln -s @shlib_base_name@.so.1 @multilib_dir@/@shlib_base_name@.so' \ SHLIB_MULTILIB=''; \ stage2/xgcc -Bstage2/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/usr/local/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.0.2\" -DDEFAULT_TARGET_MACHINE=\"sparc64-unknown-linux-gnu\" -DSTANDARD_BINDIR_PREFIX=\"/usr/local/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB_LINK}" = "X" || test "yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = "X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \ -I. -Itreelang -I../../gcc/gcc -I../../gcc/gcc/treelang -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include ../../gcc/gcc/treelang/spec.c -o treelang/spec.o) stage2/xgcc -Bstage2/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H -o gtreelang treelang/spec.o \ gcc.o version.o prefix.o intl.o ../libcpp/libcpp.a ../libiberty/libiberty.a
This turns out to be a dup of bug 20604 which is already fixed for 4.1.0. Since this is not a regression and treelang should only be really working on the mainline as it is an example front-end, I am just going to close this as a dup of bug 20604. *** This bug has been marked as a duplicate of 20604 ***