[Bug middle-end/58335] S/390: reload vs lra regression - testcase builtin-in-setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Andreas Krebbel --- Closing per comment above.
[Bug middle-end/58335] S/390: reload vs lra regression - testcase builtin-in-setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335 Andreas Krebbel changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andreas Krebbel --- Regression is fixed. Thanks!
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #14 from Tobias Burnus --- Janus' submitted patch: http://gcc.gnu.org/ml/fortran/2013-08/msg00026.html Looks great and fixes also comment 10's test case. * * * I tried to test for the "intrinsic elemental" of comment 2's standard quote. That works without "elemental" in the INTERFACE but not with. However, the standard states for "acos": "Class. Elemental function." Nonetheless, gfortran prints: Error: Interface mismatch in procedure pointer assignment at (1): Mismatch in PURE attribute" for intrinsic acos interface elemental real function oo(x) ! Works (and should work) without "elemental" real, intent(in) :: x end function end interface procedure(oo),pointer :: bar bar => acos end
[Bug other/58467] Documentation of the "used" variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug other/58467] Documentation of the "used" variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Sep 20 06:08:44 2013 New Revision: 202764 URL: http://gcc.gnu.org/viewcvs?rev=202764&root=gcc&view=rev Log: 2013-09-20 Marek Polacek PR other/58467 * doc/extend.texi: Document that attribute used is meant to be used on variables with static storage duration. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c/58454] Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #4 from Ian Lance Taylor --- Richi, as you know, -fno-strict-overflow was added to prevent people from configuring GCC to make -fwrapv the default. I know you hate the option but I continue to think that adding was the right tactical move at the time. We can't just ignore the world outside the compiler development community. It's true that -fno-strict-overflow does not apply to loop optimizations, which are covered by -fno-aggressive-loop-optimizations. I agree that that is a doc omission.
[Bug middle-end/58479] [4.9 Regression] slow compilation on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479 Marek Polacek changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/58479] slow compilation on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed (with checking enabled). It's VTA: with -fno-var-tracking the slowdown goes away.
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #4 from Martin Husemann --- I stared at the assembly a bit more (but my vax fu is weak): we are in the last line of 216 #line 781 "../../gcc-4.8.1/gcc/config/vax/vax.md" 217 ((INTVAL (operands[1]) == 8 || INTVAL (operands[1]) == 16) 218&& INTVAL (operands[2]) % INTVAL (operands[1]) == 0 219&& (REG_P (operands[0]) 220|| ! mode_dependent_address_p (XEXP (operands[0], 0), 221MEM_ADDR_SPACE (operands[0]) and doing: 0x92cda2 : movl *0xef3cfc <_GLOBAL_OFFSET_TABLE_+1548>,r0 this is r0 = operands[0] MEM_ADDR_SPACE(RTX) is get_mem_attrs (RTX)->addrspace) so we do the call: 0x92cda9 : pushl r0 0x92cdab : calls $0x1,0x92c99e and apparently get_mem_attrs(operand[0]) returned 4, which we then deref to ->addrspace and crash.
[Bug middle-end/58479] [4.9 Regression] slow compilation on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479 Marek Polacek changed: What|Removed |Added Summary|slow compilation on |[4.9 Regression] slow |x86_64-linux at -O1 (and|compilation on x86_64-linux |above) with -g, but |at -O1 (and above) with -g, |checking disabled |but checking disabled --- Comment #2 from Marek Polacek --- With 4.8/4.7 it's indeed not that bad, thus tentatively marking as 4.9 regression...
[Bug middle-end/58478] New: very slow compilation at -O1 and above on a nested loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58478
Bug ID: 58478
Summary: very slow compilation at -O1 and above on a nested
loop
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following testcase takes much longer to compile at -O1 and above using GCC
4.7.3 on x86_64-linux (in both 32-bit and 64-bit modes).
It does not seem to affect 4.8 and the current trunk.
$ gcc-4.7 -v
Using built-in specs.
COLLECT_GCC=gcc-4.7
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.3/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking
--with-gmp=/usr/local/gcc-4.7 --with-mpfr=/usr/local/gcc-4.7
--with-mpc=/usr/local/gcc-4.7 --with-ppl=/usr/local/gcc-4.7
--with-cloog=/usr/local/gcc-4.7 --prefix=/usr/local/gcc-4.7
Thread model: posix
gcc version 4.7.3 (GCC)
$ time gcc-4.7 -O0 small.c
0.02user 0.02system 0:00.05elapsed 86%CPU (0avgtext+0avgdata 38336maxresident)k
0inputs+32outputs (0major+6471minor)pagefaults 0swaps
$ time gcc-4.7 -O1 small.c
33.43user 0.12system 0:33.64elapsed 99%CPU (0avgtext+0avgdata
660976maxresident)k
0inputs+32outputs (0major+53023minor)pagefaults 0swaps
$ time gcc-4.8 -O1 small.c
0.02user 0.02system 0:00.05elapsed 85%CPU (0avgtext+0avgdata 36704maxresident)k
0inputs+32outputs (0major+6364minor)pagefaults 0swaps
$ time gcc-trunk -O1 small.c
0.04user 0.01system 0:00.07elapsed 82%CPU (0avgtext+0avgdata 42656maxresident)k
0inputs+32outputs (0major+6700minor)pagefaults 0swaps
$
-
int a, b, c, d, e;
int main ()
{
for (a = 0; a < 10; a++)
for (b = 0; b < 10; b++)
for (c = 0; c < 10; c++)
for (d = 0; d < 10; d++)
for (e = 0; e < 10; e++)
;
return 0;
}
[Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58318 --- Comment #3 from Zhendong Su --- > A quick check with a non-bootstrapped cc1 but release checking makes the > slowdown go away. Richard, there is related testcase that I have just reported (58479). It manifests also under release checking. Thanks.
[Bug middle-end/58478] very slow compilation at -O1 and above on a nested loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58478 --- Comment #2 from Zhendong Su --- (In reply to Marek Polacek from comment #1) > Confirmed. That's quick; thanks Marek! Please also take a look at 58479 when you get a chance. It's related (as well as 58318).
[Bug middle-end/58478] very slow compilation at -O1 and above on a nested loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58478 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-19 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug middle-end/58479] New: slow compilation on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479
Bug ID: 58479
Summary: slow compilation on x86_64-linux at -O1 (and above)
with -g, but checking disabled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code takes much longer to compile at -O1 (and above) with -g
using the current gcc trunk on x86_64-linux (in both 32-bit and 64-bit modes).
It also affects 4.6, 4.7, and 4.8 (with checking disabled), but to a lesser
extent (4 seconds vs. 12 seconds at -O1 with -g).
This seems to be related to 58318, but 58318 manifests only when checking is
enabled.
This may also be related to 58478.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/su/software/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-checking=release
--with-gmp=/home/su/software/local/gcc-trunk
--with-mpfr=/home/su/software/local/gcc-trunk
--with-mpc=/home/su/software/local/gcc-trunk
--with-cloog=/home/su/software/local/gcc-trunk
--prefix=/home/su/software/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130917 (experimental) (GCC)
$
$ time gcc -O0 -g small.c
0.02user 0.00system 0:00.13elapsed 27%CPU (0avgtext+0avgdata 37888maxresident)k
0inputs+56outputs (0major+6439minor)pagefaults 0swaps
$ time gcc -O1 small.c
0.02user 0.02system 0:00.14elapsed 30%CPU (0avgtext+0avgdata 40144maxresident)k
0inputs+32outputs (0major+6560minor)pagefaults 0swaps
$ time gcc -O1 -g small.c
7.69user 0.53system 0:12.20elapsed 67%CPU (0avgtext+0avgdata
2632224maxresident)k
0inputs+32outputs (0major+180567minor)pagefaults 0swaps
$
-
int a, b, c, d, e, f;
int main ()
{
for (a = 0; a < 8; a++)
for (b = 0; b < 8; b++)
for (c = 0; c < 8; c++)
for (d = 0; d < 8; d++)
for (e = 0; e < 8; e++)
{
int t[3][2][9] = {
{{f, f, f, f, f, f, f, f, f},
{f, f, f, f, f, f, f, f, f}},
{{f, f, f, f, f, f, f, f, f},
{f, f, f, f, f, f, f, f, f}},
{{f, f, f, f, f, f, f, f, f},
{f, f, f, f, f, f, f, f, f}},
};
}
return 0;
}
[Bug c++/58477] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-19 CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jan Hubicka --- mine.
[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #13 from Dominique d'Humieres --- > What's the difference between defined_assignment_11_db.f90 and > defined_assignment_11.f90? In defined_assignment_11_db.f90 the print statements have been uncommented.
[Bug c++/58435] Applying a type transformation to a list: const ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58435 --- Comment #6 from iavr at image dot ntua.gr --- (In reply to pa...@gcc.gnu.org from comment #5) > Author: paolo > Date: Tue Sep 17 17:46:03 2013 > New Revision: 202662 > Hi, Thanks a lot for your immediate response. However, I have to report that exactly the same problem occurs for "volatile" and "const volatile", as I just found out. Maybe these have been fixed as well already? Yannis
[Bug c++/58477] New: ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477 Bug ID: 58477 Summary: ice in cgraph_speculative_call_info Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 30868 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30868&action=edit gzipped C++ source code I just tried to compile package oxygen-gtk2-1.4.0 with gcc 4.9 trunk dated 20130917. It said /home/dcb/rpmbuild/BUILD/oxygen-gtk2-1.4.0/src/oxygencolorutils.cpp:148:67: inte rnal compiler error: Segmentation fault m_backgroundTopColorCache.insert( color.toInt(), out ); ^ 0xb0413f crash_signal ../../src/trunk/gcc/toplev.c:335 0x7e8f14 cgraph_speculative_call_info(cgraph_edge*, cgraph_edge*&, cgraph_edge*& , ipa_ref*&) ../../src/trunk/gcc/cgraph.c:1125 0x7e9ffe cgraph_redirect_edge_call_stmt_to_callee(cgraph_edge*) ../../src/trunk/gcc/cgraph.c:1308 0xb5b14e redirect_all_calls(copy_body_data*, basic_block_def*) ../../src/trunk/gcc/tree-inline.c:2326 0xb6162f copy_cfg_body ../../src/trunk/gcc/tree-inline.c:2458 0xb6162f copy_body ../../src/trunk/gcc/tree-inline.c:2625 0xb66983 expand_call_inline ../../src/trunk/gcc/tree-inline.c:4234 0xb66983 gimple_expand_calls_inline ../../src/trunk/gcc/tree-inline.c:4341 0xb66983 optimize_inline_calls(tree_node*) ../../src/trunk/gcc/tree-inline.c:4496 0xf8758b inline_transform(cgraph_node*) ../../src/trunk/gcc/ipa-inline-transform.c:436 0xa58139 execute_one_ipa_transform_pass ../../src/trunk/gcc/passes.c:2039 0xa58139 execute_all_ipa_transforms() ../../src/trunk/gcc/passes.c:2079 0x7f1990 expand_function ../../src/trunk/gcc/cgraphunit.c:1743 0x7f39d6 expand_all_functions ../../src/trunk/gcc/cgraphunit.c:1855 0x7f39d6 compile() ../../src/trunk/gcc/cgraphunit.c:2192 0x7f3fb9 finalize_compilation_unit() ../../src/trunk/gcc/cgraphunit.c:2269 0x5ff47d cp_write_global_declarations() ../../src/trunk/gcc/cp/decl2.c:4360 Please submit a full bug report, with preprocessed source if appropriate. Preprocessed source code attached. Flag -O3 required.
[Bug c++/58477] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 tmp % cat test.ii
struct A {
void operator==(const A &);
};
class B {
public:
A m_fn1();
A m_fn2();
};
template class C {
public:
T Key;
const M &m_fn2(const T &);
virtual void m_fn1() {}
B _map;
};
C b;
template const M &C::m_fn2(const T &) {
A a = _map.m_fn2();
a == _map.m_fn1();
m_fn1();
}
void fn1() { b.m_fn2(0); }
markus@x4 tmp % g++ -O2 test.ii
test.ii: In function ‘void fn1()’:
test.ii:24:24: internal compiler error: Segmentation fault
[Bug rtl-optimization/58461] [MIPS] Using LRA instead of reload increases code size for mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58461 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- Thanks for working on this. As you mentioned in the gcc@ message, there are two ways of looking at the problem: the backend costs are wrong or LRA isn't handling the reloads as well (or both, for a third). I think it'd be wrong for the backend to say that moves between MIPS16 registers and other general registers are more expensive than memory though. Doing that could in theory pessimise post- reload optimisation (postreload.c also compares memory and register costs). Other passes might look at the costs too in future. And a move in or out of a MIPS16 register really is as cheap as a move between MIPS16 registers. But of course, although the moves are cheap, registers other than $2-$7, $16, $17 and $24 are only useful as spill space. So if it's better for IRA to ignore them and LRA to use them via TARGET_SPILL_CLASS, perhaps we should enforce that directly, by hiding other registers from IRA. I suppose that's like restoring the old cover classes hook, but only as an optional feature. I realise this isn't the point of the bug report or the attachment, but just FWIW: the constraints shouldn't be matching the fake FRAME_POINTER_REGNUM. They should wait for it to be eliminated to either STACK_POINTER_REGNUM or HARD_FRAME_POINTER_REGNUM and match that.
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #4 from Oleg Smolsky --- Also, I've just extracted the regex call into a tiny test app and there is no deadlock... so, it is a bit puzzling...
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #25 from Marc Glisse --- Note that naively doing what I am proposing in comment #14 (it's just an iter_swap and a +-1) also makes reverse-sorted arrays a bad case, because of the way we do partitioning, so it isn't an alternative to Chris's first+1 approach, more of an orthogonal optimization.
[Bug c++/58477] ice in cgraph_speculative_call_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477 Paolo Carlini changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #2 from Paolo Carlini --- CC-ing Honza.
[Bug c++/58435] Applying a type transformation to a list: const ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58435 --- Comment #7 from Paolo Carlini --- Of course. Just look at the testcase.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #22 from Tammy Hsu --- Thanks a lot. We will test it out with our real application. Just want to do things right, the patch is the one described in Attachment 30861. And I just need to patch the /include/c++/4.8.1/bits/stl_algo.h, don't need to rebuild gcc481.
[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #12 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #11) > The test gfortran.dg/defined_assignment_11.f90 fails on > x86_64-apple-darwin10: > ==30916== Invalid read of size 4 > ==30916==at 0x121EF: MAIN__ (defined_assignment_11_db.f90:40) > > It is probably related to comment #10. It shouldn't. The problem of comment 10 only occurs when "left" is deallocated - and there is no end-of-scope deallocation in defined_assignment_11.f90 as variables in MAIN have implicitly the SAVE attribute. What's the difference between defined_assignment_11_db.f90 and defined_assignment_11.f90?
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Thu Sep 19 17:03:51 2013 New Revision: 202750 URL: http://gcc.gnu.org/viewcvs?rev=202750&root=gcc&view=rev Log: PR tree-optimization/58472 * c-c++-common/gomp/pr58472.c: New test. Added: branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/gomp/pr58472.c Modified: branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #23 from Paolo Carlini --- If this is a question, the answer is YES.
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Sep 19 16:56:40 2013 New Revision: 202748 URL: http://gcc.gnu.org/viewcvs?rev=202748&root=gcc&view=rev Log: PR tree-optimization/58472 * tree-vect-stmts.c (vectorizable_store, vectorizable_load): For simd_lane_access set inv_p = false. * omp-low.c (lower_rec_input_clauses): Set TREE_NO_WARNING on the simduid magic VAR_DECL. * c-c++-common/gomp/pr58472.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/tree-vect-stmts.c
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from John David Anglin --- Thanks, fixed.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #24 from Tammy Hsu --- Yes, it is a question. And thank you for the answer... :-)
[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58464 Marek Polacek changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #4 from Marek Polacek --- Started with r198333.
[Bug middle-end/58463] ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I think this has been already fixed.
[Bug bootstrap/58476] bootstrap failure with Go enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #1 from Ian Lance Taylor --- I can not recreate this problem on my x86_64-unknown-linux-gnu (Ubuntu Precise) system. I tried building in my current working directory, then I tried removing x86_64-unknown-linux-gnu/libstdc++ and x86_64-unknown-linux-gnu/32/libstdc++. Either way it worked fine for me. As the Go frontend contains only C and C++ code, this is not of course a Go problem. It looks like a problem in libstdc++.
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #3 from Oleg Smolsky --- Hey Kostya, unfortunately I have no way to check that. This happens in our product code I cannot built it with Clang.
[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58464 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Whoops. Confirmed.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #21 from Jeffrey M. Birnbaum --- (In reply to Paolo Carlini from comment #19) > I ran some quick tests and indeed the performance seems equal of better of > those of the old C++03 code. Note that the patch is very small and can be > installed even on top of the installed headers, without rebuilding anything, > thus I would really encourage the bug submitters to test it and report back. Excellent. Will test and report back.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #20 from Chris Jefferson --- Created attachment 30867 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30867&action=edit Performance tests for sort This is some performance tests for performance checking. Sorry for tar rather than patch, just pop them in performance/25_algorithms. I decided to check stable_sort and heap_sort as well as just sort, just to check nothing else got broken at the same time (turns out, nothing else did). Not sure exactly what the appropriate memory / time tradeoffs are for the performance test suite, so any comments welcome.
[Bug other/58467] Documentation of the "used" variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-19 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Yeah. I've just posted a patch that should clarify the doc a bit...
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #9 from vincenzo Innocente --- w/o opening another bug report c++ -O2 -S omp4red.cc -fopenmp -Wall omp4red.cc: In function ‘float sumO1()’: omp4red.cc:6:9: warning: ‘simduid.0’ is used uninitialized in this function [-Wuninitialized] #pragma omp simd reduction(+:s) ^
[Bug other/58467] Documentation of the "used" variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #1 from Paul Smith --- Housekeeping: it would be very nice to have a "Doc" component in bugzilla. As it was I picked "c" because it was that part of the docs. Thx!
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #19 from Paolo Carlini --- I ran some quick tests and indeed the performance seems equal of better of those of the old C++03 code. Note that the patch is very small and can be installed even on top of the installed headers, without rebuilding anything, thus I would really encourage the bug submitters to test it and report back.
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 Gregor Richards changed: What|Removed |Added Attachment #30835|0 |1 is obsolete|| --- Comment #14 from Gregor Richards --- Created attachment 30866 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30866&action=edit mips support for musl And the equivalent change for MIPS (/lib/ld-musl-mips[el].so.1)
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 Gregor Richards changed: What|Removed |Added Attachment #30834|0 |1 is obsolete|| --- Comment #13 from Gregor Richards --- Created attachment 30865 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30865&action=edit arm support for musl This change to arm.diff adds support for musl's -eb and -hf linkers (/lib/ld-musl-arm[eb][hf].so.1)
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 Gregor Richards changed: What|Removed |Added Attachment #30831|0 |1 is obsolete|| Attachment #30832|0 |1 is obsolete|| --- Comment #12 from Gregor Richards --- Created attachment 30864 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30864&action=edit Changes to gcc/configure.ac for musl Making libssp use the same system as everything else. (I'll leave the whether-to-build-libssp debate to future generations :) )
[Bug bootstrap/58476] New: bootstrap failure with Go enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476 Bug ID: 58476 Summary: bootstrap failure with Go enabled Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org I'm using a recent (yesterda) gcc trunk from git. I have no local patches applied. I'm building a native gcc on x86-64 Fedora 18. I configured with: barimba. ./config.status --version config.status configured by ../gcc/configure, generated by GNU Autoconf 2.64, with options " '--prefix=/home/tromey/Space/Trunk/Git/install' '--enable-threads=posix' '--enable-checking=yes' '--enable-java-awt=gtk' '--disable-multilib' '--enable-libgo' '--enable-libada' '--disable-static' '--enable-languages=c,ada,c++,fortran,go,java,lto,objc,obj-c++'" Bootstrap fails when linking the Go front end: make[3]: Entering directory `/home/tromey/Space/Trunk/Git/build/gcc' /home/tromey/Space/Trunk/Git/build/./prev-gcc/xg++ -B/home/tromey/Space/Trunk/Git/build/./prev-gcc/ -B/home/tromey/Space/Trunk/Git/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/tromey/Space/Trunk/Git/gcc/libstdc++-v3/libsupc++ -L/home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o go1 \ go/ast-dump.o go/dataflow.o go/export.o go/expressions.o go/go-backend.o go/go-dump.o go/go-gcc.o go/go-lang.o go/go-linemap.o go/go-optimize.o go/go.o go/gogo-tree.o go/gogo.o go/import.o go/import-archive.o go/lex.o go/parse.o go/runtime.o go/statements.o go/types.o go/unsafe.o attribs.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz /home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(istream.o): In function `std::istream::ignore(long, int)': /home/tromey/Space/Trunk/Git/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/c++98/../../../../../gcc/libstdc++-v3/src/c++98/istream.cc:116: undefined reference to `std::istream::ignore(long)' /home/tromey/Space/Trunk/Git/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(istream.o): In function `std::basic_istream >::ignore(long, unsigned int)': /home/tromey/Space/Trunk/Git/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/c++98/../../../../../gcc/libstdc++-v3/src/c++98/istream.cc:521: undefined reference to `std::basic_istream >::ignore(long)' collect2: error: ld returned 1 exit status make[3]: *** [go1] Error 1 make[3]: Leaving directory `/home/tromey/Space/Trunk/Git/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/tromey/Space/Trunk/Git/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/tromey/Space/Trunk/Git/build' make: *** [all] Error 2 FWIW, this blocks the auto-dependency patch series.
[Bug target/58475] SH4 insn swapb does not satisfy its constraints:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58475 --- Comment #1 from chrbr at gcc dot gnu.org --- The problem is that [(set (match_operand:SI 0 "arith_reg_dest" "=r") (ior:SI (and:SI (match_operand:SI 1 "arith_reg_operand" "r") accepts fpul registers in the predicate, but not in the constraints. The reason is that arith_reg_dest is tricked to accept FPUL_REG when TARGET_SH4. There is no reason that a fpul register is accepted as a source operand for an arithmetic op, unless the floating point transfer needs to be expressed in the rtl, so fpul will need reloading. .
[Bug target/58475] New: SH4 insn swapb does not satisfy its constraints:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58475
Bug ID: 58475
Summary: SH4 insn swapb does not satisfy its constraints:
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: chrbr at gcc dot gnu.org
Created attachment 30863
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30863&action=edit
test case
cc1 -Os -m4 swapb_ice.c -o 2.s -quiet
swapb_ice.c: In function 'kerninfo':
swapb_ice.c:15:1: error: insn does not satisfy its constraints:
}
^
(insn 35 8 10 2 (set (reg:SI 150 fpul)
(ior:SI (and:SI (reg:SI 4 r4 [170])
(const_int 4294901760 [0x]))
(ior:SI (and:SI (ashift:SI (reg:SI 4 r4 [170])
(const_int 8 [0x8]))
(const_int 65280 [0xff00]))
(and:SI (ashiftrt:SI (reg:SI 4 r4 [170])
(const_int 8 [0x8]))
(const_int 255 [0xff]) swapb_ice.c:14 209 {swapbsi2}
(nil))
swapb_ice.c:15:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:774
Only fails for -m4 (-m2, ... are OK)
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #2 from Kostya Serebryany --- does this happen with clang trunk? BTW, I hope to do a fresh merge in the nearest 2-3 weeks.
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #8 from vincenzo Innocente --- Yes I compile gcc with -O2 -ftree-vectorize on linux I also do bootstrap-lto strange that the compiler does not warn about this uninitialized variable: it does for a couple of others that force me to compile with -disable-werror
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #7 from Jakub Jelinek --- I bet the difference is probably that your tree-vect-stmts.o has been compiled with -O2, while mine with -O0.
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #6 from vincenzo Innocente --- seems so gcc -O2 libgomp/testsuite/libgomp.c/simd-4.c -fopenmp c++ -O2 -S omp4red.cc -fopenmp| cat omp4red.s .text .align 4,0x90 .globl __Z5sumO1v __Z5sumO1v: LFB0: etc could you please send me your ./configure I do not understand why it crashes on me both on Linux and MacOS mine are in the previous comments…
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-19 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Created attachment 30862 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30862&action=edit gcc49-pr58472.patch I can't reproduce this either, but from looking at the code, I guess it is simply a matter of using an uninitialized variable - inv_p. Does this patch fix that?
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #6 from Marc Glisse --- Author: glisse Date: Thu Sep 19 11:40:29 2013 New Revision: 202737 URL: http://gcc.gnu.org/viewcvs?rev=202737&root=gcc&view=rev Log: 2013-09-19 Marc Glisse PR libstdc++/58338 * include/bits/stl_tree.h (_Rb_tree_node_base) [_S_minimum, _S_maximum]: Mark as noexcept. (_Rb_tree_iterator) [_Rb_tree_iterator, operator*, operator->, operator++, operator--, operator==, operator!=]: Likewise. (_Rb_tree_const_iterator) [_Rb_tree_const_iterator, _M_const_cast, operator*, operator->, operator++, operator--, operator==, operator!=]: Likewise. (operator==(const _Rb_tree_iterator&, const _Rb_tree_const_iterator&), operator!=(const _Rb_tree_iterator&, const _Rb_tree_const_iterator&)): Likewise. (_Rb_tree) [_M_put_node, _M_destroy_node, _M_root, _M_leftmost, _M_rightmost, _M_begin, _M_end, _S_left, _S_right, _S_minimum, _S_maximum]: Likewise. * include/debug/string (basic_string) [basic_string(const _Allocator&), shrink_to_fit, operator[], pop_back]: Likewise. * include/ext/vstring.h (__versa_string) [_M_limit, _M_disjunct, _M_ibegin, _M_iend, __versa_string(const _Alloc&), operator=(__versa_string&&), shrink_to_fit, operator[], front, back, assign(__versa_string&&), swap]: Likewise. (__versa_string) [__versa_string(), __versa_string(const _Alloc&)]: Merge. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/include/debug/string trunk/libstdc++-v3/include/ext/vstring.h
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #18 from Marc Glisse --- [Ugh, bugzilla seems half broken at the moment] > I would suggest my current patch (which is simpler than it looks from the > diff) for previous versions, then investigate pivot. Well, you're the one doing all the work ;-) (svn diff --diff-cmd diff -x -u10 (actually I have diff-cmd = diff-for-svn in ~/.subversion/config where diff-for-svn is a script where I put the options I like, so svn diff does it by default), too bad -p often doesn't work well with C++)
[Bug target/54272] [SH] Add support for addv / subv instructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272
--- Comment #6 from Oleg Endo ---
Another example where addv could be used:
int test (int a)
{
if (a == 0x7FFF)
return a;
return a + 1;
}
currently compiles to:
-O2 -m2a:
mov.l .L6,r1
cmp/eq r1,r4
bt.s.L4
mov r4,r0
add #1,r0
.L4:
rts/n
.align 2
.L6:
.long 2147483647
-O2 -m4:
mov.l .L4,r1
mov #-1,r0
cmp/eq r1,r4
negcr0,r0
rts
add r4,r0
.align 2
.L4:
.long 2147483647
better:
SH4 with zero displacement branch:
mov #1,r0
addvr4,r0 // T = r0 == 0x8000 (overflow)
bt 0f
mov r4,r0
0:
rts
nop
branch-free:
mov#1,r0
mov#0,r1
addvr4,r0 // T = r0 == 0x8000 (overflow)
rts
subcr1,r0 // r0 = r0 - r1 - T
[Bug libstdc++/58358] [4.7 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Version|4.8.1 |4.8.2 Resolution|--- |FIXED Summary|[4.7/4.8 Regression]|[4.7 Regression] search_n |search_n has a Complexity |has a Complexity violation |violation for random access |for random access iterator |iterator| --- Comment #27 from Paolo Carlini --- Fixed for 4.8.2 too. WONTFIX in 4.7.x.
[Bug libstdc++/58358] [4.7/4.8 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #26 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Sep 19 10:19:58 2013 New Revision: 202736 URL: http://gcc.gnu.org/viewcvs?rev=202736&root=gcc&view=rev Log: 2013-09-19 Mitsuru Kariya Chris Jefferson PR libstdc++/58358 * include/bits/stl_algo.h (search_n): Fix to guarantee a number of comparisons <= number of elements in the range. * testsuite/25_algorithms/search_n/58358.cc: New. * testsuite/25_algorithms/search_n/iterator.cc: Extend. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/25_algorithms/search_n/58358.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_algo.h branches/gcc-4_8-branch/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #17 from Paolo Carlini --- Can I ask you also a rather simple test for testsuite/performance/25_algorithms?
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #16 from Chris Jefferson --- Indeed, if std::sort had never used lower-level partitioning to get the pivot in the correct location, we would never have had this problem in the first place! This is not too serious a problem performance-wise (as the pivot ends up in the right place fairly quickly), but it would certainly be better to do that in future. Unfortunately doing this requires changing quite a few functions, to make all code which uses partition skip over the pivot value. I would suggest my current patch (which is simpler than it looks from the diff) for previous versions, then investigate pivot. In general I would like to modernise the sort to match more modern thoughts on sorting such as making use of partly sorted data (which would include reverse-ordered). The only problem there is satisfying all the requirements of std::sort). (detail: -p doesn't help, you just get things like " -110,16 +112,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION". Neither -u 10, -x -u 10 or -x "-u 10" seem to work, I just get errors. If you can give me the exact svn diff command to run to get nicer output, I am happy to do so).
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 --- Comment #4 from vincenzo Innocente --- gcc -O2 libgomp/testsuite/libgomp.c/simd-3.c -fopenmp libgomp/testsuite/libgomp.c/simd-3.c: In function ‘foo’: libgomp/testsuite/libgomp.c/simd-3.c:14:1: internal compiler error: in vectorizable_store, at tree-vect-stmts.c:4192 foo (int *p) ^ libgomp/testsuite/libgomp.c/simd-3.c:14:1: internal compiler error: Abort trap: 6 gcc: internal compiler error: Abort trap: 6 (program cc1) Abort trap: 6 agree that something is fishy here gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.4.0/4.9.0/lto-wrapper Target: x86_64-apple-darwin12.4.0 Configured with: ./configure --disable-multilib --disable-bootstrap --enable-lto -disable-libitm --enable-languages=c,c++,fortran,lto --disable-libsanitizer : (reconfigured) ./configure --disable-multilib --disable-bootstrap --enable-lto -disable-libitm --enable-languages=c,c++,fortran,lto --disable-libsanitizer Thread model: posix gcc version 4.9.0 20130918 (experimental) [gomp-4_0-branch revision 202735] (GCC)
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #15 from Paolo Carlini --- Thanks a lot guys, I appreciate all the help you are providing. While fixing this, let's remember that this regressed even in the old 4.7.x branch. Thus, if we are sure we are minimally restoring the performance of the C++03 code, we could also envisage a very minimal but *very* safe fix for 4.7.4 and 4.8.2 and something a tad more aggressive for 4.9.0.
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472
--- Comment #3 from vincenzo Innocente ---
on linux
c++ -O2 -ftree-vectorizer-verbose=1 -S omp4red.cc -fopenmp
omp4red.cc:8:13: note: loop vectorized
omp4red.cc: In function 'float sumO1()':
omp4red.cc:4:7: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:4192
float sumO1() {
^
0xdd070e vectorizable_store
../../gcc-gomp4/gcc/tree-vect-stmts.c:4192
0xdd0a7e vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator_d*,
bool*, _slp_tree*, _slp_instance*)
../../gcc-gomp4/gcc/tree-vect-stmts.c:5959
0xe958e3 vect_transform_loop(_loop_vec_info*)
../../gcc-gomp4/gcc/tree-vect-loop.c:5859
0xe9fed2 vectorize_loops()
../../gcc-gomp4/gcc/tree-vectorizer.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-gomp4/configure
--prefix=/afs/cern.ch/user/i/innocent/w2 --enable-languages=c,c++,lto,fortran
-enable-gold=yes --enable-lto --with-build-config=bootstrap-lto
--with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64
-with-mpc-lib=/usr/local/lib64 --enable-cloog-backend=isl
--with-cloog=/usr/local --with-ppl-lib=/usr/local/lib64 CFLAGS='-O2
-ftree-vectorize -fPIC' -enable-libitm -disable-multilib -disable-werror
--disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20130918 (experimental) [gomp-4_0-branch revision 202731]
(GCC)
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472
--- Comment #2 from vincenzo Innocente ---
yes
cat omp4red.cc
float a[1024];
float b[1024];
float sumO1() {
float s = 0.f;
#pragma omp simd reduction(+:s)
for (int i=0;i<1024;++i) {
s += a[i]*b[i];
}
return s;
}
pb-d-128-141-131-26:vectorize innocent$ c++ -O2 -ftree-vectorizer-verbose=1
-S omp4red.cc -fopenmp
omp4red.cc:8:13: note: loop vectorized
omp4red.cc: In function ‘float sumO1()’:
omp4red.cc:4:7: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:4192
float sumO1() {
^
omp4red.cc:4:7: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
pb-d-128-141-131-26:vectorize innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.4.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin12.4.0
Configured with: ./configure --disable-multilib --disable-bootstrap
--enable-lto -disable-libitm --enable-languages=c,c++,fortran,lto
--disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20130918 (experimental) (GCC)
I will try on linux (should make no difference)
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #39 from Bernd Edlinger --- (In reply to Martin Jambor from comment #37) > In order to use movmisalign_optab > instructions when we can, we should probably only do it if tem is a > structure with a zero sized array. I do also see possible problems with volatile accesses here. If we do not really need the whole structure reading everything would be wrong.
[Bug target/58394] unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58394 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #3 from Richard Earnshaw --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg3.html
[Bug tree-optimization/58473] [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58473 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- See also http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01417.html .
[Bug tree-optimization/58472] gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I can't reproduce it (with r202732 and without the #include); does it reproduce for you without the ?
[Bug tree-optimization/58473] New: [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58473 Bug ID: 58473 Summary: [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: rguenther at suse dot de Blocks: 58417 Target: ia64-*-* Regressed by r202700. $ gcc/xg++ -shared-libgcc -Bgcc -nostdinc++ -Lia64-suse-linux/libstdc++-v3/src -Lia64-suse-linux/libstdc++-v3/src/.libs -Lia64-suse-linux/libstdc++-v3/libsupc++/.libs -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem /usr/ia64-suse-linux/include -isystem /usr/ia64-suse-linux/sys-include -Bia64-suse-linux/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -O2 -g -D_GNU_SOURCE -O2 -g -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -Iia64-suse-linux/libstdc++-v3/include/ia64-suse-linux -Iia64-suse-linux/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util ../libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc -std=c++0x ia64-suse-linux/libstdc++-v3/testsuite/libtestc++.a -lm -o ./default.exe ../libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc: In constructor ‘__gnu_cxx::normal_mv_distribution<_Dimen, _RealType>::param_type::param_type() [with long unsigned int _Dimen = 2ul; _RealType = double]’: ../libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc:49:1: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:148 } ^ 0x411d1fff build_polynomial_chrec ../../gcc/tree-chrec.h:148 0x411d7abf chrec_fold_plus_1 ../../gcc/tree-chrec.c:290 0x411d849f chrec_fold_plus(tree_node*, tree_node*, tree_node*) ../../gcc/tree-chrec.c:373 0x411d755f chrec_fold_plus_poly_poly ../../gcc/tree-chrec.c:153 0x411d7a2f chrec_fold_plus_1 ../../gcc/tree-chrec.c:279 0x411d84ef chrec_fold_plus(tree_node*, tree_node*, tree_node*) ../../gcc/tree-chrec.c:373 0x40c2347f interpret_rhs_expr ../../gcc/tree-scalar-evolution.c:1692 0x40c1d5ef interpret_gimple_assign ../../gcc/tree-scalar-evolution.c:1810 0x40c1d5ef analyze_scalar_evolution_1 ../../gcc/tree-scalar-evolution.c:1892 0x40c1ea9f analyze_scalar_evolution(loop*, tree_node*) ../../gcc/tree-scalar-evolution.c:1947 0x40c212ff analyze_scalar_evolution_in_loop ../../gcc/tree-scalar-evolution.c:2043 0x40c2157f simple_iv(loop*, loop*, tree_node*, affine_iv*, bool) ../../gcc/tree-scalar-evolution.c:3167 0x407facbf estimate_function_body_sizes ../../gcc/ipa-inline-analysis.c:2562 0x407fc15f compute_inline_parameters(cgraph_node*, bool) ../../gcc/ipa-inline-analysis.c:2696 0x407fc4af inline_analyze_function ../../gcc/ipa-inline-analysis.c:3684 0x407fc8af inline_generate_summary() ../../gcc/ipa-inline-analysis.c:3735 0x4099648f execute_ipa_summary_passes(ipa_opt_pass_d*) ../../gcc/passes.c:2000 0x4053614f ipa_passes ../../gcc/cgraphunit.c:2008 0x4053614f compile() ../../gcc/cgraphunit.c:2115 0x40536d1f finalize_compilation_unit() ../../gcc/cgraphunit.c:2269
[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697 --- Comment #11 from Dominique d'Humieres --- The test gfortran.dg/defined_assignment_11.f90 fails on x86_64-apple-darwin10: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Valgrind reports ==30916== Invalid read of size 4 ==30916==at 0x121EF: MAIN__ (defined_assignment_11_db.f90:40) ==30916==by 0x12C5B: main (defined_assignment_11_db.f90:35) ==30916== Address 0x0 is not stack'd, malloc'd or (recently) free'd It is probably related to comment #10.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #14 from Marc Glisse --- Hi Chris, (detail: could you pass -u10, or at least -p, to diff to make the patches easier to read? It isn't required so you don't have to) I don't really understand why the pivot is still considered in lower levels of the recursion at all. So, first we move the pivot to the first position with a swap: (pivot, rest...) Then we partition: (pivot, small..., big...) Then we know what the right position is for the pivot (this isn't a stable sort), so we could put it there with another swap: (small..., pivot, big...) And now we can recurse on small and big, and no one needs to look at the pivot ever again. >From what I understand of the code, we are instead relying on recursive calls to eventually sort pivot to the right position, which seems strange to me.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #13 from Chris Jefferson --- Created attachment 30861 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30861&action=edit Sort patch Wow, this an embarrassing bug to get through testing. Obviously not enough profiling done! This patch (I hope) gets performance back to g++-4.4 levels, and in my experiments slightly (but not noticeably) better. I would be interested in anyone trying out this patch on their own data. For the interested, here is a description of the bug. I will assume you understand quicksort! Quicksort requires taking a pivot, then partitioning the array by that pivot. Getting O(n log n) behaviour requires that you choose a "good" pivot. Like most people, in g++ we choose the median of the first, middle, and last value in the array as the pivot. In the C++03 world, after we chose the pivot we took a copy of it. In C++11, we cannot copy values in std::sort any more, only move and swap. Trying to keep track of the pivot as it moves around during the partitioning is horrible and inefficient. So, I had the "bright idea" to do swap(*first, *pivot). Now the pivot is at the first location in the array, and we can just partition [first+1, end) and the partitioning is fine. See the mistake yet? The bug comes when we recursively partition the first cell. We again choose the median from the first, mid and last of this cell, but *first is always the biggest thing in the cell (as we pivoted on it one level above), meaning our median calculation is unbalanced and often chooses terrible values, leading to us often hitting the O(n^2) behaviour of quicksort (actually we technically get o(n log n), as we switch to heapsort when things are going badly, but the time is still bad). There are a selection of ways of fixing this. This patch switches the median calculation from considering then first, mid, last locations to on first+1, mid, last-1 (there is no reason in this bug to consider last-1 instead of last, but I thought it wouldn't do any harm, and might avoid other issues of accidentally choosing a bad pivot.
[Bug tree-optimization/58472] New: gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58472
Bug ID: 58472
Summary: gomp4: ICE in in vectorizable_store, at
tree-vect-stmts.c:4192
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
#include
float a[1024];
float b[1024];
float sumO1() {
auto s = 0.f;
#pragma omp simd reduction(+:s)
for (auto i=0U;i<1024;++i) {
s += a[i]*b[i];
}
return s;
}
pb-d-128-141-131-26:vectorize innocent$ c++ -std=c++11 -O2
-ftree-vectorizer-verbose=1 -S omp4.cc -fopenmp
omp4.cc:9:13: note: loop vectorized
omp4.cc: In function ‘float sumO1()’:
omp4.cc:5:7: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:4192
float sumO1() {
^
omp4.cc:5:7: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
