[Bug libstdc++/56862] std::complex constructor ambiguous overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56862
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 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
}
[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 ubizjak at gmail dot com 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 sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 David Abdurachmanov david.abdurachmanov at gmail dot com changed: What|Removed |Added CC||david.abdurachmanov at ||gmail dot com --- Comment #22 from David Abdurachmanov david.abdurachmanov at gmail dot com 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_objectboost::exception_detail::bad_alloc_ () 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 fortran/56816] ICE in delete_root
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56816 --- Comment #9 from Mikael Morin mikael at gcc dot gnu.org 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 fortran/56816] ICE in delete_root
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56816 Mikael Morin mikael at gcc dot gnu.org 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 mikael at gcc dot gnu.org 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/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 mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3 from Mikael Morin mikael at gcc dot gnu.org 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 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 dominiq at lps dot ens.fr 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 libstdc++/56861] std::vector::reserve optimization bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56861 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-07 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 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 libstdc++/56861] std::vector::reserve optimization bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56861 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-07 13:34:20 UTC --- (Andrew, I don't think this is a libstdc++ bug, maybe tree-optimization)
[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 dominiq at lps dot ens.fr 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 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 x86intrin.h
__m128d f(__m128d a, __m128d b){
return (__m128d)(~(ab));
}
but it doesn't:
cmpltpd%xmm1, %xmm0
pcmpeqd%xmm1, %xmm1
pxor%xmm0, %xmm1
movapd%xmm1, %xmm0
One reason seems to be that the instruction is modeled as (unge a b), whereas
from a trapping point of view I think it should be (not (lt a b)). But even
-ffast-math does not help.
As a side note, notice that:
return (__m128d)((ab)?0:(__m128i){-1,-1});
uses pandn instead of pxor to generate the negation. I don't think one is
better than the other, I was just surprised to see the difference.
[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/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 dominiq at lps dot ens.fr 2013-04-07 14:56:42 UTC --- The tests pass for me on costmodel-vect-76b.c at r196686.
[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/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 dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-04-07
Ever Confirmed|0 |1
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 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/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 sch...@linux-m68k.org 2013-04-07 15:26:32 UTC --- The test was run with r197541.
[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 dominiq at lps dot ens.fr 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 copypaste 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 #4 from Andreas Schwab sch...@linux-m68k.org 2013-04-07 16:30:10 UTC --- Neither r196686 nor r197531 are revisions on the trunk.
[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 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 winfried.mag...@t-online.de 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 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 dominiq at lps dot ens.fr changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 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 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 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 ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2013-04-07 18:24:31 UTC --- Marked as WONTFIX.
[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 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 g++bug at oxyware dot com 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] Constexpr example in 7.1.5/5 fails to compile correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56868 Jonathan Wakely redi at gcc dot gnu.org 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 #2 from Andrew Pinski pinskia at gcc dot gnu.org 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
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-07
19:41:33 UTC ---
Whatever it is, doesn't have much to do with constexpr, consider:
#include cassert
int f(void *) { return 0; }
int f(...) { return 1; }
int g(int n) { return f(n*0); }
int main()
{
assert (g(0) == 1);
}
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-07 Blocks||32834 Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-07 20:10:58 UTC --- Wrong code for straight F95 code.
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 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 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 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 #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-04-07 20:39:43 UTC --- The temporary is missing as far as 4.3.1.
[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 memory
namespace
{
struct Foo
{
Foo(int) {}
};
}
int main(int, char**)
{
auto foo = std::make_sharedFoo();
return 0;
}
[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 doko at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.2 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org 2013-04-07 20:52:21 UTC --- works with 4.7.2, fails with 4.7.3
[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 pinskia at gcc dot gnu.org 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 target/56855] optab_handler (op=vashr_optab, mode=V4DImode) finds nothing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56855 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 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 #5 from Paolo Carlini paolo.carlini at oracle dot com 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 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 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 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 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 daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #6 from Daniel Krügler daniel.kruegler at googlemail dot com 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 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 objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal
[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 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
templatetypename T 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]’
templatetypename T 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.
