[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #24 from Jakub Jelinek 2013-04-08 06:56:30 UTC --- "One way: put this function into the preinint array; this is automatically done if you use -static-libasan;" That is actually done whenever the binary is linked with -fsanitize=address, no matter whether -static-libasan is used also or not. Just readelf -d binary | grep PREINIT to verify.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 --- Comment #3 from Kai Tietz 2013-04-08 06:51:58 UTC --- Hmm, this bug looks like a duplicate of PR/56742 Could you test if provided patch in PR/56742 fixes your issue?
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 Steven Bosscher changed: What|Removed |Added CC|js-gcc at webkeks dot org |ktietz at gcc dot gnu.org --- Comment #2 from Steven Bosscher 2013-04-08 06:47:46 UTC --- (In reply to comment #1) > Why was this lowered to normal? This is a regression, code that worked fine > with GCC 4.7 now just crashes. It makes ObjC code that uses exceptions > unusable, as it only crashes. Because ObjC is not a release blocking language, and windows is not a primary platform. That doesn't mean it won't be fixed, that depends on whether someone is volunteering to fix this, just like for any other bug report.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #23 from Kostya Serebryany 2013-04-08 06:32:45 UTC --- (In reply to comment #22) > Has this been resolved in the final 4.8.0 (r196952)? I checked some changes > and > they seems to be in. > > I have a number (<100) C++/C packages (incl. boost 1.51.00) compiled w/o > address sanitizer and I am only enabling it for the main software using all > these packages. Yet compilation fails of the main software segflaut from David, please provide more info on the segfault. E.g. run with env. var. ASAN_OPTIONS=verbosity=1 and also disassemble the failing instruction in gdb. I suspect that the non-instrumented code runs before __asan_init_v1 and then calls instrumented code. This will never work. You need to make sure that __asan_init_v1 is called before any instrumented code. One way: put this function into the preinint array; this is automatically done if you use -static-libasan; you can do it manually in your main module. Another way: instrument everything.
[Bug fortran/56872] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #1 from Rich Townsend 2013-04-08 06:02:42 UTC --- Created attachment 29821 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29821 Test program to reproduce the error
[Bug fortran/56872] New: Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Bug #: 56872 Summary: Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu The attached code gives the incorrect results when compiled with -ffrontend-optimize (either explicitly, or via use of one of the -O flags). Correct behavior: $ gfortran -o sum_bug sum_bug.f90 $ ./sum_bug 1. 1000.0 1001.0 Incorrect behavior (i): $ gfortran -O2 -o sum_bug sum_bug.f90 $ ./sum_bug 1. 1000.0 1.0005E-03 Incorrect behavior (ii): $ gfortran -ffrontend-optimize -o sum_bug sum_bug.f90 $ ./sum_bug 1. 1000.0 Infinity gfortran -v gives: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130404 (experimental) (GCC)
[Bug c++/56871] New: [c++11] Specialization of constexpr Templated Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56871 Bug #: 56871 Summary: [c++11] Specialization of constexpr Templated Function Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: david.narv...@computer.org Consider the code below template constexpr int foo(T) { return 0; }; template<> int foo(int) { return 1; } Compiling this code with g++-4.8.0 -Wall -c -std=c++0x bug.cpp throws the following error: bug.cpp:2:23: error: redeclaration ‘constexpr int foo(T) [with T = int]’ differs in ‘constexpr’ template<> int foo(int) { return 1; } ^ bug.cpp:1:36: error: from previous declaration ‘constexpr int foo(T) [with T = int]’ template constexpr int foo(T) { return 0; }; Yet, the C++ standard (section 7.1.5) says that an explicit specialization can differ from the template declaration with respect to the constexpr specifier.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 js-gcc at webkeks dot org changed: What|Removed |Added CC||js-gcc at webkeks dot org --- Comment #1 from js-gcc at webkeks dot org 2013-04-07 22:49:06 UTC --- Why was this lowered to normal? This is a regression, code that worked fine with GCC 4.7 now just crashes. It makes ObjC code that uses exceptions unusable, as it only crashes.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 Andrew Pinski changed: What|Removed |Added Severity|blocker |normal
[Bug objc/56870] New: @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 Bug #: 56870 Summary: @catch handler broken with SEH Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: js-...@webkeks.org When trying to use ObjC exceptions with the new SEH support, the caught object is not the ObjC object, but the _Unwind_Exception instead. Example: @try { id e = [Object new]; printf("@throw %p\n", e); @throw e; } @catch (id e) { printf("@catch %p\n", e); @throw e; } Expected behaviour: Both are the same pointer. Observed behaviour: They differ. Looking further into it, the second pointer is the pointer to the _Unwind_Exception (I added debug code in objc_exception_throw that outputs the pointer after the malloc. It is always the same that's received in the catch). So it seems the generated landing pad for ObjC code is wrong when using SEH. I think it is correct that the landing pad receives the _Unwind_Exception and not the ObjC object. But the landing pad needs to get the ObjC exception out of the _Unwind_Exception and give that back to the user instead of the _Unwind_Exception, which the user should never see. This seems to happen not only with 4.8, but also with 4.9. I marked this bug as blocker, as 4.8 made SEH the default, effectively breaking ObjC execptions on Windows.
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #6 from Daniel Krügler 2013-04-07 21:32:46 UTC --- IMO this behaviour should be considered in the light of http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#903 Assuming the P/R of this issue becomes accepted, both static_assert(g2(0) == 1, "g2 failed"); static_assert(g3(0) == 1, "g3 failed"); should fail.
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com --- Comment #5 from dank at kegel dot com 2013-04-07 21:29:20 UTC --- What's the status of this patch?
[Bug target/56855] optab_handler (op=vashr_optab, mode=V4DImode) finds nothing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855 --- Comment #2 from Marc Glisse 2013-04-07 21:18:28 UTC --- There is still something suboptimal in that with -mxop, vashrv2di3 works fine, but tree-vect-generic lowers vashrv4di3 to scalars instead of v2di. But that doesn't look like a target issue.
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 --- Comment #5 from Paolo Carlini 2013-04-07 21:10:04 UTC --- Don't we have an old issue with folding happening too early in some cases? I'm wondering if this isn't just an example, but I can't quickly find that issue.
[Bug target/56855] optab_handler (op=vashr_optab, mode=V4DImode) finds nothing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Marc Glisse 2013-04-07 21:03:55 UTC --- Uh, I seem to have invented an instruction that doesn't exist, sorry...
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 --- Comment #4 from Andrew Pinski 2013-04-07 20:57:42 UTC --- (In reply to comment #3) > Whatever it is, doesn't have much to do with constexpr, consider: That definitely makes it feel like 0*n being considered a null pointer constant when it should not be.
[Bug c++/56869] [4.7 Regression] ICE (segfault) Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56869 Matthias Klose changed: What|Removed |Added Known to work||4.7.2 --- Comment #1 from Matthias Klose 2013-04-07 20:52:21 UTC --- works with 4.7.2, fails with 4.7.3
[Bug c++/56869] New: [4.7 Regression] ICE (segfault) with the 4.7.3 release candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56869 Bug #: 56869 Summary: [4.7 Regression] ICE (segfault) with the 4.7.3 release candidate Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org works with 4.6 and 4.8, fails with the 4.7 branch $ g++ -std=c++0x foo.cc ' Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. #include namespace { struct Foo { Foo(int) {} }; } int main(int, char**) { auto foo = std::make_shared(); return 0; }
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 --- Comment #4 from Dominique d'Humieres 2013-04-07 20:39:43 UTC --- The temporary is missing as far as 4.3.1.
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 --- Comment #3 from Thomas Koenig 2013-04-07 20:19:53 UTC --- Oops, here it is: program main character(len=4) :: a character(len=4) :: c(3) c(1) = 'abcd' c(2) = '1234' c(3) = 'wxyz' c(:)(1:2) = c(2)(2:3) print '(A)',c end program main
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 --- Comment #2 from Tobias Burnus 2013-04-07 20:15:06 UTC --- Can you attach the test case?
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-07 Blocks||32834 Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig 2013-04-07 20:10:58 UTC --- Wrong code for straight F95 code.
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 --- Comment #3 from Paolo Carlini 2013-04-07 19:41:33 UTC --- Whatever it is, doesn't have much to do with constexpr, consider: #include int f(void *) { return 0; } int f(...) { return 1; } int g(int n) { return f(n*0); } int main() { assert (g(0) == 1); }
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 --- Comment #2 from Andrew Pinski 2013-04-07 18:51:00 UTC --- Looks like 0*0 is being considered a null pointer constant.
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-07 Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0, 4.9.0
[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 --- Comment #1 from Hubert Matthews 2013-04-07 18:39:04 UTC --- Compiled with g++-4.7.0 -Wall -Wextra -std=c++11 on Fedora 14, 64-bit.
[Bug c++/56868] New: Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 Bug #: 56868 Summary: Constexpr example in 7.1.5/5 fails to compile correctly Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: g++...@oxyware.com // The following example from 7.1.5/5 fails the static assert for g3(0) constexpr int f(void *) { return 0; } constexpr int f(...) { return 1; } constexpr int g1() { return f(0); } constexpr int g2(int n) { return f(n); } constexpr int g3(int n) { return f(n*0); } int main() { static_assert(g1() == 0, "g1 failed"); static_assert(g2(0) == 1, "g2 failed"); static_assert(g3(0) == 1, "g3 failed"); // fails, g3(0) returns 0 not 1 }
[Bug rtl-optimization/53728] [4.6 regression] Bootstrap comparison failure (gcc/varasm.o differs) with CFLAGS="-O2 -march=pentium3"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53728 Uros Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #12 from Uros Bizjak 2013-04-07 18:24:31 UTC --- Marked as WONTFIX.
[Bug fortran/56867] New: Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 Bug #: 56867 Summary: Missing temporary with string array assignment Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org And I thought we were done with missing temporaries... ig25@linux-fd1f:~/Krempel/Dep-12> gfortran bar.f90 ig25@linux-fd1f:~/Krempel/Dep-12> ./a.out 23cd 2334 33yz ig25@linux-fd1f:~/Krempel/Dep-12> gfortran-4.6 bar.f90 ig25@linux-fd1f:~/Krempel/Dep-12> ./a.out 23cd 2334 33yz ig25@linux-fd1f:~/Krempel/Dep-12> gfortran-4.7 bar.f90 ig25@linux-fd1f:~/Krempel/Dep-12> ./a.out 23cd 2334 33yz Of course, the last line of output should be 23yz.
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 Dominique d'Humieres changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #5 from Dominique d'Humieres 2013-04-07 17:33:12 UTC --- > Neither r196686 nor r197531 are revisions on the trunk. Well, I record the revision number given by svn: Updated to revision xx The corresponding actual revision for trunk may be some number below, e.g., 197530 for 197531, or 196683 for 196686. If you know a simple way to get the last actual revision for trunk (branch), I'll be glad to use it. Note that between r197531 and r197541, the only changes I can find are r197533 and r197534. Both are supposed to have been tested on powerpc64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00263.html and http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00333.html), but may be not with -m32. Since there is no division in the test, I suspect that if there is a regression in the 197531 to 197541 range, it is likely r197533, hence CCed Steven.
[Bug c/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 --- Comment #1 from Winfried Magerl 2013-04-07 16:55:00 UTC --- Created attachment 29820 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29820 tar-file with small set of c-files to reproduce the problem
[Bug c/56866] New: gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 Bug #: 56866 Summary: gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: winfried.mag...@t-online.de compiling glibc-2.17 with 'O3 -march=bdver2' fails crypt-test when running 'make check' after glibc-build. I've already tested with different compilers/settings and the problem exists with gcc-4.7.x and gcc-4.8.x when using '-O3 -march=bdver1' or '-O3 -march=bdver2' (-O2 is fine) and the affected file is glibc-2.17/crypt/sha512.c. I've attached a tar-file which includes necessary files from glibc-2.17 (sha512-block.c/sha512.c/sha512.h) and a modified version of sha512c-test.c (removed dependency to glibc-test-environment). Might not work if system-libc is not 2.17 (recompiling glibc and run test-suite should always work. A small test-script test-gcc.sh to demonstrate the problem. Verified on: gcc (GCC) 4.8.1 20130407 / glibc-2.17 gcc (GCC) 4.7.2 20130108 / opensuse-12.3 / glibc-2.17
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 --- Comment #4 from Andreas Schwab 2013-04-07 16:30:10 UTC --- Neither r196686 nor r197531 are revisions on the trunk.
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 --- Comment #3 from Dominique d'Humieres 2013-04-07 15:31:13 UTC --- > > The tests pass for me on costmodel-vect-76b.c at r196686. > > The test was run with r197541. I did a copy&paste error, the tests pass for me at r197531.
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 --- Comment #2 from Andreas Schwab 2013-04-07 15:26:32 UTC --- The test was run with r197541.
[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-07 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-04-07 15:08:53 UTC --- Confirmed on powerpc-apple-darwin9 for -m32. For -m64 I get PASS: gcc.dg/vect/vect-42.c execution test PASS: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "vectorized 2 loops" 1 PASS: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access forced using versioning" 1 XFAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4 XFAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 One of the following conditions { vect_no_align || { { ! vector_alignment_reachable } || vect_element_align } } must be true on a G5 under powerpc-apple-darwin9.
[Bug target/56865] New: [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865 Bug #: 56865 Summary: [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Target: powerpc*-*-* Created attachment 29819 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29819 vect-42.c.111t.vect spawn /daten/gcc/gcc-20130406/Build/gcc/xgcc -B/daten/gcc/gcc-20130406/Build/gcc/ /daten/gcc/gcc-20130406/gcc/testsuite/gcc.dg/vect/vect-42.c -fno-diagnostics-show-caret -maltivec -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -m32 -o ./vect-42.exe PASS: gcc.dg/vect/vect-42.c (test for excess errors) Setting LD_LIBRARY_PATH to :/daten/gcc/gcc-20130406/Build/gcc:/daten/gcc/gcc-20130406/Build/gcc/64::/daten/gcc/gcc-20130406/Build/gcc:/daten/gcc/gcc-20130406/Build/gcc/64:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libstdc++-v3/src/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libmudflap/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libsanitizer/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libssp/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libgomp/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libitm/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libatomic/.libs:/daten/gcc/gcc-20130406/Build/./gcc:/daten/gcc/gcc-20130406/Build/./prev-gcc spawn [open ...] PASS: gcc.dg/vect/vect-42.c execution test PASS: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "vectorized 2 loops" 1 FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4 FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 Fails for both -m32 and -m64. Configured with: ../configure --prefix=/usr --build=powerpc64-linux --enable-checking=release --enable-shared --with-system-zlib --with-cpu=default32 --with-cpu-64=power4 --enable-secureplt --with-long-double-128
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 --- Comment #1 from Dominique d'Humieres 2013-04-07 14:56:42 UTC --- The tests pass for me on costmodel-vect-76b.c at r196686.
[Bug target/56864] New: [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 Bug #: 56864 Summary: [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Target: powerpc-*-* Created attachment 29818 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29818 costmodel-vect-76b.c.111t.vect spawn /daten/gcc/gcc-20130406/Build/gcc/xgcc -B/daten/gcc/gcc-20130406/Build/gcc/ /daten/gcc/gcc-20130406/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c -fno-diagnostics-show-caret -O2 -ftree-vectorize -fvect-cost-model -fno-common -maltivec -fdump-tree-vect-details -lm -m32 -o ./costmodel-vect-76b.exe PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c (test for excess errors) Setting LD_LIBRARY_PATH to :/daten/gcc/gcc-20130406/Build/gcc:/daten/gcc/gcc-20130406/Build/gcc/64:/daten/gcc/gcc-20130406/Build/powerpc64-linux/./libsanitizer/asan/.libs::/daten/gcc/gcc-20130406/Build/gcc:/daten/gcc/gcc-20130406/Build/gcc/64:/daten/gcc/gcc-20130406/Build/powerpc64-linux/./libsanitizer/asan/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libstdc++-v3/src/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libmudflap/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libsanitizer/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libssp/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libgomp/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libitm/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libatomic/.libs:/daten/gcc/gcc-20130406/Build/./gcc:/daten/gcc/gcc-20130406/Build/./prev-gcc spawn [open ...] PASS: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c execution test FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorization not profitable" 1 Only fails for -m32. Configured with: ../configure --prefix=/usr --build=powerpc64-linux --enable-checking=release --enable-shared --with-system-zlib --with-cpu=default32 --with-cpu-64=power4 --enable-secureplt --with-long-double-128
[Bug target/56863] New: cmpnltpd recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56863 Bug #: 56863 Summary: cmpnltpd recognition Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: gli...@gcc.gnu.org Target: x86_64-linux-gnu Hello, I was looking at this program, trying to get it to generate cmpnltpd: #include __m128d f(__m128d a, __m128d b){ return (__m128d)(~(a
[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56812 --- Comment #11 from Dominique d'Humieres 2013-04-07 13:35:54 UTC --- > The test is failing on ia64: > > $ grep basic slp-pr56812.cc.115t.slp > /usr/local/gcc/gcc-20130404/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:16: note: > not vectorized: unsupported alignment in basic block. It is also failing on powerpc*-*-*. The test is skipped if I follows comment #9.
[Bug libstdc++/56861] std::vector::reserve optimization bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56861 --- Comment #2 from Jonathan Wakely 2013-04-07 13:34:20 UTC --- (Andrew, I don't think this is a libstdc++ bug, maybe tree-optimization)
[Bug libstdc++/56861] std::vector::reserve optimization bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56861 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-07 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2013-04-07 13:32:26 UTC --- You apparently didn't read http://gcc.gnu.org/bugs Please do not supply a URL to some other site, that's not a valid bug report.
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #17 from Dominique d'Humieres 2013-04-07 13:18:27 UTC --- The test gfortran.dg/vect/fast-math-pr37021.f90 fails on powerpc*-* (see http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00677.html ). Isn't it expected? AFAICT doubles are not vectorized, at least on a G5.
[Bug fortran/56852] [4.6/4.7/4.8/4.9 Regression] ICE on invalid: "Bad array reference" for an undeclared loop variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56852 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin 2013-04-07 11:47:58 UTC --- There is a simple fix, may be too big hammer: diff --git a/resolve.c b/resolve.c index 835b57f..0b44c98 100644 --- a/resolve.c +++ b/resolve.c @@ -14426,6 +14426,7 @@ gfc_resolve (gfc_namespace *ns) { gfc_namespace *old_ns; code_stack *old_cs_base; + int errors; if (ns->resolved) return; @@ -14435,6 +14436,9 @@ gfc_resolve (gfc_namespace *ns) old_cs_base = cs_base; resolve_types (ns); + gfc_get_errors (NULL, &errors); + if (errors > 0) +return; component_assignment_level = 0; resolve_codes (ns);
[Bug fortran/56816] ICE in delete_root
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56816 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-07 AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #10 from Mikael Morin 2013-04-07 11:30:43 UTC --- Comment #9, is a bit too complex; I will test and submit comment #8, which seems to be the safest.
[Bug fortran/56816] ICE in delete_root
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56816 --- Comment #9 from Mikael Morin 2013-04-07 11:28:45 UTC --- Created attachment 29817 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29817 Another tentative patch This variant moves the namespace allocation to parse_select_type_block (parse.c), like it's done for associate blocks. This implies delaying name to symbol resolution for associate-name, i.e. register the name only in gfc_match_select_type, and wait for the namespace to be allocated in parse_select_type_block to retrieve the symbol.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 David Abdurachmanov changed: What|Removed |Added CC||david.abdurachmanov at ||gmail dot com --- Comment #22 from David Abdurachmanov 2013-04-07 08:44:21 UTC --- Has this been resolved in the final 4.8.0 (r196952)? I checked some changes and they seems to be in. I have a number (<100) C++/C packages (incl. boost 1.51.00) compiled w/o address sanitizer and I am only enabling it for the main software using all these packages. Yet compilation fails of the main software segflaut from boost. Reminder, that boost and ROOT is not compiled w/ address sanitizer. I tried -static-libasan, yet in that case linker cannot resolve asan symbols while shared library is being created. libasan_preinit.o, libasan.so, and libasan.a is in my GCC package under ./lib64. I added the following options to default CXXFLAGS, which also ended up on LDFLAGS: -static-libasan -fsanitize=address -fno-omit-frame-pointer -g -O0 ### SEGFAULT ### The lines below might hint at the cause of the crash. If they do not help you then please submit a bug report at http://root.cern.ch/bugs. Please post the ENTIRE stack trace from above as an attachment in addition to anything else that might help us fixing this issue. === #5 0x2b33b9930d8a in boost::exception_detail::get_static_exception_object () at /build/davidlt/test-asan/a/slc6_amd64_gcc480/external/boost /1.51.0-cms2/include/boost/exception/detail/exception_ptr.hpp:117 #6 0x2b33ba70685c in _GLOBAL__sub_I_future.cpp () from /build/davidlt/test-asan/a/tmp/BUILDROOT/2c73b4475e8345752c405e046bb5182f/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2 _X_2013-04-06-0200/external/slc6_amd64_gcc480/lib/libboost_thread.so.1.51.0 #7 0x003326c0e57f in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #8 0x003326c12c25 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #9 0x003326c0e196 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #10 0x003326c1246a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #11 0x003327400f66 in dlopen_doit () from /lib64/libdl.so.2 #12 0x003326c0e196 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #13 0x00332740129c in _dlerror_run () from /lib64/libdl.so.2 #14 0x003327400ee1 in dlopen ### UNDEFINED REFERENCES ### /build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetFileFormatVersion.cc:5: error: undefined reference to '__asan_init_v1'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:8: error: undefined reference to '__asan_report_load1'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:11: error: undefined reference to '__asan_unregister_globals'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:11: error: undefined reference to '__asan_init_v1'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:11: error: undefined reference to '__asan_register_globals'
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #3 from Uros Bizjak 2013-04-07 08:28:44 UTC --- (In reply to comment #2) > I can't test this because I have no access to alpha hardware. I'll bootstrap and regression test the patch on ev68, please expect results in a couple of days.
[Bug libstdc++/56862] std::complex constructor ambiguous overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56862 --- Comment #1 from Paolo Carlini 2013-04-07 08:18:18 UTC --- I think everything is working by design, both in the compiler and in the library (which is very simple in this area). This is enough to show the issue (all the compiler I have around behave the same): struct complex { complex(const double& = double(), const double& = double()); }; struct number { operator complex() const { return 0; } operator int(); //OK if this line is commented out }; int main() { number b; complex cb(b); //error: call of overloaded 'complex(number&)' is ambiguous }