[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-13 07:43 --- Fixed on trunk. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32
--- Comment #7 from dannysmith at gcc dot gnu dot org 2009-01-13 07:41 --- Subject: Bug 38580 Author: dannysmith Date: Tue Jan 13 07:40:51 2009 New Revision: 143330 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143330 Log: PR bootstrap/38580 * gcc.c (process_command): Replace call to execvp with calls to pex_one and exit. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs
--- Comment #6 from rob1weld at aol dot com 2009-01-13 07:16 --- (In reply to comment #5) > # Even if the default multilib is not a cross compilation, > # it may be that some of the other multilibs are. > if test $cross_compiling = no && test $multilib = yes \ >&& test "x${with_multisubdir}" != x ; then >cross_compiling=maybe > fi > Yes, it's a little screwy. If 64 bit code can not be executed on a 32 bit platform then you MUST be 'cross compiling'. I think the term it is looking for is 'building multilib'. Other circumstances include "co-processing". You want to compile for your favorite hardware, Xbox or PSP, and you execute a portion of gcc's build on the device, both for speed and accuracy of the values determined by the configure scripts. The 'hardware' can also be "fake" like Qemu. There is also the situation where you have the hardware you are compiling for and could execute the program and libraries on the device. This helps to get the real values for fixing scripts used to cross compile. The gdb program can help run "make -i check" on your hardware remotely. Maybe the Docs need this explanation: What if you have a 486 and want to build 32/64 bit execs/libs for a 686. That is cross compiling and multilib, regardless of boot mode. Up in family or "cross" family is cross compiling. What if you have a 686 and want to build 32/64 bit execs/libs for a 686. That is building multilib, regardless of boot mode. Same family, no cross. What if you have a 686 and want to build 32/64 bit execs/libs for a 486. That is building multilib, regardless of boot mode. Down in family is not cross compiling. Building any of the above combinations with either only 32 bit _or_ only 64 bit execs/libs means you are not building multilib. Building for a higher number in the family or "cross" to a different (and non-compatible) family is cross compiling. A quick mention for completeness that cross platform (or ABI) compiling is not "cross compiling" in the usual sense though the same techniques can be used to get gcc to run under Cygwin (a Linux Simulation for Windows (and others)) or Wine (a Windows Simulation for Linux (and others)) by using bootstrapping and cross compiling. I don't know why this 32/64 bit issue comes up so often. We've had 64 bit OSes for a few years now. It must be the VM that is new and confusing ;(o Also, the dozen occurrences of the 'ac_link' variable is redundant. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804
[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-01-13 06:07 --- Reply to comments 16 and 17 which I did not see before my commit. Please make sure the original r143102 is in place when you apply latest patch. It does seem bothersome that the xplor-nih is so sensitive. It is largely due to depending on error conditions. I don't think we want to jump to Daniels patch until we understand what's wrong here. Regardless, I will need a reduced test case to go further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:57 --- Thanks for help Jack. The patch committed does fix the test case you provided. Please double check with xplor-nih and if fixed as expected we can close this PR. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|r143102 breaks error|r143102 reveals missed error |checking on floating point |checking on floating point |reads |reads http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:53 --- Subject: Bug 38772 Author: jvdelisle Date: Tue Jan 13 05:53:07 2009 New Revision: 143328 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143328 Log: 2009-01-12 Jerry DeLisle PR libfortran/38772 * gfortran.dg/fmt_bz_bn_err.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_bz_bn_err.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-01-13 05:40 --- Subject: Bug 38772 Author: jvdelisle Date: Tue Jan 13 05:40:36 2009 New Revision: 143327 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143327 Log: 2009-01-12 Jerry DeLisle PR libfortran/38772 * io/read.c (read_f): Clean up loop conditions for BZ/BN, allowing proper digit testing. White space fix. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-01-13 05:31 --- I'll do a fresh bootstrap with the proposed patch tomorrow. We may have a separate regression that appeared since I last checked the full xplor-nih testsuite. Basically, the following difference is appearing in output of half of the testcases @@ -264,8 +264,8 @@ X-PLOR>energy end --- cycle= 1 -- | Etotal =236.279grad(E)=14.482 E(BOND)=41.209 E(ANGL)=122.157 | - | E(DIHE)=0.000 E(IMPR)=48.529 E(VDW )=18.932 E(ELEC)=0.000 | - | E(COUP)=5.453 | + | E(DIHE)=0.000 E(IMPR)=48.529 E(VDW )=18.932 E(ELEC)=0.000 + | E(COUP)=5.453 --- X-PLOR> X-PLOR>coup print threshold=1.0 class phi end somehow we are losing the trailing | character in the output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-01-13 05:06 --- Jerry, While that eliminated the failure in the xtarget.inp testcase for xplor-nih, it also increased the number of test case failures from 13 to 72 out of 133 tests. I'll test Daniel's patch to see if it allows all of xplor-nih's testcases to pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug testsuite/38821] [4.4 Regression] Testsuite for libjava is truncated
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 05:02 --- There is no java source compiler in 4.3 and above so the number of tests have decreased. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38821
[Bug testsuite/38821] New: [4.4 Regression] Testsuite for libjava is truncated
I built gcc version 4.4.0 20090104 (experimental) (GCC) and configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 --enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with-stabs --enable-debug -enable-largefile --enable-symvers --without-system-zlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld I ran "make -i check" and got this sort of result for libjava: Using /usr/share/src/gcc_trunk/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.cni/cni.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jar/jar.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jni/jni.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jvmti/jvmti-interp.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.jvmti/jvmti.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.lang/lang.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.loader/loader.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.mauve/mauve.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.special/special.exp ... Running /usr/share/src/gcc_trunk/libjava/testsuite/libjava.verify/verify.exp ... === libjava Summary === # of expected passes2468 # of unexpected failures55 # of untested testcases 55 -- I built gcc version 4.2.3 (release) and configured with: ../gcc_4.2.3/configure --prefix=/usr/gnu --libdir=/usr/gnu/lib --libexecdir=/usr/gnu/lib --mandir=/usr/gnu/share/man --infodir=/usr/share/info --with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-multilib --enable-shared --disable-static --enable-decimal-float -disable-nls I ran "make -i check" and got this sort of result for libjava: Using /usr/share/src/gcc_4.2.3/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.cni/cni.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.compile/compile.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jacks/jacks.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jar/jar.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jni/jni.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.jvmti/jvmti.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.lang/lang.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.loader/loader.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.mauve/mauve.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.special/special.exp ... Running /usr/share/src/gcc_4.2.3/libjava/testsuite/libjava.verify/verify.exp ... === libjava Summary === # of expected passes6978 # of unexpected failures13 # of expected failures 12 # of untested testcases 18 -- When you compare gcc version 4.4.0 20090104 with gcc version 4.2.3 (release) you notice that the trunk adds test "libjava/testsuite/libjava.jvmti/jvmti-interp.exp" and is missing both tests "libjava/testsuite/libjava.compile/compile.exp" and "libjava/testsuite/libjava.jacks/jacks.exp". The 4.2.3 version passed 6978 tests (with a couple of dozen 'not-pass' results). The Trunk version passed 2468 tests (with four dozen 'not-pass' results). The Trunk was compiled with a few more complicated java configuration yet there were fewer tests for the Trunk compared with the 4.2.x series. I have looked at some results from / to: http://gcc.gnu.org/ml/gcc-testresults/2008-03/ http://gcc.gnu.org/ml/gcc-testresults/2009-01/ and it seems that 4.4 is with far fewer tests than prior versions. Thanks, Rob -- Summary: [4.4 Regression] Testsuite for libjava is truncated Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38821
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-01-13 04:36 --- Here is a patch. If the character is not a digit or a blank, we exit the loop and skip the test for not a digit. DUH! (first part of patch is just an indentation fix) Index: read.c === --- read.c (revision 143139) +++ read.c (working copy) @@ -972,14 +972,14 @@ read_f (st_parameter_dt *dtp, const fnod while (w > 0) { if (*p != ' ') - goto bad_float; + goto bad_float; p++; w--; } } else /* BZ or BN status is enabled */ { - while (w > 0 && (isdigit (*p) || *p == ' ')) + while (w > 0) { if (*p == ' ') { -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-01-13 04:14 --- The problem is in read.c. In reading floats we are not catching invalid exponent characters. The BN patch just revealed this bug that has been there all along. The string can be just about anything with an 'e' followed by at least one character, including such things as 'ej' or 'ek '. Incidentally, Daniel's read float patch fixes this. If any one is brave enough, we could just commit his patch. Otherwise I will band aid this one, hopefully shortly. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libfortran/38772] r143102 breaks error checking on floating point reads
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-01-13 03:44 --- Great work Jack. Now we have a test case to work with. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-13 03:44:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug testsuite/38820] New: [4.2/4.3/4.4 Regression] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/"
+++ This bug was initially created as a clone of Bug #14435 +++ I built "gcc version 4.4.0 20090111 [trunk revision 143259]" and when I run "make -i check" it sets 'GCC_EXEC_PREFIX="/usr/local/lib/gcc/"'. It seems gcc may look for this directory: # ls -lrtA /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/ total 1327 drwxr-xr-x 13 root root 21 Jan 10 22:26 include-fixed drwxr-xr-x 3 root root 7 Jan 11 17:57 install-tools -rw-r--r-- 1 root root 137434 Jan 11 17:58 libgcc_eh.a -rw-r--r-- 1 root root 236788 Jan 11 17:58 libgcc.a -rw-r--r-- 1 root root 95148 Jan 11 17:58 libgcov.a -rw-r--r-- 1 root root3888 Jan 11 17:58 gmon.o -rw-r--r-- 1 root root2032 Jan 11 17:58 crtbegin.o -rw-r--r-- 1 root root1300 Jan 11 17:58 crtend.o -rwxr-xr-x 1 root root 924 Jan 11 17:59 libgfortranbegin.la -rw-r--r-- 1 root root4462 Jan 11 17:59 libgfortranbegin.a drwxr-xr-x 2 root root 604 Jan 11 18:06 adalib drwxr-xr-x 2 root root1087 Jan 11 18:06 adainclude drwxr-xr-x 4 root root 12 Jan 11 18:06 amd64 drwxr-xr-x 2 root root 6 Jan 11 18:07 finclude drwxr-xr-x 5 root root 41 Jan 11 18:07 include # gmake -i check ... gmake[2]: Entering directory `/usr/share/src/gcc_build/gcc' test -d testsuite || mkdir testsuite test -d testsuite/gcc || mkdir testsuite/gcc (rootme=`${PWDCMD-pwd}`; export rootme; \ srcdir=`cd ../../gcc_trunk/gcc; ${PWDCMD-pwd}` ; export srcdir ; \ cd testsuite/gcc; \ rm -f tmp-site.exp; \ sed '/set tmpdir/ s|testsuite|testsuite/gcc|' \ < ../../site.exp > tmp-site.exp; \ /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \ EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \ if [ -f ${rootme}/../expect/expect ] ; then \ TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \ export TCL_LIBRARY ; fi ; \ GCC_EXEC_PREFIX="/usr/local/lib/gcc/" ; export GCC_EXEC_PREFIX ; \ ... If you do NOT run "make install" _PRIOR_ to running "make -i check" then how can we be thinking that "/usr/local/lib/gcc/" contains the _correct_ code to be used for the Testsuite ? We should either require installation prior to checking (which is not good but I do it to ensure I don't get hit) _or_ have "make -i check" do a _partial_ installation to a temp directory and set the "GCC_EXEC_PREFIX" environment variable to the temporary directory instead (preferred). We need "GCC_EXEC_PREFIX" set to the code that was just compiled and not to code that might have been installed weeks / months previously (or not installed at all). Rob -- Summary: [4.2/4.3/4.4 Regression] During "make -i check" we set GCC_EXEC_PREFIX="/usr/local/lib/gcc/" Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38820
[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc
--- Comment #5 from rob1weld at aol dot com 2009-01-13 02:52 --- (In reply to comment #4) > >"Cannot build gnattools while gnatlib is out of date or unbuilt". > That bug is a different issue than this bug. Please don't confuse the two. I searched before I posted to try to avoid a dupe. As long as this _second_ manifestation of "Cannot build gnattools while ..." is recorded as a bug _somewhere_ then that is OK. It would be a 'fix' in _my_ instance if typing "make" built gnatlib first (so it was not "out of date or unbuilt") and then was able to build gnattools successfully. Thanks for the info, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #19 from bkoz at gcc dot gnu dot org 2009-01-13 01:49 --- Subject: Bug 38384 Author: bkoz Date: Tue Jan 13 01:49:30 2009 New Revision: 143322 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143322 Log: 2009-01-12 Benjamin Kosnik PR libstdc++/38384 * crossconfig.m4 (hpux): Update for 10.20, 11, 11.20. * configure: Regenerate. 2009-01-12 Benjamin Kosnik * crossconfig.m4 (linux): Add GCC_CHECK_TLS to define _GLIBCXX_HAVE_TLS. Use GLIBCXX_CHECK_COMPILER_FEATURES to compute SECTION_FLAGS. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/crossconfig.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug libstdc++/36647] configure scripts can not find out version of GNU ld 2.18
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-01-13 01:35 --- on trunk (4.4.x): 1) ld --version GNU ld (GNU Binutils) 2.19 checking for ld version... 21900 2) ld --version GNU ld version 2.18.50.0.9-7.fc10 20080822 checking for ld version... 21850 3) ld --version GNU ld (GNU Binutils) 2.18 checking for ld version... 21800 All have visibility/versioning support enabled. This seems fine. On gcc-4_3-branch (will be 4.3.3) this is also ok. Thus, closing. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36647
[Bug c++/35109] [4.2/4.3/4.4 Regression] ICE in lookup_name_real, at cp/name-lookup.c:4056
--- Comment #6 from jason at gcc dot gnu dot org 2009-01-13 01:23 --- Subject: Bug 35109 Author: jason Date: Tue Jan 13 01:23:34 2009 New Revision: 143320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143320 Log: PR c++/35109 * name-lookup.c (lookup_name_real): Keep looking past a hidden binding. Added: trunk/gcc/testsuite/g++.dg/lookup/friend14.C trunk/gcc/testsuite/g++.dg/lookup/friend15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lookup/friend11.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35109
[Bug tree-optimization/38748] [4.4 Regression] Missed FRE because of VIEW_CONVERT_EXPR
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 01:09 --- We should be able to fold: VIEW_CONVERT_EXPR(D.919509.D.78313.D.78008) Into just D.919509 . The indirect issue is a different one which needs to be fixed anyways as it causes aliasing issues which were not in the original code in some cases. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-13 01:09:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38748
[Bug libgcj/38812] gcj-built executables don't run after strip (libgcj erroneously references _environ)
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 01:03 --- Confirmed, though your patch is not portable really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-apple-darwin9.5.0 | GCC host triplet|i386-apple-darwin9.5.0 | GCC target triplet|i386-apple-darwin9.5.0 |*-*-darwin* Last reconfirmed|-00-00 00:00:00 |2009-01-13 01:03:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38812
[Bug other/38805] sed Unterminated `s' command
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 01:01 --- for ac_var in `(set) 2>&1 | sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38805
[Bug other/38805] sed Unterminated `s' command
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-13 00:59 --- How did you invoke configure? How did you invoke GNU make? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38805
[Bug libfortran/38772] r143102 breaks xplor-nih
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-01-13 00:55 --- The attached badread,f test program produces... F ...when attempting to read a float with... READ(TEMP,'(F20.0)',ERR=) R from TEMP='END' when run against the libgfortran prior to r143102. After r143102, the libgfortran results in the output of T which is means that we aren't properly handling error conditions in the floating point read routines now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug bootstrap/38728] gcc 4.4.0 20090104 - "make install" is relinking `libgij.la'
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:54 --- I have no idea why this happens for you but it works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38728
[Bug libfortran/38772] r143102 breaks xplor-nih
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-01-13 00:52 --- Created an attachment (id=17081) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17081&action=view) test program demonstrating missing error condition -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38772
[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-13 00:45 --- # Even if the default multilib is not a cross compilation, # it may be that some of the other multilibs are. if test $cross_compiling = no && test $multilib = yes \ && test "x${with_multisubdir}" != x ; then cross_compiling=maybe fi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804
[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:45 --- Hmm, automake should have done the correct thing ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804
[Bug bootstrap/38743] libgcc multilib fails if not able to exec "non" native programs
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:42 --- a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is needed for libgcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|gcc 4.4.0 20090106 - The|libgcc multilib fails if not |configure for |able to exec "non" native |$BUILD/amd64/libgcc checks |programs |if 64 bit code can exec on | |32 bit platform | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38743
[Bug awt/38803] [4.4 regression] Configure with "--enable-java-awt=x" requires Escher
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bug-classpath at gnu dot org Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38803
[Bug bootstrap/38792] RFE - Need Makefile to build using different strategy for "coverage" vs. "profiling"
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-13 00:38 --- Coverage builds should not be bootstrapped. Profiled bootstrap means build stage1 with no opts and then stage2 with generating the profiling data and then build some target libraries (not all though) and the build stage3 using that generated profile data. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38792
[Bug bootstrap/3415] make distclean (in gcc subdirectory) does not clean up all the way
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:36 --- *** Bug 38800 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3415
[Bug bootstrap/38800] gcc 4.4.0 20090109 - "make -i -k distclean" does not remove amd64/*/* fixincludes/* and /gnattools/*
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:36 --- fixincludes is already registered as PR 25470. And really PR 3415 is the original bug for it. *** This bug has been marked as a duplicate of 3415 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38800
[Bug bootstrap/38776] gcc 4.4.0 20090109 - Configure with "--enable-coverage=noopt" breaks build
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-13 00:32 --- You should not be bootstrapping a --enable-coverage=noopt build, you should only need to build stage1 gcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38776
[Bug bootstrap/38788] gcc 4.4.0 20090109 - Configure with "--enable-intermodule" breaks build
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-13 00:31 --- Nobody builds using --enable-intermodule, it uses too much memory in general anyways so closing as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38788
[Bug bootstrap/38775] gcc 4.4.0 20090109 - The Makefile displays "profile" when using "--enable-coverage" (and not profiling)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-13 00:28 --- Well you don't understand any of these options it seems. First --enable-coverage=nopt does nothing except changes the CFLAGS really. There is nothing in the toplevel makefile or configure which uses --enable-coverage=, only the gcc subdirectory. Also you should not be bootstrapping a compiler built with --enable-coverage= really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38775
[Bug middle-end/33443] Compiler warnings in gcc sources
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-13 00:21 --- *** Bug 38746 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33443
[Bug bootstrap/38746] gcc 4.4.0 20090104 - Warnings during bootstrap about poor coding
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:21 --- *** This bug has been marked as a duplicate of 33443 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38746
[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement GCC build triplet|i386-pc-solaris2.11 | GCC host triplet|i386-pc-solaris2.11 | GCC target triplet|i386-pc-solaris2.11 |*-*-solaris* Summary|gcc 4.4.0 20090104 -|libmudflap could be enabled |OpenSolaris can enable |for Solaris when using GNU |libmudflaps (if gcc is |ld |configured to use GNU ld) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738
[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 00:18 --- >"Cannot build gnattools while gnatlib is out of date or unbuilt". That bug is a different issue than this bug. Please don't confuse the two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323
[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc
--- Comment #3 from rob1weld at aol dot com 2009-01-13 00:14 --- In gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] we have the: "Cannot build gnattools while gnatlib is out of date or unbuilt" Bug. # gmake clean-gcc ... # gmake ... gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libgcc' g ... gmake[5]: Entering directory `/usr/share/src/gcc_build/gcc' gmake[5]: `ada/s-oscons.ads' is up to date. gmake[5]: Leaving directory `/usr/share/src/gcc_build/gcc' test -f stamp-libada || \ gmake -C ../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-m64" "LN_S=ln -s" "SHELL=/bin/sh" "GNATLIBFLAGS=-W -Wall -gnatpg -m64" "GNATLIBCFLAGS=-g -O2 -m64" "TARGET_LIBGCC2_CFLAGS=-fPIC" "THREAD_KIND=native" "TRACE=no" "MULTISUBDIR=/amd64" "libsubdir=/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64" "objext=.o" "prefix=/usr/local" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include" "CFLAGS=-g -O0 -fprofile-arcs -ftest-coverage-m64 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes" gnatlib-shared \ && touch stamp-libada true DO=all multi-do # gmake gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libada' gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libada' gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libada' gmake[2]: Entering directory `/usr/share/src/gcc_build/gnattools' rm -rf ../gcc/ada/tools mkdir -p ../gcc/ada/tools (cd ../gcc/ada/tools; ln -s ../sdefault.adb .) rm -f ../gcc/ada/tools/mlib-tgt-specific.adb; ln -s /usr/share/src/gcc_trunk/gcc/ada/mlib-tgt-specific-solaris.adb ../gcc/ada/tools/mlib-tgt-specific.adb; touch ../gcc/stamp-tools Cannot build gnattools while gnatlib is out of date or unbuilt gmake[2]: *** [../gcc/stamp-gnatlib-rts] Error 1 gmake[2]: Leaving directory `/usr/share/src/gcc_build/gnattools' gmake[1]: *** [all-gnattools] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 You may get this message; if you type: # cd gcc_build/gcc/.. # make clean-gcc # make ... "Cannot build gnattools while gnatlib is out of date or unbuilt". Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #18 from bkoz at gcc dot gnu dot org 2009-01-12 23:59 --- Thanks for your help Dave: this should be fixed now. (FWIW, the 10.20 config is correct, or mostly correct.) Still, it's nice to confirm. Ranier, this should be working now. Can you try to cross-compile as before, but with updated gcc sources? -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug fortran/38810] Floating point exception
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38810
[Bug bootstrap/36815] gnattools related error when building only c and fortran
--- Comment #2 from rob1weld at aol dot com 2009-01-12 23:35 --- (In reply to comment #0) > With --enable-languages=c,fortran, system trys to build gnattools and fails > with this error: > ... > Cannot build gnattools while gnatlib is out of date or unbuilt > ... That may occur if you use "make clean-gcc" (clean only the gcc directory) and then try to type "make" afterwards. It should not harass you if the language Ada was not even on the list. There is some fixing needed here. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36815
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-12 23:00 --- The 4.3 version seems to be the old one, with is_* prefixes and macro, while trunk/4.2 are the new ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #8 from dodji at gcc dot gnu dot org 2009-01-12 22:50 --- Fixed in trunk, gcc-4_3 and gcc-4_2. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #7 from dodji at gcc dot gnu dot org 2009-01-12 22:48 --- Subject: Bug 36019 Author: dodji Date: Mon Jan 12 22:47:49 2009 New Revision: 143315 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143315 Log: gcc/cp/ChangeLog: 2009-01-12 Dodji Seketeli PR c++/36019 * pt.c (parameter_of_template_p): New function. * cp-tree.h: Declare it. * name-lookup.c (binding_to_template_parms_of_scope_p): New function. (outer_binding): Take template parameters in account when looking for a name binding. gcc/testsuite/ChangeLog: 2009-01-12 Dodji Seketeli PR c++/36019 * g++.dg/lookup/hidden-class12.C: New test. * g++.dg/lookup/hidden-class13.C: New test. * g++.dg/lookup/hidden-class14.C: New test. * g++.dg/lookup/hidden-class15.C: New test. * g++.dg/lookup/hidden-class16.C: New test. Added: trunk/gcc/testsuite/g++.dg/lookup/hidden-class12.C trunk/gcc/testsuite/g++.dg/lookup/hidden-class13.C trunk/gcc/testsuite/g++.dg/lookup/hidden-class14.C trunk/gcc/testsuite/g++.dg/lookup/hidden-class15.C trunk/gcc/testsuite/g++.dg/lookup/hidden-class16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #6 from dodji at gcc dot gnu dot org 2009-01-12 22:44 --- Subject: Bug 36019 Author: dodji Date: Mon Jan 12 22:44:13 2009 New Revision: 143314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143314 Log: gcc/cp/ChangeLog: 2009-01-12 Dodji Seketeli PR c++/36019 * pt.c (parameter_of_template_p): New function. * cp-tree.h: Declare it. * name-lookup.c (binding_to_template_parms_of_scope_p): New function. (outer_binding): Take template parameters in account when looking for a name binding. gcc/testsuite/ChangeLog: 2009-01-12 Dodji Seketeli PR c++/36019 * g++.dg/lookup/hidden-class12.C: New test. * g++.dg/lookup/hidden-class13.C: New test. * g++.dg/lookup/hidden-class14.C: New test. * g++.dg/lookup/hidden-class15.C: New test. * g++.dg/lookup/hidden-class16.C: New test. * gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C: Adjust testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class12.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class13.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class14.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class15.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/lookup/hidden-class16.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/cp-tree.h branches/gcc-4_3-branch/gcc/cp/name-lookup.c branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #5 from dodji at gcc dot gnu dot org 2009-01-12 22:41 --- Subject: Bug 36019 Author: dodji Date: Mon Jan 12 22:41:19 2009 New Revision: 143313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143313 Log: gcc/cp/ChangeLog: 2009-01-12 Dodji Seketeli PR c++/36019 * pt.c (parameter_of_template_p): New function. * pt.c (get_template_info): Ditto. * cp-tree.h: Declare those. * name-lookup.c (binding_to_template_parms_of_scope_p): New function. (outer_binding): Take template parameters in account when looking for a name binding. gcc/testsuite/ChangeLog: 2009-01-12 Dodji Seketeli PR c++/36019 * g++.dg/lookup/hidden-class12.C: New test. * g++.dg/lookup/hidden-class13.C: New test. * g++.dg/lookup/hidden-class14.C: New test. * g++.dg/lookup/hidden-class15.C: New test. * g++.dg/lookup/hidden-class16.C: New test. * gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C: Adjust testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class12.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class13.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class14.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class15.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/lookup/hidden-class16.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/name-lookup.c branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.old-deja/g++.benjamin/tem03.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug middle-end/38817] GCC wrongly optimize a modulo operation.
--- Comment #2 from jlerouge at apple dot com 2009-01-12 22:22 --- Verified fixed with 4.3.3. -- jlerouge at apple dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38817
[Bug c++/38818] C++ bitfield static initialisation problem
--- Comment #2 from john dot spelis at 3dlabs dot com 2009-01-12 22:16 --- Subject: Re: C++ bitfield static initialisation problem Thank you. (I'm suitably humbled). Cheers On 12 Jan 2009, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:37 > --- > *(unsigned long *)this=l; > > You are violating C/C++ aliasing rules which invokes undefined behavior as you > are accessing a giChannelTiming as a unsigned long. > > Either use -fno-strict-aliasing or memcpy or unions or the attribute may_alias > to fix your code > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818
[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754
--- Comment #6 from vmakarov at redhat dot com 2009-01-12 22:12 --- Yes, it is an IRA bug. Code processing calls to functions can throw is lost in IRA. I'll submit a patch tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
[Bug middle-end/36548] [4.3 Regression] remainder gives the wrong result for wrapping case with unsigned types
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-12 21:56 --- *** Bug 38817 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jlerouge at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36548
[Bug middle-end/38817] GCC wrongly optimize a modulo operation.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:56 --- This was fixed for 4.3.3 by the patch for PR 36548. *** This bug has been marked as a duplicate of 36548 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38817
[Bug tree-optimization/38515] Disabling PPL/CLOOG with configure does not work
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-12 21:38 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38515
[Bug c++/38818] C++ bitfield static initialisation problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:37 --- *(unsigned long *)this=l; You are violating C/C++ aliasing rules which invokes undefined behavior as you are accessing a giChannelTiming as a unsigned long. Either use -fno-strict-aliasing or memcpy or unions or the attribute may_alias to fix your code -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818
[Bug tree-optimization/38515] Disabling PPL/CLOOG with configure does not work
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-12 21:37 --- Subject: Bug 38515 Author: spop Date: Mon Jan 12 21:36:58 2009 New Revision: 143311 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143311 Log: 2009-01-12 Sebastian Pop PR tree-optimization/38515 * configure.ac (cloog-polylib): Removed. (with_ppl, with_cloog): Test for "no". * configure: Regenerated. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38515
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #18 from bkoz at gcc dot gnu dot org 2009-01-12 21:36 --- fixed for 4.4.x/4.3.x -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #17 from bkoz at gcc dot gnu dot org 2009-01-12 21:32 --- Subject: Bug 36801 Author: bkoz Date: Mon Jan 12 21:32:19 2009 New Revision: 143310 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143310 Log: 2009-01-12 Benjamin Kosnik Jonathan Larmour PR libstdc++/36801 * config/cpu/generic/atomicity_mutex/atomicity.h (get_atomic_mutex): New. (__gnu_cxx::__exchange_and_add): Use it. * src/debug.cc (get_safe_base_mutex): New. * src/locale.cc (get_locale_cache_mutex): New. * src/mt_allocator.cc (get_freelist): New. (get_freelist_mutex): New. * src/pool_allocator.cc (get_palloc_mutex): New. 2009-01-12 Jonathan Larmour * include/ext/concurrence.h: Fix __gthread_cond_t initialisation function macro name. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/config/cpu/generic/atomicity_mutex/atomicity.h branches/gcc-4_3-branch/libstdc++-v3/include/ext/concurrence.h branches/gcc-4_3-branch/libstdc++-v3/src/debug.cc branches/gcc-4_3-branch/libstdc++-v3/src/locale.cc branches/gcc-4_3-branch/libstdc++-v3/src/mt_allocator.cc branches/gcc-4_3-branch/libstdc++-v3/src/pool_allocator.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug c++/31488] [4.3/4.4 Regression] va_list considered non-POD
--- Comment #13 from jason at gcc dot gnu dot org 2009-01-12 21:07 --- Subject: Bug 31488 Author: jason Date: Mon Jan 12 21:07:46 2009 New Revision: 143308 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143308 Log: PR c++/31488 * tree.c (pod_type_p): Return 1 for structs created by the back end. Added: trunk/gcc/testsuite/g++.dg/other/vararg-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #16 from bkoz at gcc dot gnu dot org 2009-01-12 20:57 --- Created an attachment (id=17080) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17080&action=view) for gcc-4_3-branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug tree-optimization/38819] New: [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop
The following test wrongly fails with a floating point exception (division by integer 0) when built with -O2 for i686-pc-linux-gnu. Based on an example posted by Robert Seacord to the WG14 reflector. It works with 3.4 and earlier, fails with 4.0 and later. The % operation may trap if it is % 0 (or INT_MIN % -1, cf bug 30484 and another recent reflector discussion suggesting INT_MIN % -1 should in fact be undefined in ISO C), so cannot be hoisted above the loop unless it is guaranteed to be executed at least once. extern void exit (int); extern void abort (void); volatile int a = 1; volatile int b = 0; volatile int x = 2; volatile signed int r = 8; void __attribute__((noinline)) foo (void) { exit (0); } int main (void) { int si1 = a; int si2 = b; int i; for (i = 0; i < 100; ++i) { foo (); if (x == 8) i++; r += i + si1 % si2; } abort (); } -- Summary: [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
[Bug c++/38818] New: C++ bitfield static initialisation problem
The following program seems to show a compiler bug on x86 using 4.3.2 compilers The correct output should be; giChannelTiming0.Setup 0xff giChannelTiming0.Recover 0xff00 which occurs only when no optimiser or -O is used. When -O2 or greater is used the mask's are incorrectly computed and print as 0. It is known also not to work on 4.1.2 compilers. It works perfectly with all optimisation levels on 3.2.3 compilers. /* */ #include #include typedef struct giChannelTiming { #if BYTE_ORDER == BIG_ENDIAN /* Bits 24..31 */ unsigned Recover : 8 ; /* Bits 16..23 */ unsigned Hold : 8 ; /* Bits 8..15 */ unsigned Pulse : 8 ; /* Bits 0.. 7 */ unsigned Setup : 8 ; #else /* Bits 0.. 7 */ unsigned Setup : 8 ; /* Bits 8..15 */ unsigned Pulse : 8 ; /* Bits 16..23 */ unsigned Hold : 8 ; /* Bits 24..31 */ unsigned Recover : 8 ; #endif giChannelTiming(long l = 0) { *(unsigned long *)this=l; } operator unsigned long *(void) { return((unsigned long *)this) ; } operator unsigned long (void) { return(*(unsigned long *)this) ; } } t_giChannelTiming ; #define FIO_LOCATED(n) 0 #define ID_GEN_giChannelTiming0Setup 0 #define ID_GEN_giChannelTiming0Recover 0 #define GI_REG_F(field,reg) { #reg "." #field, ID_GEN_##reg##field, \ { FIO_LOCATED(reg), (gr.reg=0, gr.reg.field =~0, (unsigned long)gr.reg)}} struct gen_registers { t_giChannelTiming giChannelTiming0; } ; static gen_registers gr ; struct regs { const char *name ; int id ; struct masks { int locn ; unsigned long mask ; } s ; } r[] = { GI_REG_F(Setup, giChannelTiming0), GI_REG_F(Recover, giChannelTiming0) } ; main() { printf("%s 0x%lx\n", r[0].name, r[0].s.mask); printf("%s 0x%lx\n", r[1].name, r[1].s.mask); } /* - */ -- Summary: C++ bitfield static initialisation problem Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot spelis at 3dlabs dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818
[Bug target/29141] static constructors beyond 64k fail
--- Comment #5 from aesok at gcc dot gnu dot org 2009-01-12 20:42 --- Subject: Bug 29141 Author: aesok Date: Mon Jan 12 20:41:57 2009 New Revision: 143306 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143306 Log: PR target/29141 * config/avr/t-avr (LIB1ASMFUNCS): Add _tablejump_elpm. * config/avr/libgcc.S (__do_global_ctors, __do_global_dtors): Add variant for devices with 3-byte PC. (__tablejump_elpm__) : New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/libgcc.S trunk/gcc/config/avr/t-avr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29141
[Bug middle-end/38808] another warning from system headers.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-12 20:28 --- Well for -m32/-m64 case, it might be difference in 32bit vs 64bit conversions :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38808
[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names
--- Comment #14 from markus dot schoepflin at comsoft dot de 2009-01-12 20:01 --- Just to recap what I think the problem is: 1) cc1 compiles the C file and creates input for the system assembler. The assembler source is placed into the /tmp directory. 2) The system assembler is called to create the object file "dir test/hello.o" from the assembler source file in /tmp. The system assembler can't deal with the space character in the location of the object file and instead creates an object file called "dir" in the current directory. 3) mips-tfile is called to add debugging information to the object file in "dir test/hello.o" but there is no such file, because the system assembler didn't create it, and mips-tfile complains correctly that there is no such file. Does that sound about right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names
--- Comment #13 from markus dot schoepflin at comsoft dot de 2009-01-12 19:51 --- Strange, I seem to get something different on Linux with gcc 4.3.2: ~/src/tests/gcc/PR4605$ gcc -v -c hello.c -o "./dir test/hello.o" Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) COLLECT_GCC_OPTIONS='-v' '-c' '-o' './dir test/hello.o' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.2/cc1 -quiet -v hello.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase hello.c -mtune=generic -auxbase-strip ./dir test/hello.o -version -fstack-protector -o /tmp/cciLVmZP.s ignoring nonexistent directory "/usr/local/include/i486-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include" ignoring nonexistent directory "/usr/include/i486-linux-gnu" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.2/include /usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed /usr/include End of search list. GNU C (Ubuntu 4.3.2-1ubuntu11) version 4.3.2 (i486-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=23711 Compiler executable checksum: fbed29247d8ae538bfd0dd565a17225f COLLECT_GCC_OPTIONS='-v' '-c' '-o' './dir test/hello.o' '-mtune=generic' as -V -Qy -o ./dir test/hello.o /tmp/cciLVmZP.s GNU assembler version 2.18.93 (i486-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.18.93.20081009 COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-c' '-o' './dir test/hello.o' '-mtune=generic' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
[Bug c/32041] [4.3 Regression] offsetof buglet
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-12 19:45 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.1 4.3.0 4.4.0 |4.0.1 4.3.0 Known to work|3.3 |3.3 4.4.0 Summary|[4.3/4.4 Regression]|[4.3 Regression] offsetof |offsetof buglet |buglet http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug c/32041] [4.3/4.4 Regression] offsetof buglet
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-12 19:44 --- Subject: Bug 32041 Author: jakub Date: Mon Jan 12 19:44:33 2009 New Revision: 143305 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143305 Log: PR c/32041 * c-parser.c (c_parser_postfix_expression): Allow `->' in offsetof member-designator, handle it as `[0].'. * parser.c (cp_parser_builtin_offsetof): Allow `->' in offsetof member-designator, handle it as `[0].'. * gcc.dg/pr32041.c: New test. * g++.dg/parse/offsetof9.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/offsetof9.C trunk/gcc/testsuite/gcc.dg/pr32041.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32041
[Bug gcov-profile/38784] gcc 4.4.0 20090109 - Naming xgcc.* gcc.* when configure with "--enable-coverage=noopt"
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-12 19:29 --- (In reply to comment #3) > That is what I am saying. There should be an exclusion for that one file only. Why? this is what should be done and how this has been implemented for a long time. -fprofile-arcs does not enable gmon profiling, It enables exact profiling of basic block edges and nothing more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38784
[Bug tree-optimization/38816] New: [4.4 Regression] graphite undocumented
+++ This bug was initially created as a clone of Bug #38465 +++ For 4.4, "info -f /usr/local/info/gccint.info -n Passes" needs to document the 'Graphite Pass' in the "Passes" section. At minimum a link to a Doc. -- Summary: [4.4 Regression] graphite undocumented Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38816
[Bug c/38817] New: GCC wrongly optimize a modulo operation.
The following code seems to be wrongly optimized by GCC: int main(int argc, char **argv) { unsigned int foo = 3; return ((838237499u * foo - 2137600414u) % 11u); } always return 0 on my machine, it should return 7. GCC seems to be optimizing the modulo operation (even with -O0). GCC version: debian:~ $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-1) Command line used: debian:~ $ gcc -o t t.c Thanks, Julien -- Summary: GCC wrongly optimize a modulo operation. Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlerouge at apple dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38817
[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization
--- Comment #18 from amylaar at gcc dot gnu dot org 2009-01-12 18:09 --- (In reply to comment #17) > I think enabling partial PRE to do it is appropriate (with at most inserting > on one edge). I think the abstraction with tree-ssa and cfglayout mode has gone too far. We no longer have visibility of the costs of branches, or of opportunities for conditional execution. I suspect that the 35% speed regressions we see on EEMBC fbital at -O3 are also to blame on overzealous tree-pre partial-partial redundancy eliminations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug inline-asm/38815] Taking the address of a __thread variable prevents the r0 register from being loaded
--- Comment #1 from gilles dot chanteperdrix at xenomai dot org 2009-01-12 18:03 --- The following code: __thread long tl = 42; long f(void) { long *l = &tl; register long r0 __asm__ ("r0"); register long *r1 __asm__ ("r1"); r0 = 23; r1 = l; __asm__ __volatile__ ("": "+r"(r0) : "r"(r1)); return r0; } When compiled with -O2, gives the followin assembly code: f: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 ldr r1, .L3 str lr, [sp, #-4]! bl __aeabi_read_tp @ load_tp_soft add r1, r0, r1 ldr pc, [sp], #4 Where we see that the r0 register is never loaded with 23 as it should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-12 18:01 --- Subject: Re: [4.4 Regression] Incorrect delayed branch optimization > I've been building parts of glibc's vfprintf code with -fno-delayed-branch for > hppa because of bugs in DBR. I never filed a bug because it was almost > impossible for me to reduce the vfprintf code (large file, large tables, long > jumps). I would guess that this particular regression has something to do with the new register allocator. The general problem mentioned by Richard Sandiford dbr_schedule is the only user of resource.c, which is based on this horrible hack of assuming that, although the basic block information is no longer up-to-date, we can still rely on the live register sets before BARRIERs. We also assume that we can rely on REG_DEAD notes to some extent: if a register is marked dead by a REG_DEAD note, and isn't set again before the next label, we assume it really is dead at the label. is more serious. The delayed branch optimisation is run at all levels. So, the generated code may be wrong if a user doesn't specify -fno-delayed-branch. As this problem affects more than the PA, possibly the priority of this report should be increased. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug inline-asm/38815] New: Taking the address of a __thread variable prevents the r0 register from being loaded
-- Summary: Taking the address of a __thread variable prevents the r0 register from being loaded Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gilles dot chanteperdrix at xenomai dot org GCC target triplet: armeb-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815
[Bug middle-end/38814] valgrind returns Invalid write in reserve_phi_args_for_new_edge
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-12 17:39 --- things really have a random flavor right now. I have a bt for a segfault from gdb, within a couple of minutes now: [ repeats about 4000 times] #4011 0x0049267d in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:213 #4012 0x004921bf in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315 #4013 0x004921b1 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:314 #4014 0x00491d51 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:471 #4015 0x004921bf in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315 #4016 0x004922f1 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:291 #4017 0x0065d145 in gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:171 #4018 0x0065d276 in gt_ggc_m_P11cgraph_node4htab (x_p=) at gtype-desc.c:2077 #4019 0x00628fbe in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107 #4020 0x004dad48 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941 #4021 0x0069f115 in execute_todo (flags=34871) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1047 #4022 0x0069f385 in execute_one_pass (pass=0x10f4da0) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1302 #4023 0x0069f575 in execute_pass_list (pass=0x10f4da0) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1328 #4024 0x0069f58d in execute_pass_list (pass=0x10f4860) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1329 #4025 0x0069f895 in execute_ipa_pass_list (pass=0x10f4800) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:892 #4026 0x00917ca6 in cgraph_optimize () at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1239 #4027 0x00490855 in gfc_be_parse_file (set_yydebug=) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:240 #4028 0x00746605 in toplev_main (argc=, argv=) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:970 #4029 0x7f7d53f33436 in __libc_start_main () from /lib64/libc.so.6 ---Type to continue, or q to quit--- #4030 0x00405859 in _start () (gdb) BTW, gcc from 2009-01-09 did not seem to display this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38814
[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc
--- Comment #24 from aph at gcc dot gnu dot org 2009-01-12 17:36 --- Subject: Bug 38396 Author: aph Date: Mon Jan 12 17:35:48 2009 New Revision: 143301 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143301 Log: 2009-01-12 Andrew Haley PR libgcj/38396: * libgcj_bc.c: Sort lines. *(_Jv_LookupInterfaceMethod, _Jv_MonitorExit, _Jv_RegisterResource, _Jv_JNI_PopSystemFrame): Add. * sun/misc/natUnsafe.cc (spinlock contructor): Call sched_yield(). Modified: branches/gcc-4_3-branch/libjava/ChangeLog branches/gcc-4_3-branch/libjava/libgcj_bc.c branches/gcc-4_3-branch/libjava/sun/misc/natUnsafe.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754
--- Comment #5 from hjl dot tools at gmail dot com 2009-01-12 17:27 --- Is this an IRA bug? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||vmakarov at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
[Bug fortran/38813] ICE with C_LOC(array)
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:59 --- For the diagnostics: I think it works, but we are checking in case of C_LOC(Type%Comp) the symbol Type instead of Comp. Assume that Type is a pointer and Comp is not then "gfc_is_data_pointer()" returns true for Type%Comp even though it is not a pointer (Type is a pointer, Type%Comp is the component of the target to which Type points). But somehow also the is_scalar_expr_ptr check and the args_sym->attr.dimension check point do something wrong. For rejects valid: Make "Type" a pointer and Type%Comp an array. The ICE itself is fixed by the following patch: --- trans-expr.c(Revision 143289) +++ trans-expr.c @@ -2451 +2451 @@ gfc_conv_function_call (gfc_se * se, gfc - && fsym->as->type != AS_ASSUMED_SHAPE; + && fsym->as && fsym->as->type != AS_ASSUMED_SHAPE; -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
[Bug fortran/38810] Floating point exception
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-12 16:39 --- For quick reading, skip next part and continue below the * * *. --- I think this applies still (at least partially) as libgfortran/config/fpu*.h's set_cpu() still has the line. For GLIBC one finds: /* glibc does never have a FE_DENORMAL. */ if (options.fpe & GFC_FPE_DENORMAL) #ifdef FE_DENORMAL feenableexcept (FE_DENORMAL); #else st_printf ("Fortran runtime warning: IEEE 'denormal number' " "exception not supported.\n"); #endif NOTE: The FE_* are defined in the system's fenv.h file and POSIX (SUSv3) does not specify FE_DENORMAL only: FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW and FE_UNDERFLOW. And also on my system (glibc-devel-2.9-4.18) fenv.h does not have FE_DENORMAL. However, fpu-387.h has support for it: if (options.fpe & GFC_FPE_DENORMAL) cw &= ~_FPU_MASK_DM; [...] if (has_sse()) [...] if (options.fpe & GFC_FPE_DENORMAL) cw_sse &= ~(_FPU_MASK_DM << 7); Thus the question is whether for "linux (i686) release" the fpu-387.h should have been applied instead? * * * For the reported problem: > gives the message "Fortran runtime warning: IEEE 'denormal number' exception > not supported" without the compiler option -ffpe-trap. It does not make sense that the message is printed without -ffpe-trap=. I don't see how this could happen (with the current code). > The program directly crashed with a floating point exception I some doubt that the FPE crash is related to denormal numbers as they are usually handled gracefully and are not serious. Especially since the warning explicitly states that they are not supported for trapping. For the crash it is extremely unlikely that it happens while printing the warning message. > I tried to find the error in the debugger kdbg, but before the first > executable statement was passed the program stopped with the floating point > error. There is a serious lack of information here - for instance you are missing the compiler options. Stab into the dark: You are not using by chance -malign-double or -mno-align-double? If you do, please remove it! (If you don't, don't use it.) We need: 1. If possible a minimal program which shows the bug, seemingly something like print *, 'Hello World' end is enough if the crash happens before the actual program is executed 2. The exact command line used to compile the program 3. More information about the compiler, i.e. my 4.1 compiler shows: gcc version 4.1.3 20080612 (prerelease) (SUSE Linux) Target: x86_64-suse-linux What does yours show for "gfortran -v"? And best is to update to a newer gfortran version. 4.1.x is pretty old and the 4.1.x series is no longer maintained. 4.3.x and the currently developed 4.4 are maintained (and 4.2.x is still maintained for a couple of weeks). Thus it would be best if you could update to 4.3.x or 4.4. As Daniel mentioned: Build instruction and pre-build binaries are available at http://gcc.gnu.org/wiki/GFortranBinaries -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38810
[Bug middle-end/38814] New: valgrind returns Invalid write in reserve_phi_args_for_new_edge
version used for testing: GNU Fortran (GCC) version 4.4.0 20090112 (experimental) [trunk revision 143288] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20090112 (experimental) [trunk revision 143288], GMP version 4.2.2, MPFR version 2.3.1. valgrind --tool=memcheck /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize -ffree-form -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccIEjF0W.s ==22900== ==22900== Invalid write of size 8 ==22900==at 0x7A028D: reserve_phi_args_for_new_edge (tree-flow-inline.h:299) ==22900==by 0xAE0332: redirect_edge_succ_nodup (cfg.c:410) ==22900==by 0x751AC0: gimple_redirect_edge_and_branch (tree-cfg.c:4801) ==22900==by 0xAF0479: redirect_edge_and_branch (cfghooks.c:323) ==22900==by 0x75CFBC: cleanup_tree_cfg_bb (tree-cfgcleanup.c:413) ==22900==by 0x75D71C: cleanup_tree_cfg (tree-cfgcleanup.c:594) ==22900==by 0x69EE44: execute_function_todo (passes.c:923) ==22900==by 0x69F06E: execute_todo (passes.c:1025) ==22900==by 0x69F384: execute_one_pass (passes.c:1302) ==22900==by 0x69F574: execute_pass_list (passes.c:1328) ==22900==by 0x69F58C: execute_pass_list (passes.c:1329) ==22900==by 0x69F58C: execute_pass_list (passes.c:1329) ==22900== Address 0x20008 is not stack'd, malloc'd or (recently) free'd all.f90: In function build_se_core_matrix: all.f90:364860: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. the testcase is all.f90 in http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz (see also comment #112 in PR29975). which unfortunately means it takes a couple of hours to reproduce through valgrind. I started the valgrinded compilation after having a segfault with a normal compilation that I couldn't reproduce in gdb. The latter really is a bit strange, just testing it again, segfaults out of gdb, doesn't segfault within gdb.. -- Summary: valgrind returns Invalid write in reserve_phi_args_for_new_edge Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38814
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #20 from pault at gcc dot gnu dot org 2009-01-12 16:20 --- Created an attachment (id=17079) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17079&action=view) A preliminary patch for the PR A slightly earlier version of this regtested OK. Will do it to this version tonight and then will submit. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #21 from jakub at gcc dot gnu dot org 2009-01-12 16:18 --- Created an attachment (id=17078) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17078&action=view) gcc44-pr38245.patch Patch I'm playing with. I don't see why changing CALL_INSN_FUNCTION_USAGE to have only at most word sized stores would simplify it much. The patch is still overly conservative, on the other side some stack arguments (e.g. large struct by value) still aren't added to CALL_INSN_FUNCTION_USAGE. If such an argument is first or last, this patch still won't catch it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug c++/38794] [4.2/4.3 regression] Function body accepted in typedef
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-12 15:45 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression] |Function body accepted in |Function body accepted in |typedef |typedef http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
[Bug c++/38794] [4.2/4.3/4.4 regression] Function body accepted in typedef
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-12 15:43 --- Subject: Bug 38794 Author: jakub Date: Mon Jan 12 15:43:22 2009 New Revision: 143292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143292 Log: PR c++/38794 * decl.c (start_function): If grokdeclarator hasn't returned FUNCTION_DECL nor error_mark_node, issue diagnostics. * g++.dg/parse/typedef9.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/typedef9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38794
[Bug tree-optimization/38385] ICE with -O2 -ftree-loop-distribution
--- Comment #6 from tomby at gcc dot gnu dot org 2009-01-12 15:37 --- Subject: Bug 38385 Author: tomby Date: Mon Jan 12 15:37:09 2009 New Revision: 143291 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143291 Log: PR middlend/38385 * tree-loop-distribution.c (prop_phis): New function. (generate_builtin): Call prop_phis. * testsuite/gcc.dg/tree-ssa/pr38385.c: New file. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr38385.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38385
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #8 from rguenther at suse dot de 2009-01-12 15:16 --- Subject: Re: [4.4 regression] warnings from -isystem headers strikes back. On Mon, 12 Jan 2009, pluto at agmk dot net wrote: > > > --- Comment #7 from pluto at agmk dot net 2009-01-12 15:10 --- > (In reply to comment #5) > > I can't seem to compile the preprocessed source: > > i've attached a new full archive. > > $ make > rm -f *.ii *.o *.s > /local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall > -O2 > -g0 -fPIC --save-temps -isystem ./sys-headers bug.cpp > bug.cpp: In function 'void foo()': > bug.cpp:6: warning: dereferencing pointer '' does break > strict-aliasing rules > ./sys-headers/boost/optional/optional.hpp:315: note: initialized from here > bug.cpp:6: warning: dereferencing pointer '' does break > strict-aliasing rules > ./sys-headers/boost/optional/optional.hpp:594: note: initialized from here > > > Note that the warning is from bug.cpp:6, not a system header anyway > > looks weird, because i can't see any dereferencing in bug.cpp:6 > there's only trivial cctor which copies an enum. > > for me it looks like the comes from boost::optional:: > ::aligned_storage::adress() manipulations inside boost system headers. > > > (the _note_ is from a system header, do you want that to disappear?) > > i want to disappear'em all :-) Fair enough ;) The compiler just warns that in a second it will remove that dereference (ok, only on the alias-improvements branch). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #7 from pluto at agmk dot net 2009-01-12 15:10 --- (In reply to comment #5) > I can't seem to compile the preprocessed source: i've attached a new full archive. $ make rm -f *.ii *.o *.s /local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2 -g0 -fPIC --save-temps -isystem ./sys-headers bug.cpp bug.cpp: In function 'void foo()': bug.cpp:6: warning: dereferencing pointer '' does break strict-aliasing rules ./sys-headers/boost/optional/optional.hpp:315: note: initialized from here bug.cpp:6: warning: dereferencing pointer '' does break strict-aliasing rules ./sys-headers/boost/optional/optional.hpp:594: note: initialized from here > Note that the warning is from bug.cpp:6, not a system header anyway looks weird, because i can't see any dereferencing in bug.cpp:6 there's only trivial cctor which copies an enum. for me it looks like the comes from boost::optional:: ::aligned_storage::adress() manipulations inside boost system headers. > (the _note_ is from a system header, do you want that to disappear?) i want to disappear'em all :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754
--- Comment #4 from ubizjak at gmail dot com 2009-01-12 15:06 --- -fno-ira fixes the failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #8 from carlos at systemhalted dot org 2009-01-12 15:02 --- Dave, I've been building parts of glibc's vfprintf code with -fno-delayed-branch for hppa because of bugs in DBR. I never filed a bug because it was almost impossible for me to reduce the vfprintf code (large file, large tables, long jumps). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #6 from pluto at agmk dot net 2009-01-12 15:01 --- Created an attachment (id=17077) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17077&action=view) full testcase (src + .ii + mkefile) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names
--- Comment #12 from ubizjak at gmail dot com 2009-01-12 14:59 --- Hm, on i686-pc-linux-gnu -v gives: COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' /usr/local.uros/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 -quiet -v dir test/hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o /tmp/ccgcf4Ot.s COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' as -V -Qy -o hello.o /tmp/ccgcf4Ot.s Please note, that the output of as is created in current directory, not in "dir\ test" subdirectory. BTW: The error in comment #7 comes from mips-tfile executable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-01-12 14:51 --- Ok, how about -Wstrict-aliasing=3 warning only if both the dereference and the declaration are not from system-headers (this is then the default for -Wall) and with -Wstrict-aliasing=2 (or =1) warn if either of them is not from system-headers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #13 from pluto at agmk dot net 2009-01-12 14:43 --- (In reply to comment #12) > This isn't really a warning from system headers: > > test.cpp:14: warning: dereferencing pointer '__x.13' does break > strict-aliasing > rules > > the location for the dereference is in test.cpp (if that is correct or not > is another issue). There is at least a bug that we will emit the note: part > even if the warning was suppressed - I am going to fix that. > > I can omit the warning for pointers that are declared in system headers > in addition to that. Probably this is what is the better behavior - but > I cannot easily report the dereference location even if it is in a system > header but the pointer is _not_ from a system header -- which is probably > what would be wanted here. > > So, > > t.h: > #pragma GCC system_header > > inline float deref_float (float *p) { return *p; } > > t.C: > #include "t.h" > > float transform(int i) > { > return deref_float ((float *)&i); > } > > _should_ emit a warning? Even if it looks like > > t.h: In function 'float transform(int)': > t.h:3: warning: dereferencing pointer 'i.0' does break strict-aliasing rules > t.C:5: note: initialized from here > > ? > > IMHO we want to warn unless _both_, the declaration and the dereference is > in a system header. > this will be painfull for users, e.g. boost::optional uses so called aligned_storage via mistic void*/casts/etc and now i'm getting these warnings from boost-system-headers. in this way, the -isystem switch is completely useless. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug testsuite/38809] gcc.dg/pr38616.c doesn't work on Linux/ia64
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-12 14:30 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38809
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-12 14:25 --- This isn't really a warning from system headers: test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing rules the location for the dereference is in test.cpp (if that is correct or not is another issue). There is at least a bug that we will emit the note: part even if the warning was suppressed - I am going to fix that. I can omit the warning for pointers that are declared in system headers in addition to that. Probably this is what is the better behavior - but I cannot easily report the dereference location even if it is in a system header but the pointer is _not_ from a system header -- which is probably what would be wanted here. So, t.h: #pragma GCC system_header inline float deref_float (float *p) { return *p; } t.C: #include "t.h" float transform(int i) { return deref_float ((float *)&i); } _should_ emit a warning? Even if it looks like t.h: In function 'float transform(int)': t.h:3: warning: dereferencing pointer 'i.0' does break strict-aliasing rules t.C:5: note: initialized from here ? IMHO we want to warn unless _both_, the declaration and the dereference is in a system header. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-12 14:25:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug testsuite/38790] syntax error in target selector
--- Comment #2 from joel at gcc dot gnu dot org 2009-01-12 14:23 --- It is not appearing here: (powerpc-aix) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01087.html or (powerpc-darwin) http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01077.html so it is fixed. Sorry for missed commit. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38790
[Bug testsuite/38790] syntax error in target selector
--- Comment #1 from joel at gcc dot gnu dot org 2009-01-12 14:20 --- Is this still happening? I accidentally did not commit the change to lib/target-supports.exp and did it over the weekend (Saturday?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38790
[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names
--- Comment #11 from markus dot schoepflin at comsoft dot de 2009-01-12 14:17 --- Here is the result of using -### instead of -v: scho...@area51:~/local/src/tests/gcc/4605> /opt/gcc-4.3.2/bin/gcc -### -c hello.c -o 'dir test/hello.o'Using built-in specs. Target: alphaev56-dec-osf5.1b Configured with: /net/homes/schoepf/local/src/gcc-4.3.2/configure --prefix=/opt/gcc-4.3.2 --enable-languages=c,c++,ada --with-mpfr=/opt/mpfr-2.3.1 --with-gmp=/opt/gmp-4.2.2 : (reconfigured) /net/homes/schoepf/local/src/gcc-4.3.2/configure --prefix=/opt/gcc-4.3.2 --enable-languages=c,c++,ada --with-mpfr=/opt/mpfr-2.3.1 --with-gmp=/opt/gmp-4.2.2 --disable-nls Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56' "/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/alphaev56-dec-osf5.1b/4.3.2/cc1" "-quiet" "-iprefix" "/vol2/opt/gcc-4.3.2/bin/../lib/gcc/alphaev56-dec-osf5.1b/4.3.2/" "hello.c" "-quiet" "-dumpbase" "hello.c" "-mcpu=ev56" "-auxbase-strip" "dir test/hello.o" "-o" "/tmp//ccLLEdGT.s" COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56' "as" "-g" "-oldas" "-c" "-nocpp" "-O0" "-o" "dir test/hello.o" "/tmp//ccLLEdGT.s" COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56' "/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/alphaev56-dec-osf5.1b/4.3.2/mips-tfile" "-o" "dir test/hello.o" "/tmp//ccLLEdGT.s" COMPILER_PATH=/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/alphaev56-dec-osf5.1b/4.3.2/:/vol2/opt/gcc-4.3.2/bin/../libexec/gcc/ LIBRARY_PATH=/vol2/opt/gcc-4.3.2/bin/../lib/gcc/alphaev56-dec-osf5.1b/4.3.2/:/vol2/opt/gcc-4.3.2/bin/../lib/gcc/:/usr/lib/cmplrs/cc/:/vol2/opt/gcc-4.3.2/bin/../lib/gcc/alphaev56-dec-osf5.1b/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-c' '-o' 'dir test/hello.o' '-mcpu=ev56' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605