[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 --- Comment #10 from Magnus Reftel --- Applied Manuel López-Ibáñez's patch on top of trunk and tested Jeremy's testcase. Without the patch, the error message says that "__attribute__((noreturn))" is being cast away. With the patch, the error message says that "volatile" is being cast away. Running "make check" to see if there were any regressions.
[Bug libstdc++/60497] unique_ptr tries to complete its type T even though it's not required to be a complete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-11 Component|c++ |libstdc++ Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Whether it is required or not, qualifying the call to __get_helper is easy enough (it may even be slightly faster to compile), it seems worth doing. Now the question would be: are there similar statements throughout the library that could benefit from the same treatment, or is this a special case? Thanks for the detailed analysis.
[Bug fortran/60495] [4.9 Regression] ICE: in fold_convert_loc, at fold-const.c:1994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > It could be r200954. The backtrace is similar to the one for > pr58880 (duplicate?). Very likely.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #23 from rguenther at suse dot de --- On Mon, 10 Mar 2014, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 > > --- Comment #20 from H.J. Lu --- > (In reply to Richard Biener from comment #13) > > Huh, adding a pre-header should _never_ do sth like that. Can you produce > > a small testcase that exhibits these kind of changes with adding/removing > > a preheader? > > copyprop2 pass removed a preheader and cunrolli pass added it back: > > : > # n_213 = PHI <1(2)> > > : > # n_8 = PHI Not sure how it manages to add this kind of PHI node for just adding a preheader? That looks odd to me. > copyprop3 pass optimized it to > > : > n_213 = 1; > > : > # n_8 = PHI <1(3), n_218(7)> > > Then the unused n_213 disappeared in reassoc1 pass and n_213 was > put on FREE_SSANAMES. By dce1 probably. That's all expected optimizations and not really dependent on preheader add/remove. Richard.
[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #5 from bin.cheng --- Vrp1 generates below code: : if (b_elt_11(D) != 0B) goto ; else goto ; : # kill_elt_10 = PHI goto ; : kill_elt_14 = kill_elt_2->next; : # kill_elt_2 = PHI if (kill_elt_2 != 0B) goto ; else goto ; : _12 = kill_elt_2->indx; _13 = b_elt_11(D)->indx; if (_12 < _13) goto ; else goto ; ... : goto ; : # kill_elt_41 = PHI <0B(6)> if (b_elt_11(D) != 0B) goto ; else goto ; The whole bb 19 is unnecessary since we know "b_elt_11(D) != 0" holds.
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 --- Comment #4 from Jakub Jelinek --- Created attachment 32332 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32332&action=edit gcc49-pr60482-2.patch Untested fix for the ssa-ifcombine-10.c regression. It seems that previously, with a useless ASSERT_EXPR: : _4 = x_3(D) & 1; if (_4 == 0) goto ; else goto ; : x_8 = ASSERT_EXPR ; x_9 = ASSERT_EXPR ; _5 = x_9 & 4; if (_5 != 0) goto ; else goto ; : x_7 = ASSERT_EXPR ; goto ; : : # t_1 = PHI <0(2), 3(6), 0(4)> return t_1; (the x_7 one) VRP had to create a new bb for it and while it has been removed afterwards, it ended up swapping the basic blocks in the second condition, from: : _5 = x_3(D) & 4; if (_5 != 0) goto ; else goto ; : : # t_1 = PHI <0(2), 3(3), 0(4)> to: : _5 = x_3(D) & 4; if (_5 != 0) goto ; else goto ; : : # t_1 = PHI <0(2), 3(4), 0(3)> E.g. with -fno-tree-vrp, ssa-ifcombine-10.c fails already on vanilla trunk. The attached untested patch should handle this situation.
[Bug libstdc++/60499] [4.9 Regression] non-reserved name in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60499 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- .
[Bug libstdc++/60499] New: [4.9 Regression] non-reserved name in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60499
Bug ID: 60499
Summary: [4.9 Regression] non-reserved name in
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
#define xfer_memory 1
#include
int main()
{
__gnu_debug::vector a, b;
a = std::move(b);
}
$ g++-4.9 -std=c++11 v.cc
/home/jwakely/gcc/4.x/include/c++/4.9.0/debug/vector: In member function
‘std::__debug::vector<_Tp, _Allocator>& std::__debug::vector<_Tp,
_Allocator>::operator=(std::__debug::vector<_Tp, _Allocator>&&)’:
v.cc:1:21: error: expected unqualified-id before numeric constant
#define xfer_memory 1
^
[Bug libstdc++/60499] [4.9 Regression] non-reserved name in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60499 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #2 from Jonathan Wakely --- forward_list, the RB trees and the hash tables have the same problem.
[Bug fortran/60500] New: Spurious warning on derived type initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60500 Bug ID: 60500 Summary: Spurious warning on derived type initialization Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.hogg at stfc dot ac.uk The following code: module spurious_warning implicit none type :: ntype integer :: level = 1 end type ntype contains subroutine sub1(n1, n2, st) integer, intent(in) :: n1, n2 integer, intent(out) :: st type(ntype), dimension(:), allocatable :: work1 integer, dimension(:), allocatable :: work2 allocate(work1(n1), stat=st) if(st.ne.0) return allocate(work2(n2), stat=st) if(st.ne.0) return end subroutine sub1 end module spurious_warning Produces the following spurious warning: [user@host]$ gfortran-4.8 -O2 -Wall -c bug.f90 bug.f90: In function ‘sub1’: bug.f90:12:0: warning: ‘work1.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized] type(ntype), dimension(:), allocatable :: work1 ^ With the following compiler version: GNU Fortran (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1 Notes: Removal of -O2 removes the sprurious warning. Removal of the second allocation removes spurious warning. Removal of default value in type definition removes spurious warning. Working theory: The automatic initialization accesses array size as part of implementation?
[Bug middle-end/60500] [4.7/4.8/4.9 Regression] Spurious warning on derived type initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60500 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-11 Component|fortran |middle-end Summary|Spurious warning on derived |[4.7/4.8/4.9 Regression] |type initialization |Spurious warning on derived ||type initialization Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- No warning when compiling the test with r176695 (2011-07-23), warning with r176935 (2011-07-29).
[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #6 from bin.cheng --- After investigation, I think the root cause is: For given mergephi2 dump (before vrp), there are latch(bb13) and header(bb14) of a loop: : # changed_18 = PHI : # changed_1 = PHI # kill_elt_4 = PHI if (a_elt_9(D) != 0B) goto ; else goto ; The latch is removed by the bogus patch, and the code turns into: : # changed_1 = PHI # kill_elt_4 = PHI if (a_elt_9(D) != 0B) goto ; else goto ; Since VRP requires LOOP_HAVE_SIMPLE_LATCH, it will be initialized into: : # changed_19 = PHI # kill_elt_18 = PHI : # changed_1 = PHI # kill_elt_4 = PHI if (a_elt_9(D) != 0B) goto ; else goto ; After all works in vrp (including jump threading), the code is transformed into below form: : # kill_elt_2 = PHI if (kill_elt_2 != 0B) goto ; else goto ; : goto ; ... : # changed_19 = PHI # kill_elt_18 = PHI : # changed_1 = PHI # kill_elt_4 = PHI if (a_elt_9(D) != 0B) goto ; else goto ; ... : goto ; : # kill_elt_41 = PHI <0B(21)> if (b_elt_11(D) != 0B) goto ; else goto ; When trying to remove bb26, it finds out bb27 is pred of both bb26 and bb14, then checks whether the phi args are consistent for both edges (<26, 14> and <27, 14>). Apparently "0B(26)" != "kill_elt_3(27)", resulting in keeping bb27. Actually, kill_elt_3(27) equals to "0", because of check condition in bb18. So this might be a missed opportunity in vrp?
[Bug fortran/60495] [4.9 Regression] ICE: in fold_convert_loc, at fold-const.c:1994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/60493] g++ throws segmentation fault on simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60493
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-11
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed.
t.C:10:21: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:11518
class Splay::iterator : std::iterator {
[Bug rtl-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #11 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> If I modify the shorter testcase such that int e[2]; is a static array, then
> we don't generate cmove for it, because on:
> (mem:SI (const:DI (plus:DI (symbol_ref:DI ("e") )
> (const_int 524288 [0x8]))) [2 e+524288 S4 A32])
> may_trap_or_fault_p returns true (correctly). But in the case of automatic
> out-of-bound access we get instead:
> (mem/c:SI (plus:DI (reg/f:DI 20 frame)
> (const_int 524272 [0x7fff0])) [2 S4 A128])
> and there may_trap_or_fault_p really can't (easily) know if it is valid or
> not, there is no MEM_EXPR even. This is because in the #c2 testcase as well
> as the original one DECL_RTL of e variable is a register, not MEM.
> But even if I try:
> int a;
> __attribute__((noinline, noclone)) void
> foo (int *e)
> {
> asm volatile ("" : : "r" (e) : "memory");
> }
>
> int
> main ()
> {
> int e[2] = { 0, 0 }, f = 0;
> if (a == 131072)
> f = e[a];
> foo (e);
> return f;
> }
> where we have:
> (mem:SI (plus:DI (reg/f:DI 20 frame)
> (const_int 524272 [0x7fff0])) [2 e+524288 S4 A128])
> instead and thus from MEM_EXPR we perhaps could find out that it is an out
> of bound access, we still always treat all frame based accesses (whatever
> the offset is) as non-trapping.
> So perhaps we need to handle known out of bound MEMs specially when we find
> that fact out (if we want to emit them into the RTL IL at all), one thing is
> expansion, another thing if say initially non-constant offset is later
> CSEd/forwprop etc. into constant out of bound offset.
>
> Thoughts?
Well, may_trap_or_fault_p has to be conservative. See how tree_could_trap_p
handles bound violations. If you can't prove it isn't out-of-bounds
then you have to assume it may be.
[Bug c++/60493] g++ throws segmentation fault on simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60493
Jakub Jelinek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
template
struct foo
{
};
template
struct baz
{
class bar;
};
template
struct baz::bar : foo
{
};
baz::bar it;
Fails even with r9, or g++ 3.2, so probably not a regression.
[Bug other/60486] [avr] missed optimization on detecting zero flag set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486 --- Comment #4 from Darryl Piper --- details also posted on avrfreaks.net http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1143389 the bug has existed since the code base copy from 4.7.2 to create the vanilla 4.8.0 so all the 4.8.[0,1,2] suffer this bug namely these lines in avr_out_plus are the culprits IMO. /* Work out the shortest sequence. */ avr_out_plus_1 (op, &len_minus, MINUS, &cc_plus, code_sat, sign, out_label); avr_out_plus_1 (op, &len_plus, PLUS, &cc_minus, code_sat, sign, out_label); notice the &cc_plus and &cc_minus being the wrong way around.
[Bug other/60486] [avr] missed optimization on detecting zero flag set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486 Darryl Piper changed: What|Removed |Added Severity|normal |major
[Bug target/60486] [4.8/4.9 Regression] [avr] superfluous or missing comparision after addition or subtraction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
Georg-Johann Lay changed:
What|Removed |Added
Keywords||wrong-code
Component|other |target
Summary|[avr] missed optimization |[4.8/4.9 Regression] [avr]
|on detecting zero flag set |superfluous or missing
||comparision after addition
||or subtraction
Known to fail||4.9.0
--- Comment #5 from Georg-Johann Lay ---
Target issue.
(In reply to Darryl Piper from comment #4)
> details also posted on avrfreaks.net
I am well aware of this post.
But GCC reports are supposed to be self contained. So here we go:
Root cause is swapped cc_plus and cc_minus in avr.c:avr_out_plus :
/* Work out the shortest sequence. */
avr_out_plus_1 (op, &len_minus, MINUS, &cc_plus, code_sat, sign, out_label);
avr_out_plus_1 (op, &len_plus, PLUS, &cc_minus, code_sat, sign, out_label);
Thus there are also cases where wrong code is generated like the following one:
extern void foo (unsigned);
char v;
void bar (unsigned long z)
{
if (++z == 0)
v = 0;
foo (z);
}
Output is missing the comparison because addsi3 does not set cc0 in a usable
way when is uses the PLUS alternative:
bar:
movw r26,r24 ; 20*movsi/1[length = 2]
movw r24,r22
adiw r24,1 ; 6addsi3/2[length = 3]
adc r26,__zero_reg__
adc r27,__zero_reg__
brne .L5 ; 8branch[length = 1]
sts v,__zero_reg__ ; 10movqi_insn/3[length = 2]
.L5:
rjmp foo ; 14call_insn/4[length = 1]
[Bug middle-end/60429] [4.7/4.8/4.9 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #22 from Richard Biener --- Author: rguenth Date: Tue Mar 11 12:42:18 2014 New Revision: 208479 URL: http://gcc.gnu.org/viewcvs?rev=208479&root=gcc&view=rev Log: 2014-03-11 Richard Biener PR tree-optimization/60429 PR tree-optimization/60485 * tree-ssa-structalias.c (set_union_with_increment): Properly take into account all fields that overlap the shifted vars. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (get_constraint_for_ptr_offset): Likewise. * gcc.dg/pr60485-1.c: New testcase. * gcc.dg/pr60485-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr60485-1.c trunk/gcc/testsuite/gcc.dg/pr60485-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/60485] field-sensitive points-to confused by pointer offsetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485 --- Comment #2 from Richard Biener --- Author: rguenth Date: Tue Mar 11 12:42:18 2014 New Revision: 208479 URL: http://gcc.gnu.org/viewcvs?rev=208479&root=gcc&view=rev Log: 2014-03-11 Richard Biener PR tree-optimization/60429 PR tree-optimization/60485 * tree-ssa-structalias.c (set_union_with_increment): Properly take into account all fields that overlap the shifted vars. (do_sd_constraint): Likewise. (do_ds_constraint): Likewise. (get_constraint_for_ptr_offset): Likewise. * gcc.dg/pr60485-1.c: New testcase. * gcc.dg/pr60485-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr60485-1.c trunk/gcc/testsuite/gcc.dg/pr60485-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 --- Comment #11 from Magnus Reftel --- No regressions seen. Sent en email with the patch to gcc-patches as requested ( http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00517.html ).
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Richard Biener changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |Miscompilation (aliasing) |Miscompilation (aliasing) |with -finline-functions |with -finline-functions --- Comment #23 from Richard Biener --- Should be fixed for 4.9 (sofar). Would be nice if you can verify that it fixes the original problem (it fixes your reduced testcase for me).
[Bug tree-optimization/60485] field-sensitive points-to confused by pointer offsetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug rtl-optimization/58195] Missed optimization opportunity when returning a conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195 Joel Yliluoma changed: What|Removed |Added CC||bisqwit at iki dot fi --- Comment #1 from Joel Yliluoma --- Problem confirmed on "gcc (GCC) 4.9.0 20140303 (experimental)" (SVN version) in both 32-bit and 64-bit mode using -Ofast. For comparison, Clang++ produces this instead (even on -O1): negl%edi movl%edi, %eax ret GCC misses an optimization opportunity here.
[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-11 Component|rtl-optimization|tree-optimization Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #2 from Richard Biener --- phiopt should notice : if (input_2(D) != 0) goto ; else goto ; : iftmp.0_3 = -input_2(D); : # iftmp.0_1 = PHI and value-replace iftmp.0_1 by -input_2(D).
[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58195 --- Comment #3 from Marc Glisse --- This looks like the unary version of: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00014.html and something that could be auto-generated from a pattern like: (cond (ne @0 0) (negate @0) 0) -> (negate @0) ;-)
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #24 from Allan Jensen --- I just tested the latest subversion head of gcc 4.9 and can confirm it fixes the original problem (tst_qregion in Qt 5.2.1 compiled with -O3).
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #24 from H.J. Lu --- (In reply to rguent...@suse.de from comment #23) > On Mon, 10 Mar 2014, hjl.tools at gmail dot com wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 > > > > --- Comment #20 from H.J. Lu --- > > (In reply to Richard Biener from comment #13) > > > Huh, adding a pre-header should _never_ do sth like that. Can you produce > > > a small testcase that exhibits these kind of changes with adding/removing > > > a preheader? > > > > copyprop2 pass removed a preheader and cunrolli pass added it back: > > > > : > > # n_213 = PHI <1(2)> > > > > : > > # n_8 = PHI > > Not sure how it manages to add this kind of PHI node for just > adding a preheader? That looks odd to me. > (gdb) bt #0 make_ssa_name_fn (fn=0x7f039cc63d20, var=0x7f039d127ed8, stmt=0x7f039c095800) at ../../../../gcc/gcc/tree-ssanames.c:133 #1 0x00c66392 in copy_ssa_name_fn (fn=0x7f039cc63d20, name=0x7f039cacdcf0, stmt=0x7f039c095800) at ../../../../gcc/gcc/tree-ssanames.c:459 #2 0x00a7e389 in copy_ssa_name (var=0x7f039cacdcf0, stmt=0x7f039c095800) at ../../../../gcc/gcc/tree-ssanames.h:118 #3 0x00a8d874 in gimple_make_forwarder_block (fallthru=0x7f039d777f18) at ../../../../gcc/gcc/tree-cfg.c:5291 #4 0x0061a663 in make_forwarder_block (bb=0x7f039d0c7a90, redirect_edge_p=0x627199 , new_bb_cbk=0x0) at ../../../../gcc/gcc/cfghooks.c:912 #5 0x00627416 in create_preheader (loop=0x7f039d25e280, flags=1) at ../../../../gcc/gcc/cfgloopmanip.c:1552 #6 0x0062756a in create_preheaders (flags=1) at ../../../../gcc/gcc/cfgloopmanip.c:1602 #7 0x008b76ee in apply_loop_flags (flags=15) at ../../../../gcc/gcc/loop-init.c:63 #8 0x008b780d in loop_optimizer_init (flags=15) at ../../../../gcc/gcc/loop-init.c:121 #9 0x00b9ef15 in tree_complete_unroll_inner () at ../../../../gcc/gcc/tree-ssa-loop-ivcanon.c:1377 #10 0x00b9efcf in (anonymous namespace)::pass_complete_unrolli::execute ---Type to continue, or q to quit--- (this=0x28d2110) at ../../../../gcc/gcc/tree-ssa-loop-ivcanon.c:1422 #11 0x00968b76 in execute_one_pass (pass=0x28d2110) at ../../../../gcc/gcc/passes.c:2229 #12 0x00968d8f in execute_pass_list (pass=0x28d2110) at ../../../../gcc/gcc/passes.c:2282 #13 0x00968dc0 in execute_pass_list (pass=0x28d1ed0) at ../../../../gcc/gcc/passes.c:2283 #14 0x0064676a in expand_function (node=0x7f039dba5668) at ../../../../gcc/gcc/cgraphunit.c:1774 #15 0x00646d5e in expand_all_functions () at ../../../../gcc/gcc/cgraphunit.c:1908 #16 0x0064772a in compile () at ../../../../gcc/gcc/cgraphunit.c:2252 #17 0x0059a615 in lto_main () at ../../../../gcc/gcc/lto/lto.c:3427 #18 0x00a53c2c in compile_file () at ../../../../gcc/gcc/toplev.c:548 #19 0x00a55dc3 in do_compile () at ../../../../gcc/gcc/toplev.c:1914 #20 0x00a55f2e in toplev_main (argc=24, argv=0x28ac850) at ../../../../gcc/gcc/toplev.c:1990 #21 0x011dde12 in main (argc=24, argv=0x7fffdea91ed8) at ../../../../gcc/gcc/main.c:36 (gdb)
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #32 from Jakub Jelinek ---
Ok, I've done an --enable-checking=yes,rtl bootstrap on x86_64-linux and
i686-linux, and collected statistics without your patch, but with:
--- gcc/combine-stack-adj.c.jj2014-02-06 17:37:02.173062234 +0100
+++ gcc/combine-stack-adj.c2014-03-11 12:43:26.472118796 +0100
@@ -82,7 +82,7 @@ static rtx single_set_for_csa (rtx);
static void free_csa_reflist (struct csa_reflist *);
static struct csa_reflist *record_one_stack_ref (rtx, rtx *,
struct csa_reflist *);
-static int try_apply_stack_adjustment (rtx, struct csa_reflist *,
+static int try_apply_stack_adjustment (rtx, rtx, struct csa_reflist *,
HOST_WIDE_INT, HOST_WIDE_INT);
static void combine_stack_adjustments_for_block (basic_block);
static int record_stack_refs (rtx *, void *);
@@ -194,7 +194,7 @@ record_one_stack_ref (rtx insn, rtx *ref
on success. */
static int
-try_apply_stack_adjustment (rtx insn, struct csa_reflist *reflist,
+try_apply_stack_adjustment (rtx insn, rtx other, struct csa_reflist *reflist,
HOST_WIDE_INT new_adjust, HOST_WIDE_INT delta)
{
struct csa_reflist *ml;
@@ -230,6 +230,16 @@ try_apply_stack_adjustment (rtx insn, st
for (ml = reflist; ml ; ml = ml->next)
ml->sp_offset -= delta;
+if (RTX_FRAME_RELATED_P (insn) || RTX_FRAME_RELATED_P (other))
+{
+FILE *f = fopen ("/tmp/csa", "a");
+fprintf (f, "@@-@@ %s %d ", main_input_filename ? main_input_filename : "-",
(int) BITS_PER_WORD);
+print_inline_rtx (f, insn, 0);
+fprintf (f, "\n*** ");
+print_inline_rtx (f, other, 0);
+fprintf (f, "\n");
+fclose (f);
+}
return 1;
}
else
@@ -487,7 +497,7 @@ combine_stack_adjustments_for_block (bas
/* Combine an allocation into the first instruction. */
if (STACK_GROWS_DOWNWARD ? this_adjust <= 0 : this_adjust >= 0)
{
- if (try_apply_stack_adjustment (last_sp_set, reflist,
+ if (try_apply_stack_adjustment (last_sp_set, insn, reflist,
last_sp_adjust + this_adjust,
this_adjust))
{
@@ -504,7 +514,7 @@ combine_stack_adjustments_for_block (bas
else if (STACK_GROWS_DOWNWARD
? last_sp_adjust >= 0 : last_sp_adjust <= 0)
{
- if (try_apply_stack_adjustment (insn, reflist,
+ if (try_apply_stack_adjustment (insn, last_sp_set, reflist,
last_sp_adjust + this_adjust,
-last_sp_adjust))
{
@@ -526,6 +536,16 @@ combine_stack_adjustments_for_block (bas
{
if (last_sp_adjust == 0)
{
+if (RTX_FRAME_RELATED_P (insn) || RTX_FRAME_RELATED_P (last_sp_set))
+{
+FILE *f = fopen ("/tmp/csa", "a");
+fprintf (f, "@@-@@2 %s %d ", main_input_filename ? main_input_filename : "-",
(int) BITS_PER_WORD);
+print_inline_rtx (f, insn, 0);
+fprintf (f, "\n*** ");
+print_inline_rtx (f, last_sp_set, 0);
+fprintf (f, "\n");
+fclose (f);
+}
maybe_move_args_size_note (insn, last_sp_set, true);
delete_insn (last_sp_set);
}
@@ -564,7 +584,7 @@ combine_stack_adjustments_for_block (bas
&& XEXP (XEXP (dest, 0), 0) == stack_pointer_rtx
&& !reg_mentioned_p (stack_pointer_rtx, src)
&& memory_address_p (GET_MODE (dest), stack_pointer_rtx)
- && try_apply_stack_adjustment (insn, reflist, 0,
+ && try_apply_stack_adjustment (insn, last_sp_set, reflist, 0,
-last_sp_adjust))
{
if (last2_sp_set)
@@ -598,6 +618,16 @@ combine_stack_adjustments_for_block (bas
{
if (last_sp_set && last_sp_adjust == 0)
{
+if (RTX_FRAME_RELATED_P (insn) || RTX_FRAME_RELATED_P (last_sp_set))
+{
+FILE *f = fopen ("/tmp/csa", "a");
+fprintf (f, "@@-@@3 %s %d ", main_input_filename ? main_input_filename : "-",
(int) BITS_PER_WORD);
+print_inline_rtx (f, insn, 0);
+fprintf (f, "\n*** ");
+print_inline_rtx (f, last_sp_set, 0);
+fprintf (f, "\n");
+fclose (f);
+}
force_move_args_size_note (bb, last2_sp_set, last_sp_set);
delete_insn (last_sp_set);
}
@@ -611,6 +641,14 @@ combine_stack_adjustments_for_block (bas
if (last_sp_set && last_sp_adjust == 0)
{
+if (RTX_FRAME_RELATED_P (last_sp_set))
+{
+FILE *f = fopen ("/tmp/csa", "a");
+fprintf (f, "@@-@@4 %s %d ", main_input_filename ? main_input_filename : "-",
(int) BITS_PER_WORD);
+print_inline_rtx (f, last_sp_set, 0);
+fprintf (f, "\n");
+fclose (f);
+}
force_move_args_size_note (bb, last2_sp_set, last_sp_set);
delete_insn (last_sp_set);
}
The resulting file is too large to attach (316MB), but some statistics from it:
$ grep REG_CFA csa | sort | uniq -c | sort -n
491 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
1290 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
807
[Bug rtl-optimization/60501] New: LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 Bug ID: 60501 Summary: LRA emits add patterns which might clobber cc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Created attachment 32333 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32333&action=edit Experimental fix This actually is a follow-on to #57604. While debugging 435.gromacs I've noticed that LRA still emits add patterns which might clobber cc without actually checking whether this is valid. no lra: 4982a6: eb e6 00 01 00 df sllk%r14,%r6,1 4982ac: a7 78 00 02 lhi %r7,2 4982b0: 40 7e a0 00 sth %r7,0(%r14,%r10) 4982b4: 40 7e a0 02 sth %r7,2(%r14,%r10) 4982b8: 40 7e a0 04 sth %r7,4(%r14,%r10) 4982bc: b9 f2 30 06 locrnle %r0,%r6 lra: 49823e: eb 9e 00 01 00 df sllk%r9,%r14,1 <-- cc set 498244: 18 69 lr %r6,%r9 498246: 1a 6a ar %r6,%r10 <-- cc clobber 498248: e5 44 60 00 00 02 mvhhi 0(%r6),2 49824e: a7 78 00 02 lhi %r7,2 498252: a7 38 00 04 lhi %r3,4 498256: 1a 7a ar %r7,%r10 <-- cc clobber 498258: 1a 3a ar %r3,%r10 <-- cc clobber 49825a: 1a 79 ar %r7,%r9<-- cc clobber 49825c: 1a 39 ar %r3,%r9<-- cc clobber 49825e: e5 44 70 00 00 02 mvhhi 0(%r7),2 498264: b9 f2 30 0e locrnle %r0,%r14 <-- cc use Apart from the no lra code looking much better the LRA variant is dies with a miscompare. A potential solution has already been discussed in: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01174.html Richard proposed to have standard pattern names for pointer arithmetic. I've tried to implement this for S/390. With the attached (untested) patch I get the following: 97e: eb 9e 00 01 00 df sllk%r9,%r14,1 984: 41 69 a0 00 la %r6,0(%r9,%r10) 988: e5 44 60 00 00 02 mvhhi 0(%r6),2 98e: 19 0e cr %r0,%r14 990: a7 78 00 02 lhi %r7,2 994: 41 37 a0 00 la %r3,0(%r7,%r10) 998: 41 63 90 00 la %r6,0(%r3,%r9) 99c: e5 44 60 00 00 02 mvhhi 0(%r6),2 9a2: b9 f2 30 0e locrnle %r0,%r14
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 Andreas Krebbel changed: What|Removed |Added Target||s390x-ibm-linux Priority|P3 |P1 CC||vmakarov at redhat dot com Host||s390x-ibm-linux Target Milestone|--- |4.9.0 Summary|LRA emits add patterns |[4.9 regression] LRA emits |which might clobber cc |add patterns which might ||clobber cc Build||s390x-ibm-linux
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 Richard Biener changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Richard Biener --- Do you have a testcase?
[Bug target/58424] [ARM]gcc.target/arm/pr42575.c failed on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58424 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-11 CC||ramana at gcc dot gnu.org Known to work||4.9.0 Ever confirmed|0 |1 Known to fail||4.8.0, 4.8.1 --- Comment #1 from Ramana Radhakrishnan --- Appears to be fixed on trunk with and without LRA with -O2 -mthumb / -marm -mcpu=cortex-m4 / -march=armv7-a longfunc: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mul r3, r0, r3 mla r3, r2, r1, r3 umull r0, r1, r0, r2 add r1, r1, r3 bx lr This is with a build from around 20140307 . while 4.8 still appears to have this problem. Bin : can you please check ?
[Bug tree-optimization/60502] New: 4.9 ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502
Bug ID: 60502
Summary: 4.9 ICE reassociation and vector types.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: graham.stott at btinternet dot com
gcc_unreacble abort in reassociation and vector types
If reassocation manages to simplify an expression which involves any VECTOR
type
it will trigger a gcc_unreachable abort.
On any target which has support for vector types.
typedef signed char v16i8 __attribute__ ((vector_size(16)));
v16i8 bug1(v16i8 op0)
{
v16i8 m1 = {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1};
return (op0 ^ m1) | (op0 & m1);
}
It hits a gcc_unreachable() in build_int_cst_wide.
bug.c:3:7: internal compiler error: in build_int_cst_wide, at tree.c:1200
v16i8 bug1(v16i8 op0)
^
0xb75583 build_int_cst_wide(tree_node*, unsigned long, long)
/gcc/gcc/gcc/tree.c:1200
0xaade63 eliminate_not_pairs
/gcc/gcc/gcc/tree-ssa-reassoc.c:810
0xaade63 optimize_ops_list
/gcc/gcc/gcc/tree-ssa-reassoc.c:1744
0xab0a99 reassociate_bb
/gcc/gcc/gcc/tree-ssa-reassoc.c:4436
0xab08a7 reassociate_bb
/gcc/gcc/gcc/tree-ssa-reassoc.c:4519
0xab311b do_reassoc
/gcc/gcc/gcc/tree-ssa-reassoc.c:4552
0xab311b execute_reassoc
/gcc/gcc/gcc/tree-ssa-reassoc.c:4634
0xab311b execute
/gcc/gcc/gcc/tree-ssa-reassoc.c:4676
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #1 from zosrothko at orange dot fr --- This issue applies also to other C functions like strdup, realpath, strerror_r, strsep, etc..
[Bug tree-optimization/60502] [4.8/4.9 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-11 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|4.9 ICE reassociation and |[4.8/4.9 Regression] ICE |vector types. |reassociation and vector ||types. Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r184923.
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- stdio.h is provided by cygwin, not GCC, so IMHO you should report it there instead.
[Bug tree-optimization/60502] [4.8/4.9 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 --- Comment #2 from Marc Glisse --- Indeed. Probably should call build_all_ones_cst instead of build_low_bits_mask in eliminate_not_pairs.
[Bug tree-optimization/60502] [4.8/4.9 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502
--- Comment #3 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #2)
> Indeed. Probably should call build_all_ones_cst instead of
> build_low_bits_mask in eliminate_not_pairs.
Agreed. Are you going to prepare a patch, or should I? Guess we don't want to
use v16i8 in fn return type or argument, it needs to be
typedef signed char v16i8 __attribute__ ((vector_size (16)));
typedef unsigned char v16u8 __attribute__ ((vector_size (16)));
void
foo (v16i8 *x)
{
v16i8 op0 = *x;
v16i8 m1 = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
};
*x = (op0 ^ m1) | (op0 & m1);
}
void
bar (v16u8 *x)
{
v16u8 op0 = *x;
v16u8 m1 = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
};
*x = (op0 ^ m1) | (op0 & m1);
}
instead.
[Bug libstdc++/60499] [4.9 Regression] non-reserved name in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60499 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Tue Mar 11 17:16:41 2014 New Revision: 208490 URL: http://gcc.gnu.org/viewcvs?rev=208490&root=gcc&view=rev Log: PR libstdc++/60499 * include/debug/forward_list (forward_list::operator=(forward_list&&)): Uglify name. * include/debug/map (map::operator=(map&&)): Likewise. * include/debug/multimap (multimap::operator=(multimap&&)): Likewise. * include/debug/multiset (multiset::operator=(multiset&&)): Likewise. * include/debug/set (set::operator=(set&&)): Likewise. * include/debug/unordered_map (unordered_map::operator=(unordered_map&&)): Likewise. (unordered_multimap::operator=(unordered_multimap&&)): Likewise. * include/debug/unordered_set (unordered_set::operator=(unordered_set&&)): Likewise. (unordered_multiset::operator=(unordered_multiset&&)): Likewise. * include/debug/vector (vector::operator=(vector&&)): Likewise. * testsuite/23_containers/forward_list/debug/60499.cc: New * testsuite/23_containers/map/debug/60499.cc: New * testsuite/23_containers/multimap/debug/60499.cc: New * testsuite/23_containers/multiset/debug/60499.cc: New * testsuite/23_containers/set/debug/60499.cc: New * testsuite/23_containers/unordered_map/debug/60499.cc: New * testsuite/23_containers/unordered_multimap/debug/60499.cc: New * testsuite/23_containers/unordered_multiset/debug/60499.cc: New * testsuite/23_containers/unordered_set/debug/60499.cc: New * testsuite/23_containers/vector/debug/60499.cc: New Added: trunk/libstdc++-v3/testsuite/23_containers/forward_list/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/map/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/set/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/debug/60499.cc trunk/libstdc++-v3/testsuite/23_containers/vector/debug/60499.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/forward_list trunk/libstdc++-v3/include/debug/map.h trunk/libstdc++-v3/include/debug/multimap.h trunk/libstdc++-v3/include/debug/multiset.h trunk/libstdc++-v3/include/debug/set.h trunk/libstdc++-v3/include/debug/unordered_map trunk/libstdc++-v3/include/debug/unordered_set trunk/libstdc++-v3/include/debug/vector
[Bug libstdc++/60499] [4.9 Regression] non-reserved name in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60499 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- fixed
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #3 from zosrothko at orange dot fr --- (In reply to Jakub Jelinek from comment #2) > stdio.h is provided by cygwin, not GCC, so IMHO you should report it there > instead. on the cygwin mailling list, cygwin states that it is a bug in gcc... see this thread: http://cygwin.com/ml/cygwin/2012-04/msg00140.html Thus I am a little bit puzzled...
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #4 from zosrothko at orange dot fr --- (In reply to Jakub Jelinek from comment #2) > stdio.h is provided by cygwin, not GCC, so IMHO you should report it there > instead. and by the way, it compiles fine when using -std=gnu++11
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #5 from zosrothko at orange dot fr --- This is a snipet from usr/include/stdio.h #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) #ifndef _REENT_ONLY int _EXFUN(asiprintf, (char **, const char *, ...) _ATTRIBUTE ((__format__ (__printf__, 2, 3; char * _EXFUN(asniprintf, (char *, size_t *, const char *, ...) _ATTRIBUTE ((__format__ (__printf__, 3, 4; char * _EXFUN(asnprintf, (char *__restrict, size_t *__restrict, const char *__restrict, ...) _ATTRIBUTE ((__format__ (__printf__, 3, 4; int _EXFUN(asprintf, (char **__restrict, const char *__restrict, ...) _ATTRIBUTE ((__format__ (__printf__, 2, 3; #ifndef diprintf int _EXFUN(diprintf, (int, const char *, ...) _ATTRIBUTE ((__format__ (__printf__, 2, 3; #endif int _EXFUN(fcloseall, (_VOID)); int _EXFUN(fiprintf, (FILE *, const char *, ...) _ATTRIBUTE ((__format__ (__printf__, 2, 3; int _EXFUN(fiscanf, (FILE *, const char *, ...) _ATTRIBUTE ((__format__ (__scanf__, 2, 3; int _EXFUN(iprintf, (const char *, ...) _ATTRIBUTE ((__format__ (__printf__, 1, 2; int _EXFUN(iscanf, (const char *, ...) _ATTRIBUTE ((__format__ (__scanf__, 1, 2; int _EXFUN(siprintf, (char *, const char *, ...) _ATTRIBUTE ((__format__ (__printf__, 2, 3; int _EXFUN(siscanf, (const char *, const char *, ...) _ATTRIBUTE ((__format__ (__scanf__, 2, 3; int _EXFUN(snprintf, (char *__restrict, size_t, const char *__restrict, ...) _ATTRIBUTE ((__format__ (__printf__, 3, 4;
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 --- Comment #2 from Andreas Krebbel --- Bootstrap with -mzarch -m31 -march=zEC12 as defaults passed. 108 testsuite fails got fixed.
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jakub Jelinek --- As C++ isn't C, obviously it g++ -std=c++11 doesn't define __STDC_VERSION__ macro, but just defines __STRICT_ANSI__ 1 __cplusplus 201103L Should be more than enough for cygwin headers to do the right thing.
[Bug tree-optimization/60502] [4.8/4.9 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #4 from Marc Glisse --- (In reply to Jakub Jelinek from comment #3) > Are you going to prepare a patch, or should I? Please go ahead (or I'll do it in a few days). Note that the &m1 part is not necessary to reproduce: *x |= (*x ^ m1);
[Bug c++/60389] [4.8/4.9 Regression] [c++11] ICE with inheriting constructors and wrong usage of constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60389 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Mar 11 17:34:32 2014 New Revision: 208491 URL: http://gcc.gnu.org/viewcvs?rev=208491&root=gcc&view=rev Log: /cp 2014-03-11 Paolo Carlini PR c++/60389 * method.c (get_inherited_ctor): New. * cp-tree.h (get_inherited_ctor): Declare it. * semantics.c (is_valid_constexpr_fn): Use it. /testsuite 2014-03-11 Paolo Carlini PR c++/60389 * g++.dg/cpp0x/inh-ctor19.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/method.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60389] [4.8/4.9 Regression] [c++11] ICE with inheriting constructors and wrong usage of constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60389 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|4.8.3 |4.9.0 --- Comment #3 from Paolo Carlini --- Fixed for 4.9.0.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #25 from Jakub Jelinek --- Created attachment 32334 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32334&action=edit gcc49-pr60418.patch Unfortunately the patch fails to bootstrap due to -fcompare-debug failures, so tried this instead, but it also fails due to -fcompare-debug failures.
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #7 from zosrothko at orange dot fr --- (In reply to Jakub Jelinek from comment #6) > As C++ isn't C, obviously it g++ -std=c++11 doesn't define __STDC_VERSION__ > macro, but just defines > __STRICT_ANSI__ 1 > __cplusplus 201103L > Should be more than enough for cygwin headers to do the right thing. Ok but gnu++1 doesn't define __STDC_VERSION__ neither but it compiles fine...so?? $ g++ -xc++ -std=gnu++11 -dM -E - < /dev/null | sort | grep STDC #define __GNUC_STDC_INLINE__ 1 #define __STDC_HOSTED__ 1 #define __STDC__ 1 $ g++ -xc++ -std=c++11 -dM -E - < /dev/null | sort | grep STDC #define __GNUC_STDC_INLINE__ 1 #define __STDC_HOSTED__ 1 #define __STDC__ 1
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #8 from Jakub Jelinek --- Sure, but with -std=gnu++11 __STRICT_ANSI__ isn't defined (as intended).
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #9 from Jonathan Wakely --- Definitely a Cygwin bug, their header should test: #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) || (__cplusplus >= 201103L) That way the functions will be defined for any -std=gnuNN mode, for C99, and for C++11, which would be correct.
[Bug c++/60498] error: 'snprintf' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498 --- Comment #10 from Jakub Jelinek --- Note, you've listed also plenty of non-standard functions like asiprintf, I guess those certainly shouldn't be available for __STRICT_ANSI__, even for -std=c99, -std=c11 or -std=c++11.
[Bug libstdc++/59738] [4.9 Regression] r206444 caused FAIL: 23_containers/vector/52591.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59738 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue Mar 11 19:23:04 2014 New Revision: 208494 URL: http://gcc.gnu.org/viewcvs?rev=208494&root=gcc&view=rev Log: Backport from mainline. 2014-01-09 Jonathan Wakely PR libstdc++/59738 * include/bits/stl_vector.h (vector<>::_M_move_assign): Restore support for non-Movable types. 2014-01-08 François Dumont * include/bits/stl_vector.h (std::vector<>::_M_move_assign): Pass *this allocator instance when building temporary vector instance so that *this allocator does not get moved. * testsuite/23_containers/vector/allocator/move.cc (test01): Add check on a vector iterator. * testsuite/23_containers/vector/allocator/move_assign.cc (test02): Likewise. (test03): New, test with a non-propagating allocator. 2013-11-15 Jonathan Wakely * testsuite/23_containers/vector/allocator/move.cc: New Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/23_containers/vector/allocator/move.cc - copied, changed from r208492, branches/gcc-4_8-branch/libstdc++-v3/testsuite/23_containers/vector/allocator/move_assign.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_vector.h branches/gcc-4_8-branch/libstdc++-v3/testsuite/23_containers/vector/allocator/move_assign.cc
[Bug libstdc++/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 --- Comment #23 from Jonathan Wakely --- Author: redi Date: Tue Mar 11 19:41:07 2014 New Revision: 208495 URL: http://gcc.gnu.org/viewcvs?rev=208495&root=gcc&view=rev Log: 2014-03-11 Jonathan Wakely Backport from mainline. 2014-01-27 Jonathan Wakely PR libstdc++/59215 * include/bits/shared_ptr_base.h (_Sp_counted_base<_S_atomic>::_M_add_ref_lock()): Use relaxed atomic load. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/shared_ptr_base.h
[Bug libstdc++/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Jonathan Wakely --- Fixed for 4.8.3 now
[Bug c++/60503] New: gcc looks for C++ attributes in the wrong place in a lambda-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503
Bug ID: 60503
Summary: gcc looks for C++ attributes in the wrong place in a
lambda-expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
GCC accepts this ill-formed code:
void f() { []() [[ ]] mutable noexcept {}; }
... and rejects this valid code:
void f() { []() mutable noexcept [[ ]] {}; }
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #26 from H.J. Lu --- This patch avoids removing preheader when optimizing since preheader will be added back later even if it is removed: diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c index 926d300..af5b24b 100644 --- a/gcc/tree-cfgcleanup.c +++ b/gcc/tree-cfgcleanup.c @@ -328,7 +328,10 @@ tree_forwarder_block_p (basic_block bb, bool phi_wanted) (LOOPS_MAY_HAVE_MULTIPLE_LATCHES)); } else if (bb->loop_father == loop_outer (dest->loop_father)) - return !loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS); + /* Preserve preheader when optimizing since it will be added + back later. */ + return !(optimize + || loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)); /* Always preserve other edges into loop headers that are not simple latches or preheaders. */ return false;
[Bug libstdc++/59680] Compile error in thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59680 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Mar 11 21:06:21 2014 New Revision: 208497 URL: http://gcc.gnu.org/viewcvs?rev=208497&root=gcc&view=rev Log: 2014-03-11 Jonathan Wakely Backport from mainline. 2014-01-09 Jonathan Wakely PR libstdc++/59680 * src/c++11/thread.cc (__sleep_for): Fix call to ::sleep. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/src/c++11/thread.cc
[Bug libstdc++/59680] Compile error in thread.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59680 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #5 from Jonathan Wakely --- Fixed for 4.8.3
[Bug c++/60367] Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 Volker Reichelt changed: What|Removed |Added CC||reichelt at gcc dot gnu.org --- Comment #9 from Volker Reichelt --- *** Bug 58501 has been marked as a duplicate of this bug. ***
[Bug c++/58501] [c++11] Crash with brace-enclosed initializer as default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58501 Volker Reichelt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Volker Reichelt --- Fixed by Jason's patch for PR60367. The testcase added there seems to cover the testcase here, so no further action is required. Marking as duplicate then. *** This bug has been marked as a duplicate of bug 60367 ***
[Bug ada/60504] New: [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 Bug ID: 60504 Summary: [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com With gcc-4.9-20140309 I see the following testsuite regressions on armv5tel-linux-gnueabi compared to the previous working snapshot gcc-4.9-20140223 (the intermediate 4.9-20130302 didn't bootstrap due to PR60411): === acats tests === +FAIL: a87b59a +FAIL: c32111a +FAIL: c32111b +FAIL: c32112b +FAIL: c32113a +FAIL: c32115a +FAIL: c32115b (hundreds more here) +FAIL: cxg2020 +FAIL: cz1102a +FAIL: cz1103a === acats Summary === -# of expected passes 2320 -# of unexpected failures 0 +# of expected passes 1625 +# of unexpected failures 695 and === gnat tests === Running target unix +FAIL: gnat.dg/aliased_prefix_accessibility.adb execution test +FAIL: gnat.dg/conv_bug.adb execution test +FAIL: gnat.dg/curr_task.adb execution test +FAIL: gnat.dg/expect1.adb execution test +FAIL: gnat.dg/handle_and_return.adb execution test +FAIL: gnat.dg/invalid1.adb execution test +FAIL: gnat.dg/iprot_test.adb execution test +FAIL: gnat.dg/missing_acc_check.adb execution test +FAIL: gnat.dg/nested_controlled_alloc.adb execution test +FAIL: gnat.dg/not_null.adb execution test +FAIL: gnat.dg/null_pointer_deref1.adb execution test +FAIL: gnat.dg/null_pointer_deref2.adb execution test +FAIL: gnat.dg/null_pointer_deref3.adb execution test +FAIL: gnat.dg/opt22.adb execution test +FAIL: gnat.dg/overflow_sum.adb execution test +FAIL: gnat.dg/regpat1.adb execution test +FAIL: gnat.dg/stack_check1.adb execution test +FAIL: gnat.dg/stack_check2.adb execution test +FAIL: gnat.dg/tag1.adb execution test +FAIL: gnat.dg/test_enum_io.adb execution test +FAIL: gnat.dg/test_fixed_io.adb execution test +FAIL: gnat.dg/test_image.adb execution test +XPASS: gnat.dg/test_raise_from_pure.adb execution test +FAIL: gnat.dg/timer_cancel.adb execution test === gnat Summary === -# of expected passes 1200 -# of expected failures 19 +# of expected passes 1177 +# of unexpected failures 23 +# of unexpected successes 1 +# of expected failures 18 # of unsupported tests 13 The first one was splitting /mnt/scratch/objdir49/gcc/testsuite/ada/acats/tests/a/a87b59a.ada into: a87b59a.adb BUILD a87b59a.adb gnatmake --GCC="/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc/" -gnatws -O2 -gnat95 -I/mnt/scratch/objdir49/gcc/testsuite/ada/acats/support a87b59a.adb -largs --GCC="/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc/" /mnt/scratch/objdir49/gcc/xgcc -c -B/mnt/scratch/objdir49/gcc/ -gnatws -O2 -gnat95 -I/mnt/scratch/objdir49/gcc/testsuite/ada/acats/support a87b59a.adb gnatbind -I/mnt/scratch/objdir49/gcc/testsuite/ada/acats/support -x a87b59a.ali gnatlink a87b59a.ali -O2 --GCC=/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc/ RUN a87b59a ,.,. A87B59A ACATS 2.5 14-03-10 20:37:01 A87B59A CHECK THAT BECAUSE A GENERIC ACTUAL PROGRAM PARAMETER MUST BE A SUBPROGRAM, AN ENUMERATION LITERAL, OR AN ENTRY WITH THE SAME PARAMETER AND RESULT TYPE PROFILE AS THE FORMAL PARAMETER, AN OVERLOADED NAME APPEARING AS AN ACTUAL PARAMETER CAN BE RESOLVED. Execution terminated by abort of environment task FAIL: a87b59a The last one was Executing on host: /mnt/scratch/objdir49/gcc/gnatmake --GCC=/mnt/scratch/objdir49/gcc/xgcc --GNATBIND=/mnt/scratch/objdir49/gcc/gnatbind --GNATLINK=/mnt/scratch/objdir49/gcc/gnatlink -cargs -B/mnt/scratch/objdir49/gcc -largs --GCC=/mnt/scratch/objdir49/gcc/xgcc\ -B/mnt/scratch/objdir49/gcc\ -margs --RTS=/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/./libada -q -f /mnt/scratch/gcc-4.9-20140309/gcc/testsuite/gnat.dg/timer_cancel.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -lm -o ./timer_cancel.exe(timeout = 300) spawn -ignore SIGHUP /mnt/scratch/objdir49/gcc/gnatmake --GCC=/mnt/scratch/objdir49/gcc/xgcc --GNATBIND=/mnt/scratch/objdir49/gcc/gnatbind --GNATLINK=/mnt/scratch/objdir49/gcc/gnatlink -cargs -B/mnt/scratch/objdir49/gcc -largs --GCC=/mnt/scratch/objdir49/gcc/xgcc -B/mnt/scratch/objdir49/gcc -margs --RTS=/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/./libada -q -f /mnt/scratch/gcc-4.9-20140309/gcc/testsuite/gnat.dg/timer_cancel.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -lm -o ./timer_cancel.exe Executing on host: /mnt/scratch/objdir49/gcc/gnatclean -c -q -n ./timer_cancel (timeout = 300) spawn -ignore SIGHUP /mnt/scratch/objdir49/gcc/gnatclean -c -q -n ./timer_
[Bug tree-optimization/60505] New: Warning caused by GCC vectorizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60505
Bug ID: 60505
Summary: Warning caused by GCC vectorizer.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: congh at google dot com
The compilation on the code below fails with options "-Wall -Werror -O2
-ftree-loop-vectorize". The reason is that the epilogue generated by the
vectorizer tries to access the memory outside of ovec[16] and the the vrp pass
emits the warning "array subscript is above array bounds" for the access to
ovec[i]. The vectorizer should not generate the epilogue for this loop.
void foo(char *in, char *out, int num)
{
int i;
unsigned char ovec[16] = {0};
for(i=0; i < num ; ++i)
out[i] = (ovec[i] = in[i]);
out[num] = ovec[num/2];
}
[Bug tree-optimization/60505] Warning caused by GCC vectorizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60505 --- Comment #1 from Cong Hou --- Google ref: b/13403465
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-11 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > I kind of suspect the ARM unwinder changes, but I haven't had time to verify > that. Most likely indeed, I'll investigate a bit tomorrow.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #40 from Jerry DeLisle --- Created attachment 32335 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32335&action=edit Updated patch taking care of NIST failures and cleaned up This patch regression tests and passes NIST on x86-64. I have restructured it and took care of leaping on uninitialized values. Dominiq. Can you give it a spin? Thanks
[Bug c++/60506] g++ reports "internal compiler error" using SSE2 and not entirely beautiful programming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60506 --- Comment #1 from jenkinsj89 at yahoo dot ca --- Created attachment 32337 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32337&action=edit the program that gives g++ fits
[Bug c++/60506] g++ reports "internal compiler error" using SSE2 and not entirely beautiful programming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60506 Andrew Pinski changed: What|Removed |Added Severity|blocker |normal
[Bug c++/60506] g++ reports "internal compiler error" using SSE2 and not entirely beautiful programming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60506
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
typedef unsigned QuadV4 __attribute__((vector_size(16)));
void updateCount() {
QuadV4 QZ;
QuadV4 v;
v == QZ && v == QZ;
}
[Bug c++/60506] ICE with && on vectors in C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60506 Andrew Pinski changed: What|Removed |Added Target|i86_64-pc-cygwin| |-march=corei7 | Summary|g++ reports "internal |ICE with && on vectors in |compiler error" using SSE2 |C++ |and not entirely beautiful | |programming | Alias|kc_sse2_shuffle | --- Comment #3 from Andrew Pinski --- ICEs as of 4.9 20140219 too. C front-end errors out: t.c: In function ‘updateCount’: t.c:5:5: error: used vector type where scalar is required
[Bug c++/60506] ICE with && on vectors in C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60506 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Turns out this is dup of bug 58845. In 4.9 we print a sorry message meaning we don't handle this just yet. *** This bug has been marked as a duplicate of bug 58845 ***
[Bug c++/58845] Operator || and && broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845 Andrew Pinski changed: What|Removed |Added CC||jenkinsj89 at yahoo dot ca --- Comment #20 from Andrew Pinski --- *** Bug 60506 has been marked as a duplicate of this bug. ***
