[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #41 from Ralf dot Wildenhues at gmx dot de 2010-06-02 17:40 --- Subject: Re: gcc 4.5 20100218 bootstrap compare fails on os x 10.6 * dominiq at lps dot ens dot fr wrote on Wed, Jun 02, 2010 at 07:09:42PM CEST: [macbook] f90/bug% gcc46 pthread_create.c [macbook] f90/bug% a.out ; echo $? 0 Is it the correct way to do the test? (so far I only got zeros). Well you could try ...prev-gcc/xgcc -B... instead; see your respective libgomp/config.log file, it lists the command line that is used for the test (search for thread-local storage). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2010-02-24 18:19 --- (In reply to comment #6) I think the key question here is whether it is possible to build/install a new version of GCC, getting the same directory layout as was the default in previous versions. It's OK if it takes command-line options, but I think it should be *possible*. If not, then I think it is a regression. I'm fairly certain that it is possible to get the old layout back using command-line options, but that, too, should be documented in changes.html (PR 43133). I'll try it to make sure, though, and report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2010-02-22 21:39 --- Not sure if this can be qualified a regression, but still, making a release manager aware of this can't hurt, I guess. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug other/43132] installation directory defaults do not match documentation, Coding Standards
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2010-02-23 06:01
---
Well, the GCS did change, and we did (mostly) update the default locations to
follow. However, as of now, the override methods don't all work the way the
configure --help output promises, and not all documentation gets put in
directories containing a coherent expansion of ${PACKAGE}.
Anyway, not marking this as regression then. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132
[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2009-12-05 18:20 --- Subject: Re: libtool fails to detect pe-x86-64 import library * ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:16:12PM CET: hmm, I still don't see in gcc's root in libtool.m4 the patch for detecting x64_64 archives. Did I miss here something? The patch in #1 is in ltmain.sh. Did you mean another patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
[Bug bootstrap/40972] libtool fails to detect pe-x86-64 import library
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2009-12-05 19:46 --- Subject: Re: libtool fails to detect pe-x86-64 import library * ktietz at gcc dot gnu dot org wrote on Sat, Dec 05, 2009 at 07:31:22PM CET: I meant in libtool.m4, too: We have here: mingw* | pw32*) if ( test $lt_cv_nm_interface = BSD nm file / ) /dev/null 21; then lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' lt_cv_file_magic_cmd='func_win32_libid' Well, if this needs changed, then please report it upstream on the bug-libtool list. I cannot test your system, so we rely on feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #14 from Ralf dot Wildenhues at gmx dot de 2009-10-05 05:16 --- Subject: Re: Can't build libgomp without --enable-languages=fortran * davek at gcc dot gnu dot org wrote on Wed, Sep 30, 2009 at 11:26:26PM CEST: --- Comment #13 from davek at gcc dot gnu dot org 2009-09-30 21:26 --- Created an attachment (id=18680) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18680action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18680action=view) bash -x log of configure script run Hmm, from that I can't gather what $GFORTRAN was set to from the toplevel. Do you have a global log? It should be sufficient to rm $target/libgomp/Makefile make configure-target-libgomp SHELL=/bin/sh\ -x Thanks, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2009-09-21 17:51 --- Subject: Re: Can't build libgomp without --enable-languages=fortran * davek at gcc dot gnu dot org wrote on Mon, Sep 21, 2009 at 07:44:49PM CEST: Created an attachment (id=18625) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18625action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18625action=view) bad rebuild log Can you attach the two respective config.log files, too, please? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug bootstrap/38591] erratic comparison failures on very fast machines
--- Comment #10 from Ralf dot Wildenhues at gmx dot de 2009-09-17 17:40 --- Subject: Re: erratic comparison failures on very fast machines * ebotcazou at gcc dot gnu dot org wrote on Thu, Sep 17, 2009 at 06:58:37PM CEST: No idea why the borked build does not fail but pick up auto-host.h from elsewhere or so. Or do you know for sure that auto-host.h was picked up from the current directory? Couldn't a truncated auto-host.h have been picked up? config.status uses mv from a temporary subdirectory to the final location of the file, thus create it created atomically. Autoconf 2.59 did this too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38591
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #14 from Ralf dot Wildenhues at gmx dot de 2009-04-14 21:50 --- Subject: Re: Bootstrapping libstdc++-v3 failed * dominiq at lps dot ens dot fr wrote on Sun, Apr 12, 2009 at 10:17:24AM CEST: Is comment #11 still true? No, I cannot reproduce it any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug target/36622] 4.3.1 failed to compile gcse.c file.
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2008-07-02 16:46 --- Subject: Re: 4.3.1 failed to compile gcse.c file. * imam dot toufique at intel dot com wrote on Wed, Jul 02, 2008 at 06:17:59PM CEST: well... when libstdc and other shared libs are built, are they all built position independent? Yes. the whole idea here to make sure that we must build position independent libstdc.so and other shared libs. But you need not take care of that. It's done without you passing -fPIC. The build machinery will do that for those objects that end up in shared libraries. Moreover, I have tested with the -fPIC options in 4.3.2 pre-release and the build works OK. That doesn't make it recommended practice. also, I am getting an error from 'ld' that it can't find symbol '-lc' . I am not sure if this gcc related or binutils related. any ideas? Please see comment #18 for more info. I assume that is an independent issue. But still you should first try to build without -fPIC. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36622
[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist
--- Comment #10 from Ralf dot Wildenhues at gmx dot de 2008-06-19 07:22 --- Subject: Re: make exit because build/genmodes.exe doesn't exist * laurent at guerby dot net wrote on Thu, Jun 19, 2008 at 08:29:14AM CEST: It happened to me but I found the source: if even once you did run configure in the source dir then even if after that you configure in a clean build dir you'll get this error. So the solution is to regenerate a clean source dir (either untar or svn co) and to absolutely avoid to configure in it, always configure in a build dir. In what way does this description differ from mine that I overlook? Maybe we should let toplevel configure check that, if a separate build tree is used, then $srcdir/host-$host_noncanonical may not exist. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
[Bug bootstrap/33781] [4.3/4.4 Regression] Arg list too long building libgcc.a
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2008-06-12 21:46 --- Subject: Re: [4.3/4.4 Regression] Arg list too long building libgcc.a * roger at eyesopen dot com wrote on Thu, Jun 12, 2008 at 11:31:02PM CEST: that we die just a little further on with a similar execvp: /bin/sh: Arg list too long. This second failure is where we run nm on all of the objects and pipe the results through mkmap-flat.awk to create tmp-libgcc.map. This should be fixable likewise. I will prepare a patch this weekend. (I can't test it reliably as the only IRIX system I have access to has its command line length limit lifted higher, and thus does not fail.) Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/33781] [4.3/4.4 Regression] Arg list too long building libgcc.a
--- Comment #18 from Ralf dot Wildenhues at gmx dot de 2008-06-09 08:33 --- AFAICS this bug has a workaround patch applied, and may be worked around by modifying IRIX default settings. Are you still interested in a proper fix that avoids manual chunking? It looks like the write_entries_to_file tricks in libjava/Makefile.am can be applied in this case as well. Should I look into it? -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist
--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-06-09 11:02 --- (In reply to comment #7) I am currently using GCC4.2.1 and the same problem still exist as described. [...] build/genmodes -h tmp-modes.h /bin/sh: build/genmodes: No such file or directory make[3]: *** [s-modes-h] Error 127 [...] Please advise on how to solve the above problem. Or is it a known bug? Have you ever started configure and make within the source tree? As as consequence of that, if the directory $top_srcdir/host-$host_noncanonical exists, then that would lead to the above error when later building outside of the source tree (replace the variables $top_srcdir and $host_noncanonical with whatever fits your setup, e.g., ../gcc-4.2.1/host-i686-pc-linux-gnu). A solution would be to remove that directory, then remove the build tree and start afresh. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
[Bug bootstrap/33781] [4.3/4.4 Regression] Arg list too long building libgcc.a
--- Comment #19 from Ralf dot Wildenhues at gmx dot de 2008-06-09 18:41 --- Created an attachment (id=15743) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15743action=view) patch to build libraries piecewise This patch assumes that libgcc_eh.a is the only one of the three libraries whose list of objects may be empty. If that assumption is false, then the other *-objects need to be defaulted as well (but in that case the original rules had a race condition, not guarding against eh_dummy.[co] being created concurrently). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug middle-end/36213] Wrong search path generation
--- Comment #10 from Ralf dot Wildenhues at gmx dot de 2008-05-23 15:25 --- The --enable-version-specific-runtime-libs bit of this bug report is a duplicate of PR32415 -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:00 --- (In reply to comment #1) Is that a clean build? The symbol is new and I think sometimes dependencies don't get updated fine. I saw that one at some point, but a clean build made it disappear. Next time you see such an issue, can you please try to note as many details as possible, open a PR and Cc: me? I can only see that happening with --enable-maintainer-mode and then the rebuild rules not finding appropriate autotools versions. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36120
[Bug libfortran/36120] selected_char_kind_1.f90 undefined reference with -m32
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-05-06 12:14 --- Subject: Re: selected_char_kind_1.f90 undefined reference with -m32 * fxcoudert at gcc dot gnu dot org wrote on Tue, May 06, 2008 at 02:08:59PM CEST: I can only see that happening with --enable-maintainer-mode and then the rebuild rules not finding appropriate autotools versions. Hum, that was without --enable-maintainer-mode and manually running automake (but not autoconf or autoheader); maybe doing that is the mistake in itself :) If you're only modifying Makefile.am files, then running automake should be sufficient (except changes to ACLOCAL_AMFLAGS won't be picked up). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36120
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-04-25 12:05 --- Please post the link commands that expose the self reference (the libtool --mode=link stuff and whatever it generates). Also how exactly you configure GCC. Also please post cd $host/libstdc++-v3 ./libtool --tag=CXX --config Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #56 from Ralf dot Wildenhues at gmx dot de 2008-04-22 17:51 --- Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared * bonzini at gnu dot org wrote on Tue, Apr 22, 2008 at 08:27:07AM CEST: So I'm not yet convinced this particular race to be a Libtool bug. ... but you can assume it is created once and for all after it is built (something you can guarantee with Makefile rules). That's an invariant that libtool's relinking breaks, and that atomic operation would restore. OK, I understood the issue now. I'll fix Libtool. Thanks for explaining, and persevering. Another possibility would be to force libtool to relink at linking time, i.e. keep the fast install, but do the relinking even before the program is invoked (and the wrapper script installed). But I assume it is a mess? Yes, that sounds like a mess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #44 from Ralf dot Wildenhues at gmx dot de 2008-04-21 14:13 --- It is probably possible to generate the wrapper script atomically. But this solution can become ugly: on w32 we may generate also a wrapper executable. I still don't see a convincing argument why you don't use -no-fast-install. If the problem is that you don't like the relink to happen at 'make install' time, then why don't you generate two 'ld' programs, one for installation and one for use uninstalled, with -no-fast-install, or even -no-install. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #54 from Ralf dot Wildenhues at gmx dot de 2008-04-22 05:27 --- Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared * bonzini at gnu dot org wrote on Mon, Apr 21, 2008 at 04:39:20PM CEST: For win32 it suffices to: 1) create wrapper executable under random name 2) create wrapper script under random name 3) move wrapper script to correct name 4) move wrapper executable to correct name Probably. Libtool 2.2.2 has things changed there, and a couple of issues still, so I need to look at this anyway. (BTW, were you libtool maintainers aware of this race/these races?) I wasn't. But I don't think we guarantee atomic creation of output. Take the trivial case: program needs no relink. In that case, it's up to the compiler/linker whether the program is created atomically. GCC doesn't do it. :-) So I'm not yet convinced this particular race to be a Libtool bug. The problem is that you want to make a combined tree with released gcc and binutils, and since this is arguably a gcc bug you want the latest gcc without the bug to compile a combined tree with any released binutils version. Ah ok. At worse, we could just pass --disable-fast-install in the toplevel configure when gcc is present. That could be a solution for 4.3 actually. But then you may not strictly install ld-new, as it may not work on some systems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #26 from Ralf dot Wildenhues at gmx dot de 2008-04-01 15:42 --- Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap * bonzini at gnu dot org wrote on Tue, Apr 01, 2008 at 05:36:52PM CEST: --- Comment #23 from bonzini at gnu dot org 2008-04-01 15:36 --- and if you modify collect-ld manually to set it to yes? fast-install cannot work on all systems, and does not work on some where it could be made to. What I suggesteded was to use -no-fast-install: you do not want the relink to happen for the execution of the uninstalled program. Sorry, I cannot look into this until later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug preprocessor/35697] -MF should create dependency file atomically
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-03-25 21:00 --- Subject: Re: -MF should create dependency file atomically * pinskia at gcc dot gnu dot org wrote on Tue, Mar 25, 2008 at 09:53:52PM CET: Actually the driver should cleanup the file if cc1 was interrupted/errors out like it does with all the rest of the files. But that still doesn't help with SIGQUIT or KILL. Asking too much? Also, I suppose there can be weird setups where more than one instance of a parallel make read a common subset of makefile snippets, at different times. Haven't seen them, but unless the depfile is *really* created atomically, I wouldn't advise build systems to rely on it being usable without a temp file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35697
[Bug debug/35693] configure: error: cannot compute suffix of object files: cannot compile
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2008-03-25 22:43 --- Subject: Re: configure: error: cannot compute suffix of object files: cannot compile * tom_francen at midtechcorp dot com wrote on Tue, Mar 25, 2008 at 11:38:05PM CET: /apps/tmp:0x83:root:sb100mtc2 cat config.log [...] $ gcc-4.3.0/configure --prefix=/apps/gcc43 --with-config-shell=/usr/bin/ksh --with-gnu-ld --with-gnu-as --with-gmp=/apps/gmp42 --with-mpfr=/apps/mpfr23 That's the toplevel config.log. Please look at the one in the sparc-sun-solaris2.10/libgcc directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693
[Bug bootstrap/35273] [4.3.0 regression] Bootstrap of mingw32 using non-MSYS shell broken
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-02-21 07:33 --- (In reply to comment #0) I did not see an approval of this patch in GCC-patches. Was it approved off-line? Yes, it was approved by Jakub. Patch to fix this breakage posted at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00877.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35273
[Bug c/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2008-02-19 18:35 --- *** Bug 35248 has been marked as a duplicate of this bug. *** -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
[Bug driver/35248] --enable-version-specific-runtime-libs broken
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-02-19 18:35 --- *** This bug has been marked as a duplicate of 32415 *** -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35248
[Bug driver/35248] New: --enable-version-specific-runtime-libs broken
$ echo 'int main() { return 0; }' a.c
$ gcc -o a a.c -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure -C --prefix=/home/ralf/gcc-test
--enable-version-specific-runtime-libs --enable-languages=c,c++
--disable-bootstrap --disable-multilib --with-gmp=/home/ralf/local
--with-mpfr=/home/ralf/local
Thread model: posix
gcc version 4.3.0 20080218 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 'a' '-v' '-mtune=generic'
/home/ralf/gcc-test/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1
-quiet -v -iprefix
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/ a.c -quiet
-dumpbase a.c -mtune=generic -auxbase a -version -o /tmp/cc6oMFbI.s
ignoring nonexistent directory
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include
ignoring duplicate directory
/home/ralf/gcc-test/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include
ignoring duplicate directory
/home/ralf/gcc-test/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include-fixed
ignoring nonexistent directory
/home/ralf/gcc-test/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include-fixed
/usr/local/include
/home/ralf/gcc-test/bin/../lib/gcc/../../include
/usr/include
End of search list.
GNU C (GCC) version 4.3.0 20080218 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f7cc2c1b2fd21e5ef094efa68990cd25
COLLECT_GCC_OPTIONS='-o' 'a' '-v' '-mtune=generic'
as -V -Qy -o /tmp/ccUzmcgh.o /tmp/cc6oMFbI.s
GNU assembler version 2.16.91 (x86_64-linux-gnu) using BFD version 2.16.91
20060118 Debian GNU/Linux
COMPILER_PATH=/home/ralf/gcc-test/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/home/ralf/gcc-test/bin/../libexec/gcc/
LIBRARY_PATH=/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/home/ralf/gcc-test/bin/../lib/gcc/:/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'a' '-v' '-mtune=generic'
/home/ralf/gcc-test/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o
-L/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0
-L/home/ralf/gcc-test/bin/../lib/gcc
-L/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../..
/tmp/ccUzmcgh.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed
/home/ralf/gcc-test/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o
/usr/lib/../lib64/crtn.o
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Problem is, libgcc_s lives in
/home/ralf/gcc-test/lib/gcc/x86_64-unknown-linux-gnu/lib64/
I don't think this is related to PR #35197.
--
Summary: --enable-version-specific-runtime-libs broken
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35248
[Bug libstdc++/35197] Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-15 15:30 --- OK. Well, libstdc++ should not be present in /opt/tg/lib/gcc/alphaev56-dec-osf4.0g but instead in /opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3 Do you still have the build tree or a build log? If the former, could you please look up the value of glibcxx_toolexeclibdir in alphaev56-dec-osf4.0g/libstdc++-v3/src/Makefile to find out why it's not being installed there? I should note that I'm seeing a related problem on x86_64-unknown-linux-gnu with --enable-version-specific-runtime-libs not finding -lgcc_s which is in $libdir/gcc/x86_64-unknown-linux-gnu/lib64. But I think that is a separate bug (and I will open a PR for it later). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug libstdc++/35197] Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2008-02-15 07:28 --- $ g++ -v -o hello hello.cxx [superfluous verbiage elided] Please don't elide that. It shows how exactly you configured GCC, so please show that. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug middle-end/35149] [4.3 Regression] ICE: in expand_call_inline, at tree-inline.c:2653
--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-02-14 06:46 --- Subject: Re: [4.3 Regression] ICE: in expand_call_inline, at tree-inline.c:2653 * hubicka at gcc dot gnu dot org wrote on Wed, Feb 13, 2008 at 06:29:51PM CET: --- Comment #7 from hubicka at gcc dot gnu dot org 2008-02-13 17:29 --- This one liner actually took me a while. It is quite ugly ordering issue. Index: ipa.c === --- ipa.c (revision 132243) +++ ipa.c (working copy) @@ -192,6 +192,7 @@ cgraph_remove_unreachable_nodes (bool be } cgraph_node_remove_callees (node); node-analyzed = false; + node-local.inlinable = false; } else cgraph_remove_node (node); This patch fixes the failure for me. Thanks for working on it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35149
[Bug c++/35149] ICE: in expand_call_inline, at tree-inline.c:2653
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-02-10 09:52 --- Created an attachment (id=15126) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15126action=view) slightly reduced testcase This is what multidelta gets me (see http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction). Sorry, I don't have time for manual reduction ATM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35149
[Bug c++/35149] ICE: in expand_call_inline, at tree-inline.c:2653
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-10 09:53 --- Created an attachment (id=15127) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15127action=view) fix mime type of gzipped testcase -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added Attachment #15126|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35149
[Bug c++/35149] ICE: in expand_call_inline, at tree-inline.c:2653
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-02-10 13:55 --- Created an attachment (id=15128) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15128action=view) slightly more reduced testcase -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added Attachment #15127|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35149
[Bug other/35148] make pdf has missing file in 4.3-20080208
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2008-02-10 17:21 --- Subject: Re: make pdf has missing file in 4.3-20080208 * hal at oz dot net wrote on Sun, Feb 10, 2008 at 06:18:02PM CET: I'd be glad to try changing the rule for gcc-vers.texi to see if that fixes the original problem, but I'm not sure where to do this. What file is this in? diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 7553dcb..9c91fb5 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3653,7 +3653,7 @@ gcc-vers.texi: $(BASEVER) $(DEVPHASE) then echo @set DEVELOPMENT; \ else echo @clear DEVELOPMENT; \ fi) [EMAIL PROTECTED] - echo @set srcdir $(srcdir) [EMAIL PROTECTED] + echo @set srcdir $(abs_srcdir) [EMAIL PROTECTED] if [ -n $(PKGVERSION) ]; then \ echo @set VERSION_PACKAGE $(PKGVERSION) [EMAIL PROTECTED]; \ fi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35148
[Bug other/35148] make pdf has missing file in 4.3-20080208
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2008-02-10 20:30 --- Subject: Re: make pdf has missing file in 4.3-20080208 * joseph at codesourcery dot com wrote on Sun, Feb 10, 2008 at 09:25:09PM CET: On Sun, 10 Feb 2008, Ralf dot Wildenhues at gmx dot de wrote: --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3653,7 +3653,7 @@ gcc-vers.texi: $(BASEVER) $(DEVPHASE) then echo @set DEVELOPMENT; \ else echo @clear DEVELOPMENT; \ fi) [EMAIL PROTECTED] - echo @set srcdir $(srcdir) [EMAIL PROTECTED] + echo @set srcdir $(abs_srcdir) [EMAIL PROTECTED] if [ -n $(PKGVERSION) ]; then \ echo @set VERSION_PACKAGE $(PKGVERSION) [EMAIL PROTECTED]; \ fi This patch is OK for trunk and 4.2 branch. Thanks. Please note that I don't have write access yet (so if you want to make sure it gets in please consider applying it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35148
[Bug other/35148] make pdf has missing file in 4.3-20080208
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2008-02-09 18:36 --- Confirmed the failure with $ /usr/bin/texi2dvi --version texi2dvi (GNU Texinfo 4.8) 1.34 It works fine however with current CVS texinfo. Related: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00125.html -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35148
[Bug other/35148] make pdf has missing file in 4.3-20080208
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-09 22:13 --- Subject: Re: make pdf has missing file in 4.3-20080208 * joseph at codesourcery dot com wrote on Sat, Feb 09, 2008 at 08:29:27PM CET: On Sat, 9 Feb 2008, hal at oz dot net wrote: ! I can't find file `../../gcc-4.3-20080208/gcc/../libiberty/at-file.texi'. This looks like you are configuring with a relative path to the source directory. Does configuring with an absolute path (/path/to/srcdir/configure) help? For me, putting an absolute srcdir path in gcc-vers.texi seems to do the trick for texinfo 4.8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35148
[Bug libgcj/33085] liblt_prog_compiler_pic_GCJ='-DDLL_EXPORT' is wrong
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-02-07 17:25 --- Argh. Why doesn't GCC import the fix in libtool instead of hacking around it downstream? http://lists.gnu.org/archive/html/libtool-patches/2007-08/msg6.html -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33085
[Bug middle-end/35099] [4.3 Regression] ICE in remove_unreachable_regions with -O -fopenmp
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-06 18:05 --- Created an attachment (id=15110) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15110action=view) fairly reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35099
[Bug c++/35109] New: ICE in lookup_name_real, at cp/name-lookup.c:4056
Fall-out from PR 35099: g++ -c test2.ii test2.ii: In member function typename vector_Tp, _Alloc::iterator vector_Tp, _Alloc::insert(__normal_iterator, const _Tp): test2.ii:13: internal compiler error: in lookup_name_real, at cp/name-lookup.c:4056 Please submit a full bug report, That is with trunk from within the last 24 hrs. -- Summary: ICE in lookup_name_real, at cp/name-lookup.c:4056 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35109
[Bug c++/35109] ICE in lookup_name_real, at cp/name-lookup.c:4056
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2008-02-06 18:34 --- Created an attachment (id=15112) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15112action=view) failing test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35109
[Bug other/29972] typos in the manual
--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-02-06 07:33 --- Fixed. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
[Bug ada/15479] Ada manual problems
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-02-03 14:57 --- patch set posted at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00058.html. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15479
[Bug other/31569] Install's web page has 0.n when it should be either 4.n or 5.n
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-02-03 17:29 --- Created an attachment (id=15087) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15087action=view) cheap workaround: turn off section numbering for HTML pages -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31569
[Bug driver/30330] -Wdeprecated is not documented
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-02-03 23:19 --- patch for -Wfoo/-Wno-foo posted at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00069.html. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30330
[Bug c++/26278] ambiguous overload candidates list contains duplicates
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2008-01-29 17:25 --- Created an attachment (id=15050) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15050action=view) reduced testcase t.5.ii: In function int main(): t.5.ii:14: error: ambiguous overload for operator== in c == p t.5.ii:14: note: candidates are: operator==(X, X) built-in t.5.ii:14: note: operator==(int, int) built-in t.5.ii:14: note: operator==(X, X) built-in t.5.ii:7: note: bool coEnume1, e2::operator==(coEnume1, e2) const [with e1 = A, e2 = X] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26278
[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-01-23 08:21 --- Created an attachment (id=15005) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15005action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934
[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-01-23 08:23 --- valgrind output (gcc (GCC) 4.3.0 20080122 (experimental)): send_tiny.i: In function sendto_realops_lev: send_tiny.i:77: warning: implicit declaration of function strlen send_tiny.i:77: warning: incompatible implicit declaration of built-in function strlen send_tiny.i:78: warning: implicit declaration of function vsendto_one --17488-- REDIR: 0x4ccb070 (memmove) redirected to 0x4a1c0f0 (memmove) ==17488== Invalid write of size 8 ==17488==at 0x82D8D9: reachable_at_most_once (tree-stdarg.c:101) ==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377) ==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823) ==17488==by 0x656302: execute_one_pass (passes.c:1118) ==17488==by 0x6564CB: execute_pass_list (passes.c:1171) ==17488==by 0x6564DD: execute_pass_list (passes.c:1172) ==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404) ==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152) ==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215) ==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079) ==17488==by 0x6D3F45: toplev_main (toplev.c:1055) ==17488==by 0x4C7549A: (below main) (in /lib/libc-2.3.6.so) ==17488== Address 0x51177b8 is 0 bytes after a block of size 152 alloc'd ==17488==at 0x4A19DAB: malloc (vg_replace_malloc.c:207) ==17488==by 0xB34CA7: xmalloc (xmalloc.c:147) ==17488==by 0x82D73D: reachable_at_most_once (tree-stdarg.c:61) ==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377) ==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823) ==17488==by 0x656302: execute_one_pass (passes.c:1118) ==17488==by 0x6564CB: execute_pass_list (passes.c:1171) ==17488==by 0x6564DD: execute_pass_list (passes.c:1172) ==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404) ==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152) ==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215) ==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079) ==17488== ==17488== Invalid read of size 8 ==17488==at 0x82D819: reachable_at_most_once (tree-stdarg.c:76) ==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377) ==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823) ==17488==by 0x656302: execute_one_pass (passes.c:1118) ==17488==by 0x6564CB: execute_pass_list (passes.c:1171) ==17488==by 0x6564DD: execute_pass_list (passes.c:1172) ==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404) ==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152) ==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215) ==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079) ==17488==by 0x6D3F45: toplev_main (toplev.c:1055) ==17488==by 0x4C7549A: (below main) (in /lib/libc-2.3.6.so) ==17488== Address 0x51177c0 is 8 bytes after a block of size 152 alloc'd ==17488==at 0x4A19DAB: malloc (vg_replace_malloc.c:207) ==17488==by 0xB34CA7: xmalloc (xmalloc.c:147) ==17488==by 0x82D73D: reachable_at_most_once (tree-stdarg.c:61) ==17488==by 0x82F530: va_list_ptr_read (tree-stdarg.c:377) ==17488==by 0x8307B5: execute_optimize_stdarg (tree-stdarg.c:823) ==17488==by 0x656302: execute_one_pass (passes.c:1118) ==17488==by 0x6564CB: execute_pass_list (passes.c:1171) ==17488==by 0x6564DD: execute_pass_list (passes.c:1172) ==17488==by 0x734718: tree_rest_of_compilation (tree-optimize.c:404) ==17488==by 0x8F44D1: cgraph_expand_function (cgraphunit.c:1152) ==17488==by 0x8F63F8: cgraph_optimize (cgraphunit.c:1215) ==17488==by 0x4174FC: c_write_global_declarations (c-decl.c:8079) ==17488== ==17488== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 2 from 1) -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934
[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2008-01-23 17:12 --- With the patch I get this: xgcc -m32 -O1 -c send_tiny.i send_tiny.i: In function sendto_realops_lev: send_tiny.i:77: warning: incompatible implicit declaration of built-in function strlen send_tiny.i:25: internal compiler error: in reachable_at_most_once, at tree-stdarg.c:102 Please submit a full bug report, Note that I cannot reproduce the failure without -m32 (on x86_64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934
[Bug middle-end/34934] -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev)
--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-01-23 22:33 --- Subject: Re: -O1 crash compile *** glibc detected *** /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1: double free or corruption (!prev) * rguenth at gcc dot gnu dot org wrote on Wed, Jan 23, 2008 at 10:44:51PM CET: I checked both a 32bit compiler and x86_64 with -m32 (with the reduced testcase). Hmm, I don't know what to do. I can reproduce it with a 32bit compiler on x86 as well, with a just built r131766. glibc 2.7 if that matters (but it shouldn't for valgrind). What other differences can be important? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34934
[Bug bootstrap/34922] toplevel ./configure --help is incomplete
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2008-01-22 17:32 --- (In reply to comment #0) libstdc++-v3 gives: $ ../../src/gcc-4.3/configure --disable-libstdc++-v3 configure: error: invalid feature name: libstdc++-v3 This error is from the Autoconf code that parses arguments, it currently disallows characters other than alphanumeric, minus, dot, or underscore in --enable/--disable/--with/--without arguments. I suppose this should be fixed in Autoconf. However, there is also a bug in configure.ac, and with that fixed, you will be able to use --disable-libstdc__-v3 (i.e., with the plus signs converted to underscore). Once GCC switches to a fixed Autoconf version, the plus sign conversion will not be needed any more. Patch posted at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01029.html. Cheers, Ralf -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34922
[Bug bootstrap/34922] toplevel ./configure --help is incomplete
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2008-01-22 20:43
---
Subject: Re: toplevel ./configure --help is incomplete
* brian at dessent dot net wrote on Tue, Jan 22, 2008 at 07:38:35PM CET:
Remember that this toplevel configure is shared between gcc, binutils, gdb,
newlib, insight, and cygwin.
In an ideal world the toplevel configure would check at runtime and see what
subdirs are present and adjust its output accordingly. Also --help=recursive
should be fixed, as there are tons and tons of options that are only shown if
you run configure --help in the subdirs, but are never shown by the toplevel
--help.
I guess without more intrusive hacking that will have to wait until GCC
uses Autoconf 2.62 (I just found one more glitch in there), and even
then I suppose some ugliness such as this is needed:
Index: configure.ac
===
--- configure.ac(revision 131735)
+++ configure.ac(working copy)
@@ -207,6 +207,10 @@
target_configdirs=`echo ${target_libraries} ${target_tools}`
build_configdirs=`echo ${build_libs} ${build_tools}`
+m4_divert_text([PARSE_ARGS],
+[ac_subdirs_all=`cd $srcdir echo */configure | sed 's,/configure,,g'`
+])
+
srcname=gnu development package
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34922
[Bug bootstrap/34922] toplevel ./configure --help is incomplete
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2008-01-22 22:25 --- (In reply to comment #2) (In reply to comment #0) libstdc++-v3 gives: $ ../../src/gcc-4.3/configure --disable-libstdc++-v3 configure: error: invalid feature name: libstdc++-v3 This error is from the Autoconf code that parses arguments, it currently disallows characters other than alphanumeric, minus, dot, or underscore in --enable/--disable/--with/--without arguments. I suppose this should be fixed in Autoconf. Fixed in Autoconf: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=7fa2f766b836280ef3a9a338211bce55ac223565 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34922
[Bug bootstrap/34922] toplevel ./configure --help is incomplete
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2008-01-23 06:42 --- (In reply to comment #5) In an ideal world the toplevel configure would check at runtime and see what subdirs are present and adjust its output accordingly. Also --help=recursive should be fixed, as there are tons and tons of options that are only shown if you run configure --help in the subdirs, but are never shown by the toplevel --help. Patch posted: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01061.html I guess without more intrusive hacking that will have to wait until GCC uses Autoconf 2.62 (I just found one more glitch in there) Autoconf glitch fixed: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=0fd647c6364a383b13af31b45e07679c293ff09f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34922
[Bug c++/34624] valid c++ code doesn't compile for x86_64, but for i386
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-01-14 07:42
---
This fails with both -m32 and -m64 (but I'm not quite sure if it
still reproduces the original issue):
typedef unsigned long size_t;
templatetypename _Tp, size_t _Nm = 1 struct array { };
templatetypename sampletype, unsigned int size
struct my_table: public arraysampletype, size { };
templatetypename sampletype, unsigned int size
inline const sampletype *
get_samples(arraysampletype, size const buffer) {
return buffer.begin();
}
int main() {
my_tablefloat, 1024 tab;
const float * ptr = get_samples(tab);
}
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed |Added
CC||Ralf dot Wildenhues at gmx
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-07-03 14:23 --- This and 32595 are probably dupes (32595 is from a slightly patched cln). -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug c++/32595] New: abort in libiberty:htab_clear_slot
saved_in_unbraced_linkage_specification_p = 0 '\0'
saved_in_function_body = 0 '\0'
saved_num_template_parameter_lists = 0
#27 0x004d36cd in cp_parser_init_declarator (parser=0x2afbbd20,
decl_specifiers=0x7fc04750, checks=0x0, function_definition_allowed_p=1
'\001',
member_p=0 '\0', declares_class_or_enum=value optimized out,
function_definition_p=0x7fc047af \001) at
../../gcc/gcc/cp/parser.c:16354
token = value optimized out
declarator = (cp_declarator *) 0x105b890
prefix_attributes = (tree) 0x0
attributes = (tree) 0x0
asm_specification = (tree) 0x0
initializer = value optimized out
decl = value optimized out
scope = (tree) 0x0
is_initialized = value optimized out
initialization_kind = value optimized out
is_parenthesized_init = value optimized out
is_non_constant_init = value optimized out
ctor_dtor_or_conv_p = value optimized out
friend_p = value optimized out
pushed_scope = (tree) 0x0
#28 0x004c3aec in cp_parser_simple_declaration (parser=0x2afbbd20,
function_definition_allowed_p=1 '\001') at ../../gcc/gcc/cp/parser.c:7851
function_definition_p = 1 '\001'
decl = (tree) 0x2b1ca240
decl_specifiers = {specs = {0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0},
type = 0x2cc6fa90, attributes = 0x0, redefined_builtin_type = 0x0,
storage_class = sc_static, user_defined_type_p = 1, multiple_types_p = 0,
conflicting_specifiers_p = 0, any_specifiers_p = 1, explicit_int_p = 0,
explicit_char_p = 0}
declares_class_or_enum = 0
saw_declarator = 1 '\001'
__FUNCTION__ = cp_parser_simple_declaration
#29 0x004c3f97 in cp_parser_block_declaration (parser=0x2afbbd20,
statement_p=0 '\0') at ../../gcc/gcc/cp/parser.c:7751
saved_pedantic = value optimized out
#30 0x004d68aa in cp_parser_declaration (parser=0x2afbbd20)
at ../../gcc/gcc/cp/parser.c:7659
token1 = {type = 69, keyword = RID_STATIC, flags = 64 '@', pragma_kind
= PRAGMA_NONE,
in_system_header = 0, implicit_extern_c = 0, ambiguous_p = 1,
input_file_stack_index = 421,
u = {tree_check_value = 0x2afc5180, value = 0x2afc5180}, location = {
file = 0x103d430 ../../cln/src/polynomial/elem/cl_UP_MI.h, line = 401}}
token2 = {type = 69, keyword = RID_CONST, flags = 1 '\001', pragma_kind
= PRAGMA_NONE,
in_system_header = 0, implicit_extern_c = 0, ambiguous_p = 1,
input_file_stack_index = 421,
u = {tree_check_value = 0x2afc4540, value = 0x2afc4540}, location = {
file = 0x103d430 ../../cln/src/polynomial/elem/cl_UP_MI.h, line = 401}}
saved_pedantic = value optimized out
#31 0x004d6f15 in cp_parser_declaration_seq_opt (parser=0x2afbbd20)
at ../../gcc/gcc/cp/parser.c:7554
token = (cp_token *) 0x2bfff3a0
#32 0x004d69b0 in cp_parser_declaration (parser=0x2afbbd20)
at ../../gcc/gcc/cp/parser.c:11288
token1 = {type = 69, keyword = RID_NAMESPACE, flags = 64 '@',
pragma_kind = PRAGMA_NONE, in_system_header = 0, implicit_extern_c = 0,
ambiguous_p = 1,
input_file_stack_index = 421, u = {tree_check_value = 0x2afc4cc0,
value = 0x2afc4cc0}, location = {
file = 0x103d430 ../../cln/src/polynomial/elem/cl_UP_MI.h, line = 5}}
token2 = {type = CPP_NAME, keyword = RID_MAX, flags = 1 '\001',
pragma_kind = PRAGMA_NONE, in_system_header = 0, implicit_extern_c = 0,
ambiguous_p = 0,
input_file_stack_index = 421, u = {tree_check_value = 0x2b1ca240,
value = 0x2b1ca240}, location = {
file = 0x103d430 ../../cln/src/polynomial/elem/cl_UP_MI.h, line = 5}}
saved_pedantic = value optimized out
#33 0x004d6f15 in cp_parser_declaration_seq_opt (parser=0x2afbbd20)
at ../../gcc/gcc/cp/parser.c:7554
token = (cp_token *) 0x2bfe3c00
#34 0x004d728e in c_parse_file () at ../../gcc/gcc/cp/parser.c:2966
already_called = 1 '\001'
#35 0x0059374a in c_common_parse_file (set_yydebug=value optimized
out)
at ../../gcc/gcc/c-opts.c:1278
i = 0
__FUNCTION__ = c_common_parse_file
#36 0x007d9cde in toplev_main (argc=value optimized out, argv=value
optimized out)
at ../../gcc/gcc/toplev.c:1051
No locals.
#37 0x2ad3849b in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#38 0x00403cfa in _start () at ../sysdeps/x86_64/elf/start.S:113
No locals.
(gdb)
--
Summary: abort in libiberty:htab_clear_slot
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32595
[Bug c++/32595] abort in libiberty:htab_clear_slot
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2007-07-02 19:32 --- Uploading of the file will have to wait until bugzilla does not internal-error out on me any more, sorry. I sent mail to dberlin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32595
[Bug c++/32595] abort in libiberty:htab_clear_slot
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2007-07-02 19:35 --- Created an attachment (id=13829) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13829action=view) preprocessed unincluded source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32595
[Bug c++/31950] New: ICE in tree-ssa-alias-warnings.c
With mainline as of a couple of days ago:
| gcc version 4.3.0 20070514 (experimental)
g++ -O2 -Wstrict-aliasing=3 -c t.cc
gives me this error:
| t.cc: In function int main():
| t.cc:11: internal compiler error: tree check: expected tree that contains
decl common structure, have struct_field_tag in ffan_walker, at
tree-ssa-alias-warnings.c:638
on the following code. I haven't tried eliminating valarray yet,
but may try to do so, given time. Will try updated mainline next.
Cheers,
Ralf
#include valarray
using std::valarray;
struct A {
valarraydouble* v;
virtual ~A() { delete[] v; }
};
A Op(void);
int main()
{
A a(Op());
return 0;
}
--
Summary: ICE in tree-ssa-alias-warnings.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug c++/31950] ICE in tree-ssa-alias-warnings.c
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2007-05-16 13:35
---
Reduced test case. Both tests also fail with current mainline (revision
124767M).
struct B {
~B();
};
struct A {
B* b;
virtual ~A() { delete[] b; }
};
A Op(void);
int main()
{
A a(Op());
return 0;
}
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed |Added
CC||Ralf dot Wildenhues at gmx
||dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug middle-end/31950] [4.3 Regression] ICE in tree-ssa-alias-warnings.c
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2007-05-16 16:07 --- Your patch seems to fix the failure for both reduced test cases as well as the original code. Thanks for the prompt response! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31950
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-02-16 17:40 --- This is a duplicate of 27843 (Solaris and Tru64 /bin/sh share the same issue), which has been resolved as fixed. :-) Someone empowered enough please reflect this in the settings, thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-02-05 16:51 --- Proposed patch: http://gcc.gnu.org/ml/gcc/2007-02/msg00039.html -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug other/29972] typos in the manual
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2007-01-22 23:06 --- Created an attachment (id=12935) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12935action=view) updated updated updated patch -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added Attachment #12685|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
[Bug other/29972] typos in the manual
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2006-11-25 09:09 --- Created an attachment (id=12685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12685action=view) updated patch enclosed list if compound literal's and object's types match. How about this one instead, it seems much clearer to me: +enclosed list if the types of the compound literal and the object match. Updated patch. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added Attachment #12683|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
[Bug other/29972] New: typos in the manual
Updated patch of http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00236.html with some en_us/en_uk differences dropped, and a couple of new typos. -- Summary: typos in the manual Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
[Bug other/29972] typos in the manual
--- Comment #1 from Ralf dot Wildenhues at gmx dot de 2006-11-24 16:17 --- Created an attachment (id=12683) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12683action=view) typos (against trunk) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #27 from Ralf dot Wildenhues at gmx dot de 2006-03-02 07:09 --- (In reply to comment #25) PR libgcj/17311 * ltmain.sh: Don't use $finalize_rpath for compile. This change will cause breakage on systems when relinking is done at installation time, and on systems where fast-install works and is selected. I'm sorry that due to time constraints I don't have more constructive feedback ATM, but this is definitely not a good fix (and has a good chance of breaking quite unrelated parts of the build process). Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #9 from Ralf dot Wildenhues at gmx dot de 2006-02-28 09:23 --- Regarding the hardcoding problem, the HP-UX 11 ld option '+nodefaultrpath' looks like it might be useful. It seems to be used for ia64 but not hppa*64*, or hppa in general on hpux11. I can not find references to this option in the manpages for hppa ld, not even the presumably latest: http://docs.hp.com/en/B2355-60105/ld_pa.1.html unlike for ia64. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #16 from Ralf dot Wildenhues at gmx dot de 2006-02-28 16:29 --- (In reply to comment #15) I see the same thing without the patch in the installed libstdc++.la. The real kicker is that the -L's for the build directory come before the -L's for the install directory. For an install, the order should be reveresed. No. The link paths to the build tree should not be present at all. Also, there are an amazing number of -lm's and -lgcc_s's that are unnecessary. It's my understanding that the extra -lm's and -lgcc_s's are added to handle cyclical dependencies. These may not be present on all systems. Correct on both accounts. The repetitions are harmless as long as they do not pose a line length issue. I believe a newer Libtool should produce less of those. But it will (not yet) fix the build tree references issue. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #11 from Ralf dot Wildenhues at gmx dot de 2006-03-01 07:24 --- (In reply to comment #10) I see it in the manpages for both HP-UX 11.00 and 11.11. I have the following ld(1) and linker tools patches installed: PHSS_30965 and PHSS_30968. I see in the text for PHSS_30049: Provided a linker option +nodefaultrpath for not recording build-time paths in the resultant executables and shared libraries So how can we find out cheaply whether it's supported? Even if it is ignored when not supported: we could also set hardcode_minus_L=no if supported to get the chance to save some relinking. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2006-02-26 17:19 --- (In reply to comment #5) I had a hppa64 libtool patch that fixed a lot of problems on this port (it needs to be handled in a manner very similar to ia64-hpux) but gave when the patch was ignored upstream. Please point me to your patch. Attached. The diff is against libtool in binutils as about July 28, 2005. Similar changes have entered both branch-1-5 and HEAD Libtool more than 2 years ago; branch-1-4 is long dead. I can only guess that's why it was ignored. ;-) HPPA support has evolved a bit since. There is BTW a pending patch (both branches): http://article.gmane.org/gmane.comp.gnu.libtool.general/7083 Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug target/26472] Default path for libgcc_s.sl is build directory
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2006-02-26 06:40 --- (In reply to comment #2) Subject: Re: Default path for libgcc_s.sl is build directory Isn't this really still a dup of bug 5291? Yes. I got bitten by the bug today ;( No, it is not. At least not exactly, from the Libtool POV: they likely need different fixes. The hppa64-*-hpux* situation is a little different: The result is libgcc_s isn't linked against libstdc++. I had a hppa64 libtool patch that fixed a lot of problems on this port (it needs to be handled in a manner very similar to ia64-hpux) but gave when the patch was ignored upstream. Please point me to your patch. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
[Bug java/21206] gcj seems not to pass the option to ld correctly
--- Comment #13 from Ralf dot Wildenhues at gmx dot de 2006-02-24 14:57 --- (In reply to comment #12) It appears that the LT stands for libtool. So the first one (LIBICONV) is supposed to be used for linking if you aren't using libtool, and the second one (LTLIBICONV) is used for linking if you are using libtool. Right. You cannot expect to be able to use $LTLIBICONV if you are not using Libtool. So, yes, this looks OK to me. We could at least get this on mainline even if we can't fix the release branches yet. That is not ok. Best would probably be if you took LIBICONV and killed all instances of $wl aka $acl_cv_wl from it, and turned all remaining comma into spaces, for good measure. I think. For the former, you could also call AC_LIB_RPATH explicitly and unset or empty $wl for the AM_ICONV call, and restore it afterwards. If you don't need the LIBICONV for other purposes that may involve linking with a compiler driver. Or fix config/lib-link.m4 AC_LIB_RPATH to provide additional variables for use when linking with $LD. Luckily newer Libtool macros don't do that very often anymore, so it may not be worth it. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #19 from Ralf dot Wildenhues at gmx dot de 2006-02-07 16:28 --- (In reply to comment #18) Why do I want [EMAIL PROTECTED] gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH 0x000f (RPATH) Library rpath: /export/build/gnu/gcc/build-x86_64-linux/gcc 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] [EMAIL PROTECTED] gcc]$ It may cause more problems than it solves. Certainly, that's a bad bug and has to be avoided at all (the fact that this may not work correctly now is clear: libtool does not yet fully support what I outlined). Where was I talking about the desire to have run paths in *installed programs* pointing *to the build tree* though? Maybe my notation was bad: a relinked-upon-execution executable is some program .libs/lt-foo inside the build tree that gets created when foo is executed; foo is a shell script that does this. Does this make things clearer now? Sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:18 --- (In reply to comment #20) What did you mean by *installed programs* In my notation, installed programs live below $prefix. They must not contain any reference to the build tree. You showed an installed program in comment #18, which has an erroneous run path. The executable in question is [EMAIL PROTECTED] .libs]$ readelf -d /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/gij | grep RPATH 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] This is an uninstalled program: it lives below $builddir. It should of course have a run path entry to the newly-built library (which also lives below $builddir). One of my points was that, if that uninstalled program also has a run path entry pointing to /usr/gcc-4.2/lib/../lib64, but that comes after all the run paths which point to inside $builddir, then that is not a big problem. Is is your *installed programs*? No. My point is when you run a newly built executable in the build tree, it should use the newly built shared libraries in the build tree. It is a long standing bug in gcc/libtool. Yes, correct. It's one of my medium term quests to fix this. The converse issue (from a libtool POV) is just GCC bug 5291. Again from a libtool POV it is convenient and useful to attack both issues at the same time. One of the open questions that I could not answer myself yet: When you issue `make install' for GCC, is there a guarantee by the GCC build machinery that - libraries are installed in the correct order (libgcc_s.so before libgcj)? I strongly assume yes. - For each libtool-created library, in case it needs to be relinked at install time, does the relink command have appropriate -L (and maybe -R) flags pointing to the installed non-libtool libraries (e.g., $prefix/lib/libgcc_s)? In comment #18, you show that for this build, the second question is true. I need to know however if it is true in any case, for any value of $host. Iff both questions can be affirmed, then the next question can also be made true: - If libtool erased both all `-L' and all `-R' flags pointing inside the build tree from the relink command that may be issued at `make install' time, would installation still succeed? Then we have a chance to fix this portably in libtool, not only for GNU/Linux. Another small but important question: - Do there exist directories in the GCC build tree where both libtool-created and non-libtool-created libraries are (possibly) built? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #23 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:43 --- (In reply to comment #22) - Do there exist directories in the GCC build tree where both libtool-created and non-libtool-created libraries are (possibly) built? That is THE KEY question. The executable in question is lt-gij: [EMAIL PROTECTED] .libs]$ readelf -d /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/lt-gij | grep RPATH 0x000f (RPATH) Library rpath: [/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs] [EMAIL PROTECTED] .libs]$ libgcc_s.so.1 isn't built by libtool. Yes, but the one is $stage/gcc/libgcc_s.so.1 and the other is $stage/x86_64-unknown-linux-gnu/libjava/lib/libgcj.la, so they are built in different directories. Libtool has to know that $stage/gcc is something that is necessary for the uninstalled link and run paths; but libtool also needs to be able to deduce that the path $stage/gcc must not be used for any installed libraries or programs. Now, if I want to fix this properly (in Libtool), then I need to know whether above question can be answered with yes not only for libgcc_s/libgcj, but for each library created in GCC. And also the other questions, really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #15 from Ralf dot Wildenhues at gmx dot de 2006-02-06 18:24 --- (In reply to comment #8 by H. J. Lu) See http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02467.html I don't know how to do --disable-fast-install for gcc. --enable-fast-install is totally wrong for ELF. It should never be used for any ELF targets. I don't understand this comment. You seem to imply that libtool should not add DT_RPATH entries pointing to installed paths to libraries/executables in the build tree. But given --enable-fast-install, and given that there are no indirect library dependencies, this is the correct thing: both libraries and programs can be copied to their final location without relink and will work correctly. libtool creates a shell wrapper for uninstalled programs that does relink-upon-execution and adds DT_RPATH entries for all direct dependencies. Of course, given --enable-fast-install but *indirect* library dependencies inside the build tree, adding DT_RPATH entries with the installed paths would not work: the wrong indirect libs would be picked up. However, libtool could still solve this: all systems which support indirect library dependencies well (i.e.: GNU/Linux) have measures make both the link editing step work (-rpath-link) as well as relink-upon-execution (just put all paths for uninstalled indirect dependencies in the run path of the relinked executable). What am I missing? Cheers, Ralf -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #17 from Ralf dot Wildenhues at gmx dot de 2006-02-07 05:48 --- (In reply to comment #16) Please read the summary line: Wrong libgcc_s.so.1 is used by lt-gij. Ld.so will search DT_RPATH first for any shared libraries. Yes. So all that is missing is a notion in libtool to tell it this path is to be added to the list of *uninstalled* run paths which would be added to the relinked-for-execution executable (after all other uninstalled paths) but not the unrelinked one and not either to any uninstalled libraries (on ELF, of course). You have to have that notion anyway because otherwise there would be no way you could add the run path to libgcc_s to libtool safely at all (i.e. without ending up in installed files). In comment #8 you said: I don't know how to do --disable-fast-install for gcc. As for --disable-fast-install, it's not optimal either. But libtool could create all libraries/programs with the uninstalled run paths (also the ones given by above new flag) and after that all other given ones. `make install' will surely have to relink all of those; but I don't see the necessity for a shell wrapper in this case either (on system where shlibpath_overrides_runpath=no). All there is missing for decent libtool support for libtool + non-libtool libraries in one build tree is a notion to pass uninstalled run paths and uninstalled link editor paths (-L), AFAICS. By the way, I don't see any reason why the installed run paths should not be put after the uninstalled ones (into the relinked-upon-execution executable). You have to assume anyway that incompatible libraries may be found in the default runtime linker search path, so really they are not contributing much to the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug other/25460] -pthread should have priority over -nostdlib
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2005-12-18 00:53 --- For the casual reader of the documentation, the precedence of this statement over | `-pthread' | Adds support for multithreading with the pthreads library. This | option sets flags for both the preprocessor and linker. or even the fact that the latter will add a library, are not obvious. It would be nice if the documentation could be more definite on both of these points. BTW, I believe libtool does the -nostdlib stuff because, at least in the past, not using it could cause situations where later libstdc++ would not be found automatically. I think at least for dlopen'ed modules depending on C++ libraries this is still the case (completely untested). Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460
[Bug other/25460] -pthread should have priority over -nostdlib
--- Comment #2 from Ralf dot Wildenhues at gmx dot de 2005-12-17 07:16 --- The question whether libtool should use -nostdlib in conjunction with adding all the other stuff explicitly is surely a valid one, if not completely trivial and with some interesting corner cases. It is, however, completely orthogonal to this bug report. Documentation for -nostdlib does not suggest that -pthread is not honored any more. That is either a documentation bug, if the semantics were desired, or a driver bug, if not. Please decide, and fix this. Then, we may discuss about libtool semantics (preferably on the libtool lists). Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460
[Bug middle-end/16373] -O2 and -O3 compiler switches do not omit-frame-pointers as the docs. describe.
--- Comment #5 from Ralf dot Wildenhues at gmx dot de 2005-12-13 14:37 --- Created an attachment (id=10471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10471action=view) doc patch for -fomit-frame-pointer Meanwhile, please fix the documentation to match what it does (and states elsewhere); see attached patch. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16373
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #12 from Ralf dot Wildenhues at gmx dot de 2005-12-12 16:54 --- Created an attachment (id=10459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10459action=view) quick hack to fix #5291 Here's a dirty hack to fix the installed .la files (regenerated files not shown). I can provide patches against classpath and libltdl as well, if this one is deemed ok. I do not intend to put it in upstream Libtool quite like this, but I do intend to suggest a cleaned up version there eventually. Cheers, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug c/25179] New: precedence of -fpie over -fpic
When both -fpie and -fpic are given on the command line, -fpie wins, independent on the order of the arguments. This is unfortunate, as PIC objects are more widely usable. It would be more useful to either let the last one win, or let -fpic win over -fpie, from a usability standpoint: for example, if -fpie were added to overall CFLAGS, and those were used for both program objects and shared library objects, current build rules for many packages would most likely still work. It would've also made this patch unnecessary, as an aside: http://lists.gnu.org/archive/html/libtool/2005-11/msg00093.html Observed with gcc-3.4.4 and CVS HEAD as of before the switch to SVN. Cheers, and keep up the good work, Ralf -- Summary: precedence of -fpie over -fpic Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25179
[Bug c++/22005] [4.1 Regression] ICE: SSA_NAME verification failure
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-20 09:38 --- Thanks a lot for fixing this so promptly. I can confirm that the code which triggered this compiles now and seems to be working fine again with CVS HEAD. (BTW, even with its share of bugs, CLN might be a candidate for g++ regression testing -- it has uncovered a handful of GCC (and some CLN) bugs over time. Just a thought.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/22004] New: ICE: SSA_NAME varification failure
CVS HEAD of today gives me a bunch of SSA errors and finally an ICE on this file (taken from CLN) when optimization is turned on: g++ -O1 -c cl_prin_globals.ii bzip'ed file plus error output attached. Sorry for the suboptimal naming (don't know what is happening here) and the large file size. -- Summary: ICE: SSA_NAME varification failure Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22004
[Bug c++/22005] New: ICE: SSA_NAME verification failure
CVS HEAD of today gives me a bunch of SSA errors and finally an ICE on this file (taken from CLN) when optimization is turned on: g++ -O1 -c cl_prin_globals.ii bzip'ed file plus error output attached. Sorry for the suboptimal naming (don't know what is happening here) and the large file size. -- Summary: ICE: SSA_NAME verification failure Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/22004] ICE: SSA_NAME varification failure
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-10 16:54 --- *** This bug has been marked as a duplicate of 22005 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|ICE: SSA_NAME varification |ICE: SSA_NAME varification |failure |failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22004
[Bug c++/22005] ICE: SSA_NAME verification failure
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-10 16:54 --- *** Bug 22004 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/22005] ICE: SSA_NAME verification failure
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-10 16:55 --- Created an attachment (id=9063) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9063action=view) preprocessed source that exposes this -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/22005] ICE: SSA_NAME verification failure
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-06-10 16:56 --- Created an attachment (id=9064) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9064action=view) g++ output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/21092] New: friend inaccessibility
A recent change on CVS HEAD breaks this:
$ cat a.cc
class X {
friend class Y;
friend int foo(const Y);
};
$ g++ -c -W -Wall a.cc
a.cc:3: error: expected ',' or '...' before '' token
a.cc:3: error: ISO C++ forbids declaration of 'Y' with no type
The original bug report is against CLN with possibly more info
of value, and may be read here:
http://thep.physik.uni-mainz.de/pipermail/cln-list/2005-April/000119.html
AFAIK gcc-4.0.0 is fine.
--
Summary: friend inaccessibility
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Ralf dot Wildenhues at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092
[Bug pch/19540] New: document pch directory feature
Please document that it is possible to store a pch of foo.h in a directory named foo.h.gch/ such that subsequent compiles will search all files in that directory for a good precompiled header candidate. (See also http://gcc.gnu.org/ml/gcc/2005-01/msg01087.html) -- Summary: document pch directory feature Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19540
[Bug pch/19541] New: deprecation of -I- makes precompiled headers less usable
As noted in this thread: http://gcc.gnu.org/ml/gcc/2005-01/msg01087.html there is no way to make use of a precompiled header without -I- in a VPATH build in case the header source and the C or C++ source file including it reside in the same source directory. Please consider adding a flag (-icwd?) to the preprocessor which will cause the current directory to be search for pch before the source directory. Or consider to change the default pch search order. -- Summary: deprecation of -I- makes precompiled headers less usable Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug pch/19541] deprecation of -I- makes precompiled headers less usable
--- Additional Comments From Ralf dot Wildenhues at gmx dot de 2005-01-20
15:47 ---
mkdir src build
echo 'extern int foo;' src/foo.h
echo src/bar.c '#include foo.h
int bar(void) { return foo; }'
cd build
gcc -o foo.h.gch ../src/foo.h
gcc -H -c ../src/bar.c
This will not use the gch in the current directory,
unless I also specify `-I. -I-'.
Putting the pch under the source tree works against all VPATH build
principles (read-only source tree). It does not matter whether I
use a directory build/foo.h.gch/ or a file.
(The other bug I reported was indeed false, apologies for the
reading disability that struck me there.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug c++/19270] New: ice on valid template code
With CVS version as of today: $ ~/gcc-test/bin/g++ -c ./boundcpy.ii ./boundcpy.ii: In member function T Vec3T::operator[](int) const [with T = REAL]: ./boundcpy.ii:33: instantiated from here ./boundcpy.ii:20: internal compiler error: Segmentation fault Please submit a full bug report, -- Summary: ice on valid template code Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19270
