Re: LTO branch merged into trunk - trunk remains CLOSED
On Sun, Oct 4, 2009 at 3:45 AM, Ryan Hill wrote: > On Sat, 3 Oct 2009 17:12:17 -0400 > Diego Novillo wrote: > >> Instructions on how to enable LTO support are described in the >> manual. The following is a summary: >> >> - Install libelf 0.8.12+ (http://www.mr511.de/software/libelf-0.8.12.tar.gz) >> Other versions of libelf are commonly installed in Linux >> distros. Unfortunately, libelf implementations vary in >> annoying ways and they are not all compatible. The libelf >> version in Fedora 11 works fine, however. > > I just did a build and found that LTO was enabled due to elfutils-0.143 being > installed. Do you know if elfutils is a suitable replacement for libelf or > if it will cause issues down the line? elfutils works fine for me. Richard.
Error when building cross compiler
I am getting the following error when compiling "x86_64 to powerpc64"
cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc
directory.
...
# Now that we have built all the objects, we need to copy
# them back to the GCC directory. Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
make install-leaf DESTDIR=../.././gcc \
slibdir= libsubdir= MULTIOSDIR=.
make[5]: Entering directory
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgcc'
/bin/bash ../../../src/libgcc/../mkinstalldirs ../.././gcc
/usr/bin/install -c -m 644 libgcc_eh.a ../.././gcc/
chmod 644 ../.././gcc/libgcc_eh.a
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ranlib
../.././gcc/libgcc_eh.a
/bin/bash ../../../src/libgcc/../mkinstalldirs ../.././gcc;
/usr/bin/install -c -m 644 ./libgcc_s.so.1 ../.././gcc/libgcc_s.so.1;
rm -f ../.././gcc/libgcc_s.so; ln -s libgcc_s.so.1
../.././gcc/libgcc_s.so
/bin/bash ../../../src/libgcc/../mkinstalldirs ../.././gcc
/usr/bin/install -c -m 644 libgcc.a ../.././gcc/
chmod 644 ../.././gcc/libgcc.a
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ranlib
../.././gcc/libgcc.a
/usr/bin/install -c -m 644 libgcov.a ../.././gcc/
chmod 644 ../.././gcc/libgcov.a
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/ranlib
../.././gcc/libgcov.a
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o ecrti.o
ecrtn.o ncrti.o ncrtn.o"; \
for file in $parts; do \
rm -f ../.././gcc/$file; \
/usr/bin/install -c -m 644 $file ../.././gcc/; \
done
make[5]: Leaving directory
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgcc'
make[4]: Leaving directory
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgcc'
Checking multilib configuration for libgomp...
mkdir -p -- powerpc64-unknown-linux-gnu/libgomp
Configuring in powerpc64-unknown-linux-gnu/libgomp
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... powerpc64-unknown-linux-gnu
checking target system type... powerpc64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for powerpc64-unknown-linux-gnu-strip...
/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/strip
checking for powerpc64-unknown-linux-gnu-gcc...
/a/linux/.powerpc/gcc/obj/./gcc/xgcc
-B/a/linux/.powerpc/gcc/obj/./gcc/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/lib/
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/include
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/sys-include
checking for C compiler default output file name... configure: error:
in `/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgomp':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[3]: *** [configure-target-libgomp] Error 1
make[3]: Leaving directory `/a/linux/.powerpc/gcc/obj'
The obj/powerpc64-unknown-linux-gnu/libgomp/config.log content is:
...
configure:2569: checking for C compiler default output file name
configure:2572: /a/linux/.powerpc/gcc/obj/./gcc/xgcc
-B/a/linux/.powerpc/gcc/obj/./gcc/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/bin/
-B/a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/lib/
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/include
-isystem /a/linux/.powerpc/cross-tools/powerpc64-unknown-linux-gnu/sys-include
-g -O2 conftest.c >&5
/a/linux/.powerpc/gcc/obj/./gcc/cc1: error while loading shared
libraries: /a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1: ELF file
data encoding not little-endian
configure:2575: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "GNU OpenMP Runtime Library"
| #define PACKAGE_TARNAME "libgomp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "libgomp"
| #define VERSION "1.0"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2613: error: in
`/a/linux/.powerpc/gcc/obj/powerpc64-unknown-linux-gnu/libgomp':
configure:2616: error: C compiler cannot create executables
See `config.log' for more details.
...
It seems that host cc1 executable tries to load target libgcc_s.so.1
from obj/gcc directory, rather than host libgcc_s.so.1 from /lib. The
message "error while loading shared libraries:
/a/linux/.powerpc/gcc/obj/./gcc/libgcc_s.so.1: ELF file data encoding
not little-endian" is from glibc.
Is this a bug ? And are there any workarounds ?
RE: Lattice Mico32 port
Hi Richard, >> Index: gcc/config/lm32/sfp-machine.h >> Index: gcc/config/lm32/crti.S >> Index: gcc/config/lm32/lib1funcs.S >> Index: gcc/config/lm32/crtn.S >> Index: gcc/config/lm32/arithmetic.c >> Index: gcc/config/lm32/t-fprules-softfp >> Index: gcc/config/lm32/t-lm32 > >Can you move these to libgcc? The rules in libgcc/Makefile.in use $(gcc_srcdir) (E.g. for targets lib1asmfuncs-o). How would you suggest I do this? Cheers, Jon
Re: i370 port - constructing compile script
Paul Edwards wrote: > I'm not sure whether to call MVS a target or host. Maybe it helps to take a step back and look at how the process of initially getting a compiler for a system B built, starting on an existing system A, usually works. Each of the following steps can be identified by three systems: - the "build" system (where the compiler build process runs) - the "host" system (where the resulting compiler will run) - the "target" system (where executables built by that compiler run) Using this terminology, we need the following four stages: (In your case, A would be "Linux on Intel", and B would be "MVS".) 1. build == A, host == A, target == A This is the compiler you start out with, a native compiler for the A system. (You already have that, you do not need to rebuild it.) 2. build == A, host == A, target == B This is a cross-compiler for B, running on A, which is itself built on A using the compiler from 1. 3. build == A, host == B, target == B This is a native B compiler, but it is *built* on A, using the A->B cross-compiler from 2. (This way of building a compiler is sometimes refered to as a "Canadian cross".) 4. build == B, host == B, target == B This step is optional, but using the native B compiler from 3., you could now rebuild the compiler once again, this time on B itself. At this point, B is fully supported and able to bootstrap its compiler without any assistance from another system. As there is nothing to do for step 1, and step 4 is optional, the interesting parts are steps 2 and 3. These are two separate build steps, targeting different host systems to run the resulting compiler on. As the properties of the host system (e.g. does it have "fork" or "getrusage" or whatever) are detected at build time during the "configure" step, you need to have a separate configure run for step 2 and step 3. Note that configure works but attempting to compile and/or link small test programs. In step 2, configure will use the host A compiler (from step 1) to do these trial compiles. The host A compiler will use the host A header files and libaries, and thus configure will detect properties of system A (which is correct, as in step 2, "host" == A). In step 3, configure will use the A->B cross-compiler (from step 2) to do the trial compiles. This compiler, if built correctly, will use host *B* header files and libraries from its sysroot, and thus configure will detect properties of system *B* (which again is correct, as in step 3, "host" == B). >From the symptoms you describe, it would appear that you're picking up bad configure results in step 3. Depending on what exactly you do, this might be either because you don't actually re-run configure but attempt to use the configure results from step 2 (that certainly cannot work), or else your step 2 cross-compiler was itself built incorrectly in some form so it doesn't properly pick up headers from its sysroot, or else the headers in the sysroot are simply incorrect ... You should investigate the various log files left by configure to figure out what's going on. Note that one problem might be that your step 2 cross-compiler cannot actually link executables as it is missing the cross-linker required to do so. I *think* the core GCC (C-only) configure process should be able to handle this, but I might be mistaken here. I'm not sure if this helps, but I hope this might have at least clarified a bit some of the terminology being used ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Trunk is closed for LTO merge
I wrote: [T]omorrow I plan to svn up my gcc trunk, recompile it for C and Fortran, recompile our Weather Forecasting system with it, and see what happens (the compile of the Weather code doesn't use -flto yet, obviously. I did so, svn up'd to revision 152437. The build (with --with-libelf=/usr/local pointing to my private installation of libelf 0.8.12 in preference of Debian Testing's libelf 0.8.10) successfully compiled all of HIRLAM (see http://hirlam.org). The forecast that's now running behaves normally, so compiling this code without -flto certainly works. PR 41566 (which is probably related to PR 41521, as noted by Richard Guenther) points at some code of ours that doesn't yet compile with -flto. Kind regards, and thanks to all involved with this effort ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Re: [PATCH] Adjust develop.html to reflect recent practice
On Sun, 27 Sep 2009, Richard Guenther wrote: > Ok with me. Applied now. Gerald
Re: gcc mirror in Bangalore, India
On Sat, 3 Oct 2009, Vineet Dwivedi wrote: >> Hi, We have hosted gcc mirror at the following location >> >> http://mirror.vocabbuilder.net/gnu/gcc/ >> >> Request you to include this in your list of mirrors. My contact details are >> in the signature below. Thanks, Vineet. The mirror list we maintain at http://gcc.gnu.org/mirrors.html carries those mirrors that specifically mirror our FTP server, including snap- shots. In your case it seems you are mirroring ftp.gnu.org, so my recommendation is getting listed as a mirror there (and we refer to the ftp.gnu.org mirrors from our mirrors page, too). Gerald
Re: OpenMP 3.0 libgomp ABI documentation for TASK construct
Hi Tim, > From gcc online docs (http://gcc.gnu.org/onlinedocs/libgomp/), I found > documentations for most of OpenMP constructs, except one very > important construct TASK. I cannot answer this. It may be that the documentation was written before tasks (which were introduced in a latter version of OpenMP) were added to GCC OpenMP. > > I don't know why it is missing, but I really > need to find out how TASK get transformed into GOMP_* routines. I > posted this question before, but haven't got a reply yet. I am very > grateful if someone can point me to the right track. For example, is > there a pretty-print feature of the AST after processing the OpenMP > pragmas? If so, how? Of course, if someone have the expertise, and > directly show me how TASK get transformed, it would be even better! For the pretty print, just use -fdump-tree-ompexp-all on the compile line and look for the file *.c.*ompexp that is generated. It contains the dump just after OpenMP expansion. If you need to check out the code generation routines by yourself, take a look at gcc/omp-low.c Most of everything happens there. There are two passes, OpenMP lowerring then expansion. The generation of the GOMP_* routine calls happens during expansion pass and so you should start from the "expand_omp_taskreg" function (in gcc/omp-low.c). Best, Antoniu
Re: i370 port - constructing compile script
In step 3, configure will use the A->B cross-compiler (from step 2) to do the trial compiles. This compiler, if built correctly, will use host *B* header files and libraries from its sysroot, and thus configure will detect properties of system *B* (which again is correct, as in step 3, "host" == B). From the symptoms you describe, it would appear that you're picking up bad configure results in step 3. Depending on what exactly you do, this might be either because you don't actually re-run configure but attempt to use the configure results from step 2 (that certainly cannot work), or else your step 2 cross-compiler was itself built incorrectly in some form so it doesn't properly pick up headers from its sysroot, or else the headers in the sysroot are simply incorrect ... You should investigate the various log files left by configure to figure out what's going on. Thanks for the explanation Ulrich. I was previously under the impression (my interpretation of the documentation) that I just needed to do one configure, and it would do both of the steps you mentioned. Note that one problem might be that your step 2 cross-compiler cannot actually link executables as it is missing the cross-linker required to do so. I *think* the core GCC (C-only) configure process should be able to handle this, but I might be mistaken here. Would you be able to give me the two suggested configure commands so that I can find out the answer to the above, one way or another? Perhaps if that bit fails I will need to replace the cross-compiler and cross-linker with normal gcc during the configure process, and only give it access to some C90 libraries. It so happens that I have a full suite of those, but even if I didn't, I could create a dummy printf etc so that it would at least link. Or does the configure process attempt to run the executables as well? No mind - as I said, I have the full suite for a configure to work. But it won't be able to correctly determine the stack direction if it does that. So that is the sort of thing I would need some intrusive code (out of my 20 lines quota!) to force it to 0 (unknown stack direction). Thanks. Paul.
gcc-4.3-20091004 is now available
Snapshot gcc-4.3-20091004 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20091004/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 152438 You'll find: gcc-4.3-20091004.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20091004.tar.bz2 C front end and core compiler gcc-ada-4.3-20091004.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20091004.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20091004.tar.bz2 C++ front end and runtime gcc-java-4.3-20091004.tar.bz2 Java front end and runtime gcc-objc-4.3-20091004.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20091004.tar.bz2The GCC testsuite Diffs from 4.3-20090927 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: ext/profile/mh.cc compile error on darwin
On Sat, Oct 03, 2009 at 10:40:06PM -0400, Jack Howarth wrote:
> Silvius,
>The ext/profile/mh.cc test case is failing to compile on *-*-darwin* due
> to the error...
>
> /sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:24:20:
> fatal error: malloc.h: No such file or directory
>
> This test case should be including stdlib.h rather than malloc.h as has been
> done in the past...
>
> * rts.c: Get malloc() from , not .
>
> Thanks in advance for fixing this.
>Jack
I am finding that with...
Index: testsuite/ext/profile/mh.cc
===
--- testsuite/ext/profile/mh.cc (revision 152438)
+++ testsuite/ext/profile/mh.cc (working copy)
@@ -21,7 +21,7 @@
// { dg-do compile }
#include
-#include
+#include
#include
using std::vector;
on x86_64-apple-darwin10, the compile error changes to...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/./gcc
-nostdinc++
-L/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/x86_64-apple-darwin10.0.0/i386/libstdc++-v3/src
-L/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/x86_64-apple-darwin10.0.0/i386/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.5/x86_64-apple-darwin10.0.0/bin/
-B/sw/lib/gcc4.5/x86_64-apple-darwin10.0.0/lib/ -isystem
/sw/lib/gcc4.5/x86_64-apple-darwin10.0.0/include -isystem
/sw/lib/gcc4.5/x86_64-apple-darwin10.0.0/sys-include -m32 -g -O2
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-g -O2 -DLOCALEDIR="." -nostdinc++
-I/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/x86_64-apple-darwin10.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.0.0
-I/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/x86_64-apple-darwin10.0.0/i386/libstdc++-v3/include
-I/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/util
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc
-D_GLIBCXX_PROFILE -S -m32 -o mh.s(timeout = 600)
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:
In function 'void my_init_hook()':
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:40:21:
error: '__malloc_hook' was not declared in this scope
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:
In function 'void* my_malloc_hook(size_t, const void*)':
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:48:3:
error: '__malloc_hook' was not declared in this scope
compiler exited with status 1
output is:
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:
In function 'void my_init_hook()':
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:40:21:
error: '__malloc_hook' was not declared in this scope
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:
In function 'void* my_malloc_hook(size_t, const void*)':
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:48:3:
error: '__malloc_hook' was not declared in this scope
FAIL: ext/profile/mh.cc (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:40:21:
error: '__malloc_hook' was not declared in this scope
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:48:3:
error: '__malloc_hook' was not declared in this scope
extra_tool_flags are:
-D_GLIBCXX_DEBUG -D_GLIBCXX_PROFILE
Any ideas on what is wrong here (or is this test simply glibc-centric)?
Jack
