[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - /dev/null'
--- Comment #9 from patriciak784-gccmainling at yahoo dot de 2009-01-05 08:43 --- I don't think it's good to apply the workaround mainly because 3.4.5 works for me on mingw and the code that triggers the error hasn't changed since its initial commit which was more than 5 years ago. I assume that in 3.4.5, every empty input file gets an empty buffer instead of none which is what happens at the moment in 4.3 or something like that... So if my assumption is true, the code that does that buffer handling would need to copy the old behaviour... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215
[Bug middle-end/38729] long time needed in tree canonical iv
--- Comment #1 from jv244 at cam dot ac dot uk 2009-01-05 16:18 --- Created an attachment (id=17033) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17033action=view) testcase gfortran -O1 -fbounds-check -ftime-report PR38729.f90 to reproduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38729
[Bug c++/38702] [4.4 regression] ICE with defaulted operator
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38702
[Bug middle-end/38729] New: long time needed in tree canonical iv
The to-be-attached testcase takes about 10s to compile at '-O0 -fbounds-check', 30s at '-O2 -fbounds-check' while it requires about 300s at '-O1 -fbounds-check' The time report shows that at -O1 about 80% of the time is in 'tree canonical iv : 244.29 (82%) usr' -- Summary: long time needed in tree canonical iv Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: compile-time-hog 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=38729
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #6 from pault at gcc dot gnu dot org 2009-01-05 16:32 --- (In reply to comment #1) Assuming no local problems and a clean tree (looks like), the following commit might have caused the regression: r130257 | fxcoudert | 2007-11-17 14:46:53 +0100 (Sat, 17 Nov 2007) | 6 lines http://gcc.gnu.org/viewcvs?view=revrevision=130257 PR fortran/30285 * module.c (struct written_common, written_commons): New structure. (compare_written_commons, free_written_common, write_common_0): New functions. (write_common): Call recursive function write_common_0. I have been tinkering with this and have made the above testcase work. However, legal cases that rename TESTCHAR on USE test3 (with appropriate PUBLIC statements of course) are failing. I am preparing a large envelope to track what happens to the names. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #7 from pault at gcc dot gnu dot org 2009-01-05 17:35 --- I'm just about to post a patch. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-02 19:04:21 |2009-01-05 17:35:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug rtl-optimization/38495] [4.4 Regression] ACATS tests cxa4004 cxa4005 cxa4026 fail
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38495
[Bug c/38730] New: gcc 4.4.0 20090104 - make -i check - over 60 FAILs in C compiler
On i386-pc-solaris2.11 (OpenSolaris) I built gcc 4.4.0 20090104 (with Graphite). # /usr/local/bin/g++ -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --enable-nls --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090104 (experimental) (GCC) When I run make -i check I get over 60 FAILs / XPASSes in C compiler. The C compiler is an __essential__ part of building the gcc toolchain and any errors will simply propagate into the other languages and stages; making all the testsuites invalid. While I am not convinced that this huge number of errors has ruined all hope of anything working (as it has not) the amount and the area where they occur is what concerns me. There are also more errors in the Ada compiler than we want to see but I don't want to comment on how many they would let pass. Fixing _all_ these errors will likely fix _some_ of the other errors _and_ will allow us to have more certainty of the rest of the testsuites. Making this a P1 for 4.5 . -- Test Run By user on Mon Jan 5 05:03:34 2009 Native configuration is i386-pc-solaris2.11 === gcc tests === ... FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/copysign1.c execution, -Os ... FAIL: gcc.dg/dfp/func-vararg-mixed-2.c (test for excess errors) WARNING: gcc.dg/dfp/func-vararg-mixed-2.c compilation failed to produce executable Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/dg.exp ... XPASS: gcc.dg/ucnid-2.c (test for excess errors) XPASS: gcc.dg/ucnid-3.c (test for excess errors) XPASS: gcc.dg/ucnid-4.c (test for excess errors) ... Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/pch/pch.exp ... FAIL: largefile.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -O0 -g assembly comparison FAIL: largefile.c -O0 -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -O0 assembly comparison FAIL: largefile.c -O1 -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -O1 assembly comparison FAIL: largefile.c -O2 -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -O2 assembly comparison FAIL: largefile.c -O3 -fomit-frame-pointer -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -O3 -fomit-frame-pointer assembly comparison FAIL: largefile.c -O3 -g -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -O3 -g assembly comparison FAIL: largefile.c -Os -I. (test for excess errors) FAIL: gcc.dg/pch/largefile.c -Os assembly comparison Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/special/mips-abi.exp ... ... Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/torture/dg-torture.exp ... FAIL: gcc.dg/torture/fp-int-convert-float128.c -O0 (test for excess errors) WARNING: gcc.dg/torture/fp-int-convert-float128.c -O0 compilation failed to produce executable FAIL: gcc.dg/torture/fp-int-convert-float128.c -O1 (test for excess errors) WARNING: gcc.dg/torture/fp-int-convert-float128.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/fp-int-convert-float128.c -O2 (test for excess errors) WARNING: gcc.dg/torture/fp-int-convert-float128.c -O2 compilation failed to produce executable FAIL: gcc.dg/torture/fp-int-convert-float128.c -O3 -fomit-frame-pointer (test for excess errors) WARNING: gcc.dg/torture/fp-int-convert-float128.c -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: gcc.dg/torture/fp-int-convert-float128.c -O3 -g (test for excess errors) WARNING: gcc.dg/torture/fp-int-convert-float128.c -O3 -g compilation failed to produce executable FAIL: gcc.dg/torture/fp-int-convert-float128.c -Os (test for excess errors) WARNING: gcc.dg/torture/fp-int-convert-float128.c -Os compilation failed to produce executable Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/torture/stackalign/stackalign.exp ... Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp ... Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized link_error 0 FAIL: gcc.dg/tree-ssa/ltrans-1.c scan-tree-dump-times ltrans converted loop nest to perfect loop nest 1 FAIL: gcc.dg/tree-ssa/ltrans-1.c scan-tree-dump-times ltrans transformed loop 1 FAIL: gcc.dg/tree-ssa/ltrans-3.c scan-tree-dump-times ltrans transformed loop 1 FAIL: gcc.dg/tree-ssa/ltrans-4.c scan-tree-dump-times ltrans transformed loop 1 FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times ltrans transformed loop 1 FAIL: gcc.dg/tree-ssa/ltrans-6.c scan-tree-dump-times ltrans transformed loop 1 FAIL: gcc.dg/tree-ssa/ltrans-8.c scan-tree-dump-times ltrans transformed loop 1 FAIL:
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-01-05 17:52 --- (In reply to comment #8) Seems to work on 4.3.2-1 Debian gnueabi You didn't compile your testcase with -mthumb. Also, that system should be using unwinding tables for exceptions, rather than builtin_setjmp and friends, so it's probably not relevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
[Bug c++/38702] [4.4 regression] ICE with defaulted operator
--- Comment #3 from jason at gcc dot gnu dot org 2009-01-05 17:52 --- Subject: Bug 38702 Author: jason Date: Mon Jan 5 17:52:18 2009 New Revision: 143081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143081 Log: PR c++/38701 * decl.c (cp_finish_decl): Clear DECL_INITIAL for invalid defaulting. PR c++/38702 * class.c (defaultable_fn_p): Only operator== can be a copy assignment operator. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38702
[Bug c++/38701] [4.4 regression] ICE with defaulted function
--- Comment #3 from jason at gcc dot gnu dot org 2009-01-05 17:52 --- Subject: Bug 38701 Author: jason Date: Mon Jan 5 17:52:18 2009 New Revision: 143081 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143081 Log: PR c++/38701 * decl.c (cp_finish_decl): Clear DECL_INITIAL for invalid defaulting. PR c++/38702 * class.c (defaultable_fn_p): Only operator== can be a copy assignment operator. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38701
[Bug c++/38701] [4.4 regression] ICE with defaulted function
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-05 17:52 --- Subject: Bug 38701 Author: jason Date: Mon Jan 5 17:52:35 2009 New Revision: 143082 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143082 Log: PR c++/38701 * decl.c (cp_finish_decl): Clear DECL_INITIAL for invalid defaulting. PR c++/38702 * class.c (defaultable_fn_p): Only operator== can be a copy assignment operator. Modified: trunk/gcc/cp/cp-tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38701
[Bug c++/38702] [4.4 regression] ICE with defaulted operator
--- Comment #4 from jason at gcc dot gnu dot org 2009-01-05 17:52 --- Subject: Bug 38702 Author: jason Date: Mon Jan 5 17:52:35 2009 New Revision: 143082 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143082 Log: PR c++/38701 * decl.c (cp_finish_decl): Clear DECL_INITIAL for invalid defaulting. PR c++/38702 * class.c (defaultable_fn_p): Only operator== can be a copy assignment operator. Modified: trunk/gcc/cp/cp-tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38702
[Bug target/38682] [4.4 Regression] speed regression with sse intrinsics and -ffast-math
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38682
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
--- Comment #2 from laurent at guerby dot net 2009-01-05 15:09 --- Mike Stein builds a cross compiler from x86_64 to arm-elf and see pr37433.c ICE: http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00247.html configure flags: --target=arm-elf --prefix=/home/mstein/cross-local/arm-elf --enable-languages=c --disable-nls --disable-build-warnings --with-sysroot=/home/mstein/cross-local/arm-elf --with-build-sysroot=/home/mstein/cross-local/arm-elf --with-ld=/home/mstein/cross-local/arm-elf/usr/bin/ld --with-as=/home/mstein/cross-local/arm-elf/usr/bin/as --disable-libssp --with-mpfr=/opt/cfarm/mpfr-2.3.1 This would seem to rule out an ARM native miscompile He is running his builds on the compile farm machine gcc14, let me know if you want an account: http://gcc.gnu.org/wiki/CompileFarm -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38695
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-05 14:35 ---
(In reply to comment #2)
The .mod looks OK though - as far I can see (rearrangements; only one
testcommon1 etc. instead of two).
The test2.mod is wrong I think.
Without USE TEST3:
[...]
(('testcommon1' 2 0 0 'testcommon1') ('testcommon2' 3 0 0 'testcommon2')
('testcommon3' 4 0 0 'testcommon3'))
()
(2 'testchar' 'test2' 'testchar' 1 ((VARIABLE UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN IN_COMMON) (CHARACTER 1 0 0 CHARACTER ((
CONSTANT (INTEGER 4 0 0 INTEGER ()) 0 '80'))) 0 0 () () 0 () () () 0 0)
3 'testint' 'test2' 'testint' 1 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN IN_COMMON) (INTEGER 4 0 0 INTEGER ()) 0 0 () () 0 () ()
() 0 0)
4 'testreal' 'test2' 'testreal' 1 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN IN_COMMON) (REAL 4 0 0 REAL ()) 0 0 () () 0 () () () 0 0)
)
('testchar' 0 2)
With USE TEST3:
[...]
(('testcommon1' 2 0 0 'testcommon1') ('testcommon2' 3 0 0 'testcommon2')
('testcommon3' 4 0 0 'testcommon3'))
()
(5 'testchar' 'test2' 'testchar' 1 ((VARIABLE UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN IN_COMMON) (CHARACTER 1 0 0 CHARACTER ((
CONSTANT (INTEGER 4 0 0 INTEGER ()) 0 '80'))) 0 0 () () 0 () () () 0 0)
3 'testint' 'test3' 'testint' 1 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN IN_COMMON) (INTEGER 4 0 0 INTEGER ()) 0 0 () () 0 () ()
() 0 0)
2 'testchar' 'test3' 'testchar' 1 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN IN_COMMON) (CHARACTER 1 0 0 CHARACTER ((CONSTANT (
INTEGER 4 0 0 INTEGER ()) 0 '80'))) 0 0 () () 0 () () () 0 0)
4 'testreal' 'test3' 'testreal' 1 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC
UNKNOWN UNKNOWN IN_COMMON) (REAL 4 0 0 REAL ()) 0 0 () () 0 () () () 0 0)
)
('testchar' 0 5)
With USE TEST3, testreal, testint and testchar are included from module test3,
which is wrong because everything is private in test3. We should either have
variables from both test2 and test3, or only variables from test2. Furthermore,
the 'testcommon1' common refers to 2, which is the wrong testchar (that from
test3).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-05 14:18 ---
If one compares the dumps, one finds an additional
+ extern character(kind=1) testchar[1:80];
in the failing version. Thus while the working version accesses
testcommon1.testchar[1]{lb: 1 sz: 1}
the failing uses
testchar[1]{lb: 1 sz: 1}
The .mod looks OK though - as far I can see (rearrangements; only one
testcommon1 etc. instead of two).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-05 14:14 --- (In reply to comment #3) Please can someone test on older revisions/provide more information? The test passes with gfortran 4.2.3, but not 4.3.2 on powerpc-apple-darwin9. Hence it is a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug c++/38702] [4.4 regression] ICE with defaulted operator
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-05 18:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38702
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #5 from mikael at gcc dot gnu dot org 2009-01-05 14:54 --- (In reply to comment #4) With USE TEST3, sym-backend_decl is not set. Interestingly, the backend_decl for test3's testchar is set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-05 13:54 --- The executable aborts on powerpc-apple-darwin9 (r143074) when compiled with -m32, but passes when compiled with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug c++/38701] [4.4 regression] ICE with defaulted function
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-05 18:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38701
[Bug target/38326] [4.3/4.4 regression] libjava build failure on ia64-linux-gnu
--- Comment #7 from doko at ubuntu dot com 2009-01-05 18:33 --- Can you reproduce it with vanilla trunk? yes. now, building with binutils 2.18 and glibc-2.7 lets the build succeed, building with binutils-2.19 and glibc-2.9 (Ubuntu jaunty) lets the build fail. I'm trying next to update just one of binutils and glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
--- Comment #10 from drow at gcc dot gnu dot org 2009-01-05 18:34 --- Right. You would need an arm-elf (not arm-eabi) or arm-linux (not arm-linux-gnueabi) toolchain to test this. Those are slowly becoming obsolete... -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-07-02 01:31:50 |2009-01-05 18:34:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2009-01-05 18:34 --- Subject: Re: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX pinskia at gcc dot gnu dot org writes: Does this happen still? I'm pretty sure it does, though I've got the workarounds from Comment #10 in my tree to be able to test on the platform at all. Unfortunately, Jan hasn't yet worked on this, although he introduced both parts of this regressions (and it can be reproduced in a cross compiler). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug tree-optimization/38593] [4.4 regression] ICE: verify_gimple failed
--- Comment #8 from doko at ubuntu dot com 2009-01-05 18:37 --- Created an attachment (id=17034) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17034action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593
[Bug fortran/38726] [4.3/4.4 Regression] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #8 from mikael at gcc dot gnu dot org 2009-01-05 18:44 --- Subject: Bug 38726 Author: mikael Date: Mon Jan 5 18:44:09 2009 New Revision: 143084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143084 Log: 2009-01-05 Mikael Morin mikael.mo...@tele2.fr PR fortran/38669 PR fortran/38726 * gfortran.dg/elemental_subroutine_7.f90: Fix p values so that it can be used as vector subscript. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug fortran/38669] [4.3/4.4 Regression] Array bounds violation for arguments of elemental subroutine
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-05 18:44 --- Subject: Bug 38669 Author: mikael Date: Mon Jan 5 18:44:09 2009 New Revision: 143084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143084 Log: 2009-01-05 Mikael Morin mikael.mo...@tele2.fr PR fortran/38669 PR fortran/38726 * gfortran.dg/elemental_subroutine_7.f90: Fix p values so that it can be used as vector subscript. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38669
[Bug c++/29388] [4.2/4.3/4.4 regression] ICE with invalid nested name specifier
--- Comment #9 from sje at cup dot hp dot com 2009-01-05 18:46 --- I found the same fix earlier and submitted a patch but forgot to update the PR which is probably why you didn't notice it. http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00663.html My patch doesn't check for namespace (just class) so I think your patch is better. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug fortran/38726] [4.3/4.4 Regression] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #7 from mikael at gcc dot gnu dot org 2009-01-05 15:08 --- (In reply to comment #6) If compiled with -fbounds-check, the executable yields: At line 29 of file /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Fortran runtime error: Array reference out of bounds for array 'p', lower bound of dimension 1 exceeded(-2 1) The problem comes from ... p = 20 * r - 10 ... call tq_tvgh (q(k_lev:), (p(p(k_lev: if (any (p(p) /= q)) call abort where min(p)=-10, outside the bounds of p(1:42). If I use ' p = 41 * r + 1', the test passes. Yes, of course. Stupid me. I started with the random thing, and I added the vector subscript later. Thanks Dominique. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.3 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug c++/38698] [4.4 regression] ICE initializing union with initializer list
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38698
[Bug libgomp/38086] [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver
--- Comment #2 from rob1weld at aol dot com 2009-01-05 17:07 --- I noticed this is a P1. Rainer Orth says: Building current mainline on Solaris 11/SPARC with GNU ld 2.19 and Sun as fails when building libgomp: The Official Position of Sun is: You must use Sun's ld. Andrew, on that basis you _might_ want to mark this Bug Report as INVALID. The Reporter is (according to the Manufacturer of his Operating System) trying to configure a compiler (to interface with Sun's Operating System) in a manner that in not supported. For that reason this should not be a P1 - but it should be fixed nonetheless. You are allowed to do it, it just is not recommended, and thus should this be a P1 ? I (like Rainer) compiled gcc (but it is a more recent version) using binutils 2.19 ld and I _also_ used binutils 2.19 as (unlike what Rainer did). I am also configuring the compiler in a manner that in not supported by Sun, but it _is_ supported by GNU; and that is what I am testing. NOTE: There is a reason (for Sun) to recommend the use of Sun's ld and no reason (for us) to require Sun's as be used. That statement is even more true if you are using binutils 2.19 ld (and thus have 'as' version 2.19) and not using Sun's ld (as is recommended). The only exception to this would either be to: 1. Test using binutils 2.19 ld instead of Sun's ld (which is NOT recommended (by Sun) and uncommented on, but permitted by GNU). 2. Try something that is not recommended and get it to work. I (who have a few years of building / porting GCC) can build gcc 4.4.0 20090104 on i386-pc-solaris2.11 (OpenSolaris 2008.11) this way: # /usr/local/bin/ld --version | grep Binutils GNU ld (GNU Binutils) 2.19 # /usr/local/bin/as --version | grep Binutils GNU ld (GNU Binutils) 2.19 # /usr/local/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --enable-nls --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090104 (experimental) (GCC) I have built gcc previously using --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld (that is a portion of Sun's recommended configure argument list) and libgomp built correctly using Sun's as so, Andrew, I believe this regression goes back only as far as 4.2.1 . Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38086
[Bug middle-end/36201] [4.4 Regression] NVR in the front-end causes missed optimization later on (retval thought to alias arguments)
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-05 11:19 ---
Fixed on the alias-improvements branch:
a f(a, a) (struct a g, struct a h)
{
long long int pretmp.24;
bb 2:
# .MEM_12 = VDEF .MEM_11(D)
retval = *g;
# VUSE .MEM_12
pretmp.24 = h-b;
# .MEM_7 = VDEF .MEM_12
retval.b = [plus_expr] (pretmp.24 + retval.b) + pretmp.24 * 1023;
# VUSE .MEM_7
return retval;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||37696
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36201
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-05 14:56 --- Can't reproduce with a cross and can't think of how you could get there a STRING_CST in a place of fndecl - get_callee_fndecl can't return STRING_CST, it either returns a FUNCTION_DECL or NULL. Of course unless cc1 is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38695
[Bug fortran/38669] [4.3/4.4 Regression] Array bounds violation for arguments of elemental subroutine
--- Comment #8 from mikael at gcc dot gnu dot org 2009-01-05 13:37 --- (In reply to comment #7) It caused PR 38726 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38669
[Bug tree-optimization/37194] [4.3/4.4 Regression] Autovectorization of small constant iteration loop degrades performance
--- Comment #8 from irar at il dot ibm dot com 2009-01-05 13:58 --- To handle unknown alignment of data, the vectorizer creates a prolog loop to peel a statically unknown number of scalar iterations (0=nVF). This loop is followed by a vectorized loop (with the remaining, multiple of VF, number of iterations), and an epilog scalar loop that completes the iterations that were not executed (0=nVF). Therefore, the created scalar loops have unknown number of iterations, which prevents their unrolling (while the original scalar loop is unrolled). Vectorizer cost model does not take possible unrolling into account. Another cost model problem is that the calculation of scalar outside cost for this case is performed not for the original scalar version, but includes run-time guards. Which seems to be wrong in case that the original loop bound is known. I am going to submit a patch to fix that. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37194
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #14 from laurent at guerby dot net 2009-01-05 12:05 ---
Something like that? (untested)
Index: configure.ac
===
--- configure.ac(revision 143046)
+++ configure.ac(working copy)
@@ -2904,6 +2904,9 @@
else
stage1_checking=--enable-checking=$enable_checking,types
fi])
+case ${host} in
+ arm*-*-linux-gnueabi) stage1_checking=--enable-checking=release;;
+esac
AC_SUBST(stage1_checking)
# Enable -Werror in bootstrap stage2 and later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug rtl-optimization/38722] [4.4 Regression] Revision 143027 causes ICE in find_decomposable_subregs
--- Comment #16 from tkoenig at gcc dot gnu dot org 2009-01-05 11:08 --- Reduced test case - works on i686-pc-linux-gnu for all optimization levels - works with -m32 on x86-64-unknown-linux-gnu - works with 4.3.2 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86-64-unknown-linux-gnu| Known to work|4.3.1 |4.3.1 4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-01-05 11:24:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug tree-optimization/34034] perlbmk hangs with -O2 -fno-tree-dce -fno-tree-dominator-opts
--- Comment #4 from janis at gcc dot gnu dot org 2009-01-05 19:10 --- The powerpc testcase and perlbmk now pass when compiled with the options that used to cause them to hang, for both the current 4.3 branch and mainline, so let's call this fixed. If anyone cares I can find out which patch fixed the problem. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34034
[Bug libstdc++/38631] [4.4 Regression] libstdc++ from gcc 4.4 causes OpenOffice.org 3.0 to crash on startup
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
--- Comment #3 from laurent at guerby dot net 2009-01-05 15:38 ---
jakub guerby: I guess the interesting thing is how could non-NULL be passed
there, step through expand_call and see if get_callee_fndecl returned non-NULL
or where fndecl became non-NULL
guerby fndecl seems to be NULL
guerby Breakpoint 4, emit_call_1 (funexp=0x2b02a840,
fntree=0x2af4aa50, fndecl=0x0, funtype=0x2af6dd80, stack_size=0,
rounded_stack_size=0, struct_value_size=140737488347167, next_arg_reg=0x0,
guerby valreg=0x5e94c7, old_inhibit_defer_pop=-1426709664,
call_fusage=0x17, ecf_flags=-1426820016, args_so_far=0x0) at
/home/mstein/svn/trunk/gcc/calls.c:249
guerby jakub most targets file use TREE_CODE (exp) == VAR_DECL
DECL_SECTION_NAME (exp)
guerby instead of directly DECL_SECTION_NAME (exp) as
arm.c:arm_function_in_section_p does
/* Return true if DECL is known to be linked into section SECTION. */
static bool
arm_function_in_section_p (tree decl, section *section)
{
/* We can only be certain about functions defined in the same
compilation unit. */
if (!TREE_STATIC (decl))
return false;
/* Make sure that SYMBOL always binds to the definition in this
compilation unit. */
if (!targetm.binds_local_p (decl))
return false;
/* If DECL_SECTION_NAME is set, assume it is trustworthy. */
if (!DECL_SECTION_NAME (decl))
{
/* Make sure that we will not create a unique section for DECL. */
if (flag_function_sections || DECL_ONE_ONLY (decl))
return false;
}
return function_section (decl) == section;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38695
[Bug target/38695] [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.2 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38695
[Bug fortran/38672] [4.3/4.4 Regression] ICE during build with versions 4.3.2 and 4.4-20081226
--- Comment #7 from tkoenig at gcc dot gnu dot org 2009-01-05 10:43 --- Subject: Bug 38672 Author: tkoenig Date: Mon Jan 5 10:43:39 2009 New Revision: 143074 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143074 Log: 2009-01-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/38672 * trans-types.c (gfc_get_derived_type): Check for the presence of derived-ns-proc_name before accessing derived-ns-proc_name-attr.flavor . * resolve.c (resolve_symbol): Likewise. 2009-01-05 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/38672 * gfortran.dg/host_assoc_blockdata_1.f90: New test. * gfortran.dg/host_assoc_blockdata_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/host_assoc_blockdata_1.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_blockdata_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
[Bug target/38326] [4.3/4.4 regression] libjava build failure on ia64-linux-gnu
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-05 11:54 --- Can you reproduce it with vanilla trunk? I've certainly bootstrapped/regtested the trunk on ia64-linux several times recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
[Bug fortran/37159] RANDOM_SEED: GET= check array size at compile time and respect -fdefault-integer-*
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-01-05 19:34 --- Subject: Bug 37159 Author: dfranke Date: Mon Jan 5 19:34:02 2009 New Revision: 143089 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143089 Log: gcc/fortran: 2009-01-05 Daniel Franke franke.dan...@gmail.com PR fortran/37159 * check.c (gfc_check_random_seed): Added size check for GET dummy argument, reworded error messages to follow common pattern. gcc/testsuite: 2009-01-05 Daniel Franke franke.dan...@gmail.com PR fortran/37159 * gfortran.dg/random_seed_1.f90: Updated. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/random_seed_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37159
[Bug c++/38472] [4.4 Regression] Wrong result type of ternary operator
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-28 22:39:11 |2009-01-05 19:34:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38472
[Bug tree-optimization/38721] [alias-improvements] vectorizer miscompiles gfortran.fortran-torture/execute/elemental.f90 at -O3
--- Comment #1 from irar at il dot ibm dot com 2009-01-05 13:19 --- Here is a reduced testcase: program test_elemental implicit none integer, dimension (2, 4) :: a integer, dimension (2, 4) :: b integer(kind = 8), dimension(2) :: c a = reshape ((/2, 3, 4, 5, 6, 7, 8, 9/), (/2, 4/)) b = 0 a = e_fn (a(:, 4:1:-1), 1 + b) ! This tests intrinsic elemental conversion functions. c = 2 * a(1, 1) if (any (c .ne. 14)) call abort ! This triggered bug due to building ss chains in the wrong order. b = 0; a = a - e_fn (a, b) if (any (a .ne. 0)) call abort contains elemental integer(kind=4) function e_fn (p, q) integer, intent(in) :: p, q e_fn = p - q end function end program The problem is that dse2 removes the stores to array A.4 which is used by the vectorized code: A.4[0] = D.1635_155; ... A.4[7] = D.1635_165; vect_pA.67_156 = (vector integer(kind=4) *) A.4; vect_pa.73_197 = (vector integer(kind=4) *) a; vect_var_.68_254 = *vect_pA.67_156; *vect_pa.73_197 = vect_var_.68_254; vect_pA.63_256 = vect_pA.67_156 + 16; vect_pa.69_257 = vect_pa.73_197 + 16; vect_var_.68_170 = *vect_pA.63_256; *vect_pa.69_257 = vect_var_.68_170; We propagate alias info from the scalar to vector ref in vect_create_data_ref_ptr() (in tree-vect-transform.c): /** (2) Add aliasing information to the new vector-pointer: (The points-to info (DR_PTR_INFO) may be defined later.) **/ tag = DR_SYMBOL_TAG (dr); gcc_assert (tag); /* If tag is a variable (and NOT_A_TAG) than a new symbol memory tag must be created with tag added to its may alias list. */ if (!MTAG_P (tag)) new_type_alias (vect_ptr, tag, DR_REF (dr)); else set_symbol_mem_tag (vect_ptr, tag); Those lines do not exist on the branch. Do you take care of this somewhere else? Ira -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-05 13:19:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38721
[Bug c++/38701] [4.4 regression] ICE with defaulted function
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38701
[Bug c++/38725] [4.4 regression] ICE with goto
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38725
[Bug middle-end/38299] internal error: segmentation fault
--- Comment #3 from grant dot b dot edwards at gmail dot com 2009-01-05 19:40 --- I've just run across the exact same problem using 3.4.4 to build an arm-elf 3.2.1 cross-compiler on Cygwin. Building the same exact same compiler using 3.4.6 on Linux works fine, so it appears to be something Cygwin-specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-05 13:58 --- (In reply to comment #0) On Linux/ia64, revision 143058 gave FAIL: gfortran.dg/elemental_subroutine_7.f90 -O0 execution test According to the gcc-testresults mailing list, this is confirmed on powerpc-ibm-aix5.3.0.0, ia64-unknown-linux-gnu, powerpc-apple-darwin8.5.0. It's not really a regression though, as I introduced the failing testcase as part of revision 143057. Please can someone test on older revisions/provide more information? Without access to such machines, it will be hard to find the culprit. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-05 13:58:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug fortran/38672] [4.3 Regression] ICE during build with versions 4.3.2 and 4.4-20081226
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-01-05 10:46 --- Fixed on trunk, will wait for a few days before committing to 4.3. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 Known to work||4.4.0 Summary|[4.3/4.4 Regression] ICE|[4.3 Regression] ICE during |during build with versions |build with versions 4.3.2 |4.3.2 and 4.4-20081226 |and 4.4-20081226 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #8 from pault at gcc dot gnu dot org 2009-01-05 19:46 --- Subject: Bug 38657 Author: pault Date: Mon Jan 5 19:46:06 2009 New Revision: 143090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143090 Log: 2009-01-05 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * module.c (write_common_0): Use the name of the symtree rather than the common block, to determine if the common has been written. 2009-01-05 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * gfortran.dg/module_commons_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/module_commons_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38657] [4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #9 from pault at gcc dot gnu dot org 2009-01-05 19:47 --- Trunk done, 4.3 to come! Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression]|[4.3 Regression] |PUBLIC/PRIVATE Common blocks|PUBLIC/PRIVATE Common blocks http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug target/38731] New: Local strings on the stack not aligned
String variables allocated on the stack on not aligned. -- Summary: Local strings on the stack not aligned Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: powerpc*-*-* GCC host triplet: powerpc*-*-* GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug middle-end/38587] psim miscompiled #2 [regression]
--- Comment #3 from joel at gcc dot gnu dot org 2009-01-05 14:32 --- Issue appears to have been independently resolved as of: gcc (GCC) 4.4.0 20090105 (experimental) [trunk revision 143068] I will make a full test run on the powerpc to make sure and close this if that run is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
[Bug target/38731] Local strings on the stack not aligned
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-05 19:51 --- Mine. The patch in testing: Index: rs6000/rs6000.h === --- rs6000/rs6000.h (revision 143086) +++ rs6000/rs6000.h (working copy) @@ -613,13 +613,7 @@ extern int rs6000_xilinx_fpu; local store. TYPE is the data type, and ALIGN is the alignment that the object would ordinarily have. */ #define LOCAL_ALIGNMENT(TYPE, ALIGN) \ - ((TARGET_ALTIVEC TREE_CODE (TYPE) == VECTOR_TYPE) ? 128 : \ -(TARGET_E500_DOUBLE\ - TYPE_MODE (TYPE) == DFmode) ? 64 : \ -((TARGET_SPE TREE_CODE (TYPE) == VECTOR_TYPE \ - SPE_VECTOR_MODE (TYPE_MODE (TYPE))) || (TARGET_PAIRED_FLOAT \ - TREE_CODE (TYPE) == VECTOR_TYPE \ - PAIRED_VECTOR_MODE (TYPE_MODE (TYPE ? 64 : ALIGN) + DATA_ALIGNMENT (TYPE, ALIGN) /* Alignment of field after `int : 0' in a structure. */ #define EMPTY_FIELD_BOUNDARY 32 -- 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-05 19:51:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug testsuite/38727] gcc 4.4.0 20090104 - make -i check autogen fixinclude test FAILURES
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-05 19:44 --- This is only a testsuite issue really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||01/msg00195.html Status|UNCONFIRMED |NEW Component|bootstrap |testsuite Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2009-01-05 19:44:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38727
[Bug target/38731] Local strings on the stack not aligned
--- Comment #2 from dje at gcc dot gnu dot org 2009-01-05 19:54 --- For example, the following, when declared locally: typedef char Str_30 [31]; Str_30 Str_1_Par_Ref; Str_30 Str_2_Par_Ref; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug rtl-optimization/38426] [4.4 Regression] Incorrect code produced with -momit-leaf-frame-pointer -fno-unit-at-a-time
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38426
[Bug bootstrap/38727] New: gcc 4.4.0 20090104 - make -i check autogen fixinclude test FAILURES
The autogen program (Ver. 5.7) finds fixinclude test failures. # /usr/local/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --enable-nls --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090104 (experimental) (GCC) # make -i check gmake[1]: Entering directory `/usr/share/src/gcc_build' gmake[2]: Entering directory `/usr/share/src/gcc_build/fixincludes' autogen -T ../../gcc_trunk/fixincludes/check.tpl ../../gcc_trunk/fixincludes/inclhack.def /bin/sh ./check.sh ../../gcc_trunk/fixincludes/tests/base Fixed: testing.h Fixed: testing.h Fixed: */sys/getppdp.h Fixed: AvailabilityMacros.h Fixed: X11/ShellP.h ... Fixed: tinfo.h Fixed: types/vxTypesBase.h Fixed: unistd.h Fixed: wchar.h */sys/getppdp.h /usr/share/src/gcc_trunk/fixincludes/tests/base/ia64/sys/getppdp.h differ: char 98, line 5 *** */sys/getppdp.h Mon Jan 5 05:03:21 2009 --- /usr/share/src/gcc_trunk/fixincludes/tests/base/ia64/sys/getppdp.h Thu Jan 1 14:09:22 2009 *** *** 2,8 It has been auto-edited by fixincludes from: ! fixinc/tests/inc/*/sys/getppdp.h This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ --- 2,8 It has been auto-edited by fixincludes from: ! fixinc/tests/inc/ia64/sys/getppdp.h This had to be done to correct non-standard usages in the original, manufacturer supplied header file. */ Newly fixed header: locale.h Newly fixed header: stdarg.h Missing header fix: ia64/sys/getppdp.h There were fixinclude test FAILURES gmake[2]: [check] Error 1 (ignored) gmake[2]: Leaving directory `/usr/share/src/gcc_build/fixincludes' gmake[2]: Entering directory `/usr/share/src/gcc_build/gcc' Making a new config file... echo set tmpdir /usr/share/src/gcc_build/gcc/testsuite ./tmp0 gmake[3]: Entering directory `/usr/share/src/gcc_build/gcc' # slocate sys/getppdp.h /usr/share/src/gcc_trunk/fixincludes/tests/base/ia64/sys/getppdp.h /usr/share/src/gcc_build/fixincludes/tests/res/*/sys/getppdp.h /usr/share/src/gcc_build/fixincludes/tests/inc/*/sys/getppdp.h I don't know why the scripts created the * directories in: /usr/share/src/gcc_build/fixincludes/tests/???/x . # ls -l /usr/share/src/gcc_build/fixincludes/tests/res/ | head -3 total 174 drwxr-xr-x 3 root root 3 Jan 5 05:03 * drwxr-xr-x 2 root root 4 Jan 5 05:03 ansi There must be a better choice for the directory name, other than * ? Rob -- Summary: gcc 4.4.0 20090104 - make -i check autogen fixinclude test FAILURES Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38727
[Bug other/38732] New: Openoffice.org segfaults with runtime libs built from GCC trunk
[forwarded from http://bugs.debian.org/504323] Stephan Bergmann writes: Reproducing with libstdc++.so.6 and libgcc_s.so.1 from gcc-4.4-20090102 in unxlngi6.pro DEV300m38 OOo, the problem is that OOo at http://svn.services.openoffice.org/ooo/tags/DEV300_m38/bridges/source/cpp_uno/gcc3_linux_intel/share.hxx l. 52 assumes a layout of struct __cxa_exception as given in section 2.2.1 of http://www.codesourcery.com/public/cxx-abi/abi-eh.html, while GCC 4.4 added a new member _Atomic_word referenceCount; to the start of the struct at gcc-4.4-20090102/libstc++-v3/libsupc++/unwind-cxx.h l. 57. OOo tries to get at information stored in the __cxa_exception header in the destructor function passed to __cxa_throw (function deleteException at http://svn.services.openoffice.org/ooo/tags/DEV300_m38/bridges/source/cpp_uno/gcc3_linux_intel/except.cxx l. 213), which now fails. Please somebody clarify if GCC 4.4 adding a new member to struct __cxa_exception (and thus deviating from http://www.codesourcery.com/public/cxx-abi/abi-eh.html) is intended or is a mistake. If it is intended, the OOo code needs to be changed (the information deleteException is now trying to retrieve from the __cxa_exception header must instead be encoded in the deleteException function itself, by dynamically creating instances of deleteException as is already done in the OOo bridges for Solaris). If it is a mistake, the OOo code can stay as is and the GCC 4.4 code needs to be changed instead. -- Summary: Openoffice.org segfaults with runtime libs built from GCC trunk Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
[Bug rtl-optimization/38722] [4.4 Regression] Revision 143027 causes ICE in find_decomposable_subregs
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||x86_64-*-* Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
[Bug fortran/38733] New: non pure function in forall
this should fail to compile INTEGER :: st1,i,a(10) st1(i)=F1(I) FORALL(i=1:10) a(i)=st1(i) write(6,*)a CONTAINS INTEGER FUNCTION F1(I) INTEGER, INTENT(IN) :: I F1=I*I*I END FUNCTION F1 END -- Summary: non pure function in forall Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran 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=38733
[Bug target/36851] [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-01-05 20:01 --- Hi, sorry for delays, somehow non-tuplified alpha shot this off the todo list. I still can't build the target: ../../gcc/mips-tfile.c:672:24: error: mips/a.out.h: No such file or directory ../../gcc/mips-tfile.c:693: error: 'scNil' undeclared here (not in a function) ../../gcc/mips-tfile.c:694: error: 'scText' undeclared here (not in a function) ../../gcc/mips-tfile.c:695: error: 'scData' undeclared here (not in a function) ../../gcc/mips-tfile.c:696: error: 'scBss' undeclared here (not in a function) ../../gcc/mips-tfile.c:697: error: 'scRegister' undeclared here (not in a function) ../../gcc/mips-tfile.c:698: error: 'scAbs' undeclared here (not in a function) ../../gcc/mips-tfile.c:699: error: 'scUndefined' undeclared here (not in a function) ../../gcc/mips-tfile.c:700: error: 'scCdbLocal' undeclared here (not in a function) ../../gcc/mips-tfile.c:701: error: 'scBits' undeclared here (not in a function) ../../gcc/mips-tfile.c:702: error: 'scCdbSystem' undeclared here (not in a function) ../../gcc/mips-tfile.c:703: error: 'scRegImage' undeclared here (not in a function) ../../gcc/mips-tfile.c:704: error: 'scInfo' undeclared here (not in a function) Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|alpha-dec-osf5.1b | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-01-05 20:01 --- Adding 4.4.x reported against, as this testcase is not in 4.3.x. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug c++/31488] [4.3/4.4 Regression] va_list considered non-POD
-- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-29 20:39:29 |2009-01-05 20:01:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-05 13:35 --- I checked my old trunk builds: 2007-11-05-r129891 - works 2007-11-20-r130310 - fails (= 25 fortran/ commits) Assuming no local problems and a clean tree (looks like), the following commit might have caused the regression: r130257 | fxcoudert | 2007-11-17 14:46:53 +0100 (Sat, 17 Nov 2007) | 6 lines http://gcc.gnu.org/viewcvs?view=revrevision=130257 PR fortran/30285 * module.c (struct written_common, written_commons): New structure. (compare_written_commons, free_written_common, write_common_0): New functions. (write_common): Call recursive function write_common_0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug libgomp/38086] [4.2/4.3/4.4 Regression] libgomp fails to build if assembler doesn't support .symver
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-05 20:02 --- Sun recommendations are not the issue here really. On other targets people could use someone else's assembler but GNU ld and this will fail. It just happen Solaris is the one that this happens more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38086
[Bug middle-end/38674] When storing in a register the address of a value contained in the same register, gcc 4.3.2 on ARM clobbers the register before saving its content on the stack.
--- Comment #1 from gilles dot chanteperdrix at xenomai dot org 2009-01-05
15:21 ---
The following, even simpler test case:
unsigned long long f(unsigned long long ull)
{
register unsigned long long *__r0 __asm__ (r0) = ull;
__asm__ __volatile__ ( : +r (__r0));
return * __r0;
}
gives the same warning, and the following assembly code:
f:
0: e24dd008sub sp, sp, #8 ; 0x8
4: e28d0008add r0, sp, #8 ; 0x8
8: e16000f8strdr0, [r0, #-8]!
c: e893ldm r0, {r0, r1}
10: e28dd008add sp, sp, #8 ; 0x8
14: e12fff1ebx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38674
[Bug fortran/38657] [4.3/4.4 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-05 14:47 --- without USE TEST3, gfc_get_symbol_decl (sym=testchar) returns sym-backend_decl because it is set. With USE TEST3, sym-backend_decl is not set, and we create the declaration. As testchar is included from test2 we set the assembler name to __test2_MOD_testchar. Thus the linker message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug bootstrap/38580] [4.4 Regression] Bootstrap broken on mingw32
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug target/38730] gcc 4.4.0 20090104 - make -i check - over 60 FAILs in C compiler
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-05 20:09 --- FAIL: gcc.dg/torture/fp-int-convert-float128.c -O3 -g (test for excess This means that the __float128 to int functions are not included in libgcc not a big deal because most folks don't use __float128. gcc.dg/vect/costmodel/i386/costmodel-vect-68.c These vectorizer failures look like the stack alignment is wrong. FAIL: largefile.c -O0 -g -I. (test for excess errors) Not really a big deal as this is PCH and solaris as a host has not implemented the needed PCH functions yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38730
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #29 from mikael at gcc dot gnu dot org 2009-01-05 20:10 --- (In reply to comment #28) I think this PR can be closed - the ICEs are gone, the TODO item is gone and the missing warnings are tracked in PR 33037. Closing then. It was probably fixed together with PR 37903. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug other/38732] Openoffice.org segfaults with runtime libs built from GCC trunk
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-05 20:10 --- 2008-08-23 Sebastian Redl sebastian.r...@getdesigned.at Add (again) exception propagation support as per N2179. Feature is available only when _GLIBCXX_ATOMIC_BUILTINS_4 is defined. This is to support C++0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
[Bug c++/38472] [4.4 Regression] Wrong result type of ternary operator
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38472
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-05 11:26 --- Disable stage1 checking for arm. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-01-05 11:26:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug fortran/38726] [4.3/4.4 Regression] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #6 from dominiq at lps dot ens dot fr 2009-01-05 14:47 --- If compiled with -fbounds-check, the executable yields: At line 29 of file /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Fortran runtime error: Array reference out of bounds for array 'p', lower bound of dimension 1 exceeded(-2 1) The problem comes from ... p = 20 * r - 10 ... call tq_tvgh (q(k_lev:), (p(p(k_lev: if (any (p(p) /= q)) call abort where min(p)=-10, outside the bounds of p(1:42). If I use ' p = 41 * r + 1', the test passes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug bootstrap/38728] New: gcc 4.4.0 20090104 - make install is relinking `libgij.la'
Nearly all the libraries (and all executables) can be installed by typing
make install, except for libgij which seems to require relinking.
# make install
...
libtool: install: /usr/bin/ginstall -c .libs/libjvm.soT
/usr/local/lib/amd64/gcj-4.4.0-10/libjvm.so
libtool: install: chmod +x /usr/local/lib/amd64/gcj-4.4.0-10/libjvm.so
libtool: install: /usr/bin/ginstall -c .libs/libjvm.lai
/usr/local/lib/amd64/gcj-4.4.0-10/libjvm.la
--
Libraries have been installed in:
/usr/local/lib/amd64/gcj-4.4.0-10
...
libtool: install: (cd /usr/local/lib/amd64 { ln -s -f libgcj.so.10.0.0
libgcj.so || { rm -f libgcj.so ln -s libgcj.so.10.0.0 libgcj.so; }; })
libtool: install: chmod +x /usr/local/lib/amd64/libgcj.so.10.0.0
libtool: install: /usr/bin/ginstall -c .libs/libgcj.lai
/usr/local/lib/amd64/libgcj.la
--
Libraries have been installed in:
/usr/local/lib/amd64
...
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
/bin/sh ./libtool --mode=install /usr/bin/ginstall -c 'libgij.la'
'/usr/local/lib/amd64/libgij.la'
libtool: install: warning: relinking `libgij.la'
libtool: install: (cd
/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava; /bin/sh
/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/libtool --tag CXX
--mode=relink /usr/share/src/gcc_build/./gcc/xgcc ...
...
/usr/lib/amd64/crtn.o -m64 -m64 -m64 -Wl,-Bsymbolic-functions -Wl,-soname
-Wl,libgij.so.10 -o .libs/libgij.so.10.0.0
libtool: install: /usr/bin/ginstall -c .libs/libgij.so.10.0.0T
/usr/local/lib/amd64/libgij.so.10.0.0
libtool: install: (cd /usr/local/lib/amd64 { ln -s -f libgij.so.10.0.0
libgij.so.10 || { rm -f libgij.so.10 ln -s libgij.so.10.0.0 libgij.so.10; };
})
libtool: install: (cd /usr/local/lib/amd64 { ln -s -f libgij.so.10.0.0
libgij.so || { rm -f libgij.so ln -s libgij.so.10.0.0 libgij.so; }; })
libtool: install: chmod +x /usr/local/lib/amd64/libgij.so.10.0.0
libtool: install: /usr/bin/ginstall -c .libs/libgij.lai
/usr/local/lib/amd64/libgij.la
--
Libraries have been installed in:
/usr/local/lib/amd64
...
This 'relinking' occurs for both /usr/local/lib/libgij* and
/usr/local/lib/amd64/libgij*.
Thanks,
Rob
--
Summary: gcc 4.4.0 20090104 - make install is relinking
`libgij.la'
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38728
[Bug fortran/38726] [4.3/4.4 Regression] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-01-05 14:24 --- Marking as regression according to Dominique's comment. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.2 4.4.0 Known to work||4.2.3 Summary|gfortran.dg/elemental_subrou|[4.3/4.4 Regression] |tine_7.f90 fail on |gfortran.dg/elemental_subrou |Linux/ia64 |tine_7.f90 fail on ||Linux/ia64 Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug libstdc++/38631] [4.4 Regression] libstdc++ from gcc 4.4 causes OpenOffice.org 3.0 to crash on startup
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-05 20:19 --- PR 38732 explains what is causing OO.o to fail. The ABI changed ;(. *** This bug has been marked as a duplicate of 38732 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38631
[Bug other/38732] [4.4 Regression] Openoffice.org segfaults with runtime libs built from GCC trunk
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-05 20:19 --- *** Bug 38631 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
[Bug other/38732] [4.4 Regression] Openoffice.org segfaults with runtime libs built from GCC trunk
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-05 20:20 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-05 20:20:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
[Bug target/37520] junk `(,%eax,4)' after expression / suffix or operands invalid for `lea' for libstdc++ deque/init-list.cc
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-01-05 20:23 --- The other kind of freebsd6.3 fail in libstdc++ is: testsuite/25_algorithms/max/3.cc /sw/test/GCC/trunk/libstdc++-v3/testsuite/25_algorithms/max/3.cc:26: undefined reference to `_47' /var/tmp//ccInT4La.o(.text._Z6test01v+0xb):/sw/test/GCC/trunk/libstdc++-v3/testsuite/25_algorithms/max/3.cc:26: undefined reference to `_47' On linux I see these in the linked binary: 00600b58 d ._65 00600b64 d ._66 00600b70 d ._67 00600b7c d ._68 00600b88 d ._69 00600b94 d ._70 So assuming this would be ._48 or '.' used instead of '$'. Does BSD already define NO_DOT_IN_LABEL? Although I am not quite sure what is going on it appears as if the freebsd config (and or assember) for correct linking of some of these C++ entities is off. Anyway. I thought NO_DOT_IN_LABEL/NO_DOLLAR_IN_LABEL will change the name of exported symbols and is ABI-breaking. IMHO figuring this out before the 4.4.0 release seems advisable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37520
[Bug fortran/38122] file already opened in another unit error when opening /dev/null or /dev/tty twice
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-05 20:23 --- (In reply to comment #8) As far as I can tell, ASIS is working correctly with gfortran 4.4 and 4.3. So, we can close? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38122
[Bug rtl-optimization/38722] [4.4 Regression] Revision 143027 causes ICE in find_decomposable_subregs
--- Comment #17 from jakub at gcc dot gnu dot org 2009-01-05 13:11 ---
Slightly more reduced:
! PR rtl-optimization/38722
! { dg-do compile }
! { dg-options -O1 }
SUBROUTINE foo(x, n, ga, gc, vr)
TYPE pt
DOUBLE PRECISION, DIMENSION (:, :, :), POINTER :: cr
END TYPE pt
TYPE pu
TYPE(pt), POINTER :: pw
END TYPE pu
LOGICAL, INTENT(in) :: x, ga, gc
INTEGER :: i, n
LOGICAL :: dd, ep, fe
TYPE(pu) :: vr
TYPE(pu), DIMENSION(:), POINTER :: v
IF (.NOT. fe) THEN
IF (ga) THEN
CALL bar (dd, ep, gc)
END IF
IF (x .AND. .NOT. ga) THEN
IF (gc) THEN
DO i=1,n
CALL baz (v(i), x, gc)
v(i)%pw%cr = 1.0
END DO
DO i=1,n
IF (ep) THEN
IF (dd) THEN
IF (i==1) THEN
v(i)%pw%cr=v(i)%pw%cr + vr%pw%cr
ENDIF
END IF
END IF
END DO
END IF
ENDIF
END IF
END SUBROUTINE foo
I'd say the bug is in
/* If we will be able to accept this, we have made a
change to the destination of I3. This requires us to
do a few adjustments. */
PATTERN (i3) = newpat;
adjust_for_new_dest (i3);
being done before last check that might decide to undo_all (and without
recording the changes into undo structures). A patch which just sets a flag
and does these 2 stmts if the flag is set after the last undo_all cures this,
I'll bootstrap/regtest it soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-01-05 20:38 --- Created an attachment (id=17035) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17035action=view) add fabsf for hpux10/11 Try this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-01-05 20:48 --- Ranier, when cross compiling, link tests cannot always be done. Therefore, libstdc++ hardcodes found functions when cross compiling, and discovers found functions when building for native. The problem with this approach is that the hardcoded list in crossconfig.m4 can become out of date. Thus, the comment in #5 to update this list. I did this, see attached. For HPUX, that is: *-hpux*) SECTION_FLAGS='-ffunction-sections -fdata-sections' AC_SUBST(SECTION_FLAGS) GLIBCXX_CHECK_LINKER_FEATURES GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT AC_DEFINE(HAVE_COPYSIGN) AC_DEFINE(HAVE_COPYSIGNF) AC_DEFINE(HAVE_FREXPF) AC_DEFINE(HAVE_HYPOT) case $target in *-hpux10*) AC_DEFINE(HAVE_FINITE) AC_DEFINE(HAVE_FINITEF) AC_DEFINE(HAVE_ISINF) AC_DEFINE(HAVE_ISINFF) AC_DEFINE(HAVE_ISNAN) AC_DEFINE(HAVE_ISNANF) ;; Now from looking on the web, it looks like HPUX 10.20 and HPUX 11.x have fabsf so the attached patch looks correct. However, this is rarely-touched code so perhaps further clean-up is warranted: I'll check in this first part to get the ball rolling. The current config only defines isinf, etc for 10.20, which seems suspicious to me. What I would suggest doing is looking at the generated c++config.h file from a native build on hpux11.00, and seeing if HAVE_FINITE to HAVE_ISNANF are defined. If so, move them out of the 10.20 block and into the hpux* generic block. Dave any cleanups here are pre-approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug fortran/38665] [4.3 Regression] ICE in check_host_association
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.3 4.4.0 |4.3.3 Known to work|4.3.2 |4.3.2 4.4.0 Summary|[4.4 Regression] ICE in |[4.3 Regression] ICE in |check_host_association |check_host_association Target Milestone|4.4.0 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-05 20:50 --- Subject: Bug 38384 Author: bkoz Date: Mon Jan 5 20:50:25 2009 New Revision: 143093 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143093 Log: 2009-01-05 Benjamin Kosnik b...@redhat.com PR libstdc++/38384 * crossconfig.m4: Define HAVE_FABSF for hpux crosses. 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 other/38732] [4.4 Regression] Openoffice.org segfaults with runtime libs built from GCC trunk
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Keywords||ABI Summary|Openoffice.org segfaults|[4.4 Regression] |with runtime libs built from|Openoffice.org segfaults |GCC trunk |with runtime libs built from ||GCC trunk Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
[Bug middle-end/38671] [4.4 Regression] extra code for setting up loops (IV-opts and 32bits vs 64bits)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38671
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #2 from dominiq at lps dot ens dot fr 2009-01-05 13:57 --- See also http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00421.html for powerpc-apple-darwin8.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #8 from spop at gcc dot gnu dot org 2009-01-05 21:04 --- Subject: Bug 38500 Author: spop Date: Mon Jan 5 21:03:45 2009 New Revision: 143094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143094 Log: 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38510 * graphite.c (recompute_all_dominators): Call mark_irreducible_loops. (translate_clast): Call recompute_all_dominators before graphite_verify. (gloog): Call recompute_all_dominators before graphite_verify. 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com Jan Sjodin jan.sjo...@amd.com PR tree-optimization/38500 * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com Jan Sjodin jan.sjo...@amd.com PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr38500.c trunk/gcc/testsuite/gcc.dg/graphite/pr38510.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #8 from spop at gcc dot gnu dot org 2009-01-05 21:04 --- Subject: Bug 38510 Author: spop Date: Mon Jan 5 21:03:45 2009 New Revision: 143094 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143094 Log: 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38510 * graphite.c (recompute_all_dominators): Call mark_irreducible_loops. (translate_clast): Call recompute_all_dominators before graphite_verify. (gloog): Call recompute_all_dominators before graphite_verify. 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com Jan Sjodin jan.sjo...@amd.com PR tree-optimization/38500 * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. 2009-01-05 Harsha Jagasia harsha.jaga...@amd.com Jan Sjodin jan.sjo...@amd.com PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr38500.c trunk/gcc/testsuite/gcc.dg/graphite/pr38510.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #9 from spop at gcc dot gnu dot org 2009-01-05 21:21 --- Subject: Bug 38492 Author: spop Date: Mon Jan 5 21:21:16 2009 New Revision: 143097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143097 Log: 2009-01-05 Sebastian Pop sebastian@amd.com PR tree-optimization/38492 * graphite.c (rename_map_elt, debug_rename_elt, debug_rename_map_1, debug_rename_map, new_rename_map_elt, rename_map_elt_info, eq_rename_map_elts, get_new_name_from_old_name, bb_in_sese_p): Moved around. (sese_find_uses_to_rename_use): Renamed sese_build_livein_liveouts_use. (sese_find_uses_to_rename_bb): Renamed sese_build_livein_liveouts_bb. (sese_build_livein_liveouts): New. (new_sese, free_sese): New. (new_scop): Call new_sese. (free_scop): Call free_sese. (rename_variables_from_edge, rename_phis_end_scop): Removed. (register_old_new_names): Renamed register_old_and_new_names. (register_scop_liveout_renames, add_loop_exit_phis, insert_loop_close_phis, struct igp, default_liveout_before_guard, add_guard_exit_phis, insert_guard_phis, copy_renames): New. (translate_clast): Call insert_loop_close_phis and insert_guard_phis. (sese_add_exit_phis_edge): Renamed scop_add_exit_phis_edge. (rewrite_into_sese_closed_ssa): Renamed scop_insert_phis_for_liveouts. (scop_adjust_phis_for_liveouts): New. (gloog): Call scop_adjust_phis_for_liveouts. * graphite.h (struct sese): Documented. Added fields liveout, num_ver and livein. (SESE_LIVEOUT, SESE_LIVEIN, SESE_LIVEIN_VER, SESE_NUM_VER): New. (new_sese, free_sese, sese_build_livein_liveouts): Declared. (struct scop): Added field liveout_renames. (SCOP_LIVEOUT_RENAMES): New. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/graphite.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492
[Bug other/38732] [4.4 Regression] Openoffice.org segfaults with runtime libs built from GCC trunk
--- Comment #4 from schwab at suse dot de 2009-01-05 21:31 --- From the ABI document (2.2.1 C++ Exception Objects): By convention, a __cxa_exception pointer points at the C++ object representing the exception being thrown, immediately following the header. The header structure is accessed at a negative offset from the __cxa_exception pointer. This layout allows consistent treatment of exception objects from different languages (or different implementations of the same language), and allows future extensions of the header structure while maintaining binary compatibility. Thus there should be no ABI breakage, unless there is an alignment issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
