[Bug tree-optimization/70623] [4.9/5/6 Regression] ICE in compute_antic at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70623 --- Comment #7 from Richard Biener --- Author: rguenth Date: Thu Apr 14 07:30:53 2016 New Revision: 234970 URL: https://gcc.gnu.org/viewcvs?rev=234970&root=gcc&view=rev Log: 2016-04-14 Richard Biener PR tree-optimization/70623 * tree-ssa-pre.c (changed_blocks): Make global ... (compute_antic): ... local here. Move and fix worklist handling here. Do not clear EDGE_DFS_BACK or call mark_dfs_back_edges. (compute_antic_aux): Add dumping for MAX assumed succs. Remove worklist handling, dump when ANTIC_IN changed. (compute_partial_antic_aux): Remove worklist handling. (init_pre): Do not compute post dominators. Add a comment about the CFG order chosen. (fini_pre): Do not free post dominators. * gcc.dg/torture/pr70623.c: New testcase. * gcc.dg/torture/pr70623-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr70623-2.c trunk/gcc/testsuite/gcc.dg/torture/pr70623.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/70623] [4.9/5 Regression] ICE in compute_antic at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70623 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work|4.9.3, 5.3.0|6.0 Summary|[4.9/5/6 Regression] ICE in |[4.9/5 Regression] ICE in |compute_antic at -O2|compute_antic at -O2 Known to fail|6.0 |4.9.3, 5.3.0 --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/70655] New: selectio sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70655 Bug ID: 70655 Summary: selectio sort Product: gcc Version: 3.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mubashirkaleem2 at gmail dot com Target Milestone: --- Created attachment 38261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38261&action=edit mutation testing
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130
--- Comment #23 from Richard Biener ---
But that's ok - we are storing the same scalar element:
t.i:12:3: note: Load permutation 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
t.i:12:3: note: no array mode for V8HI[16]
t.i:12:3: note: Final SLP tree for instance:
t.i:12:3: note: node
t.i:12:3: note: stmt 0 pretmp_32->mprr_2[1][j_57][0] = _40;
t.i:12:3: note: stmt 1 pretmp_32->mprr_2[1][j_57][1] = _40;
t.i:12:3: note: stmt 2 pretmp_32->mprr_2[1][j_57][2] = _40;
t.i:12:3: note: stmt 3 pretmp_32->mprr_2[1][j_57][3] = _40;
t.i:12:3: note: stmt 4 pretmp_32->mprr_2[1][j_57][4] = _40;
t.i:12:3: note: stmt 5 pretmp_32->mprr_2[1][j_57][5] = _40;
t.i:12:3: note: stmt 6 pretmp_32->mprr_2[1][j_57][6] = _40;
t.i:12:3: note: stmt 7 pretmp_32->mprr_2[1][j_57][7] = _40;
t.i:12:3: note: stmt 8 pretmp_32->mprr_2[1][j_57][8] = _40;
t.i:12:3: note: stmt 9 pretmp_32->mprr_2[1][j_57][9] = _40;
t.i:12:3: note: stmt 10 pretmp_32->mprr_2[1][j_57][10] = _40;
t.i:12:3: note: stmt 11 pretmp_32->mprr_2[1][j_57][11] = _40;
t.i:12:3: note: stmt 12 pretmp_32->mprr_2[1][j_57][12] = _40;
t.i:12:3: note: stmt 13 pretmp_32->mprr_2[1][j_57][13] = _40;
t.i:12:3: note: stmt 14 pretmp_32->mprr_2[1][j_57][14] = _40;
t.i:12:3: note: stmt 15 pretmp_32->mprr_2[1][j_57][15] = _40;
t.i:12:3: note: node
t.i:12:3: note: stmt 0 _40 = (short int) _39;
t.i:12:3: note: stmt 1 _40 = (short int) _39;
t.i:12:3: note: stmt 2 _40 = (short int) _39;
t.i:12:3: note: stmt 3 _40 = (short int) _39;
t.i:12:3: note: stmt 4 _40 = (short int) _39;
t.i:12:3: note: stmt 5 _40 = (short int) _39;
t.i:12:3: note: stmt 6 _40 = (short int) _39;
t.i:12:3: note: stmt 7 _40 = (short int) _39;
t.i:12:3: note: stmt 8 _40 = (short int) _39;
t.i:12:3: note: stmt 9 _40 = (short int) _39;
t.i:12:3: note: stmt 10 _40 = (short int) _39;
t.i:12:3: note: stmt 11 _40 = (short int) _39;
t.i:12:3: note: stmt 12 _40 = (short int) _39;
t.i:12:3: note: stmt 13 _40 = (short int) _39;
t.i:12:3: note: stmt 14 _40 = (short int) _39;
t.i:12:3: note: stmt 15 _40 = (short int) _39;
t.i:12:3: note: node
t.i:12:3: note: stmt 0 _39 = *_38[1];
t.i:12:3: note: stmt 1 _39 = *_38[1];
t.i:12:3: note: stmt 2 _39 = *_38[1];
t.i:12:3: note: stmt 3 _39 = *_38[1];
t.i:12:3: note: stmt 4 _39 = *_38[1];
t.i:12:3: note: stmt 5 _39 = *_38[1];
t.i:12:3: note: stmt 6 _39 = *_38[1];
t.i:12:3: note: stmt 7 _39 = *_38[1];
t.i:12:3: note: stmt 8 _39 = *_38[1];
t.i:12:3: note: stmt 9 _39 = *_38[1];
t.i:12:3: note: stmt 10 _39 = *_38[1];
t.i:12:3: note: stmt 11 _39 = *_38[1];
t.i:12:3: note: stmt 12 _39 = *_38[1];
t.i:12:3: note: stmt 13 _39 = *_38[1];
t.i:12:3: note: stmt 14 _39 = *_38[1];
t.i:12:3: note: stmt 15 _39 = *_38[1];
and
Creating dr for *_38[1]
analyze_innermost: success.
base_address: s_9(D)
offset from base address: 0
constant offset from base address: 4
step: 8
aligned to: 128
base_object: *s_9(D)
Access function 0: 1
Access function 1: {0B, +, 8}_1
this is an 'int' load accessing *_38[1] in the first and *_38[3] in the
second iteration. So we load a v4si from *_38[1], and then advance
by half of a vector. With my patch we still have the
__builtin_altivec_mask_for_load computed once, but that's bougs as the
alignment of the accesses changes each iteration.
Before the cited rev. we probably used interleaving and not SLP to vectorize
this loop. I think that for this special permutation using a scalar load
and splatting that would have been best, cost-wise.
Now we still first need to tell GCC that when using SLP the re-align
scheme doesn't work in this case.
The following seems to work and ends up generating unaligned loads (even with
-mcpu=power7):
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 234970)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -5983,10 +5983,19 @@ vect_supportable_dr_alignment (struct da
|| targetm.vectorize.builtin_mask_for_load ()))
{
tree vectype = STMT_VINFO_VECTYPE (stmt_info);
- if ((nested_in_vect_loop
- && (TREE_INT_CST_LOW (DR_STEP (dr))
- != GET_MODE_SIZE (TYPE_MODE (vectype
- || !loop_vinfo)
+
+ /* If we are doing SLP then the accesses need not have the
+same alignment, instead it depends on the SLP group size. */
+ if (loop_vinfo
+ && STMT_SLP_TYPE (stmt_info)
+ && (LOOP_VINFO_VECT_FACTOR (loop_vinfo)
+ * GROUP_SIZE (vinfo_for_stmt (GROUP_FIRST
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- libgcj.so is not linked with libstdc++ (I think intentionally), and contains a bunch of VLAs in there: ../../../libjava/jni.cc:542:17: warning: ISO C++ forbids variable length array ‘s’ [-Wvla] ../../../libjava/jni.cc:730:12: warning: ISO C++ forbids variable length array [-Wvla] ../../../libjava/jni.cc:835:14: warning: ISO C++ forbids variable length array [-Wvla] ../../../libjava/jni.cc:897:14: warning: ISO C++ forbids variable length array [-Wvla] ../../../libjava/jni.cc:940:14: warning: ISO C++ forbids variable length array [-Wvla] ../../../libjava/jni.cc:987:14: warning: ISO C++ forbids variable length array [-Wvla] ../../../libjava/jni.cc:1229:12: warning: ISO C++ forbids variable length array [-Wvla] ../../../libjava/jni.cc:2210:52: warning: ISO C++ forbids variable length array ‘buf’ [-Wvla] ../../../libjava/jni.cc:2341:72: warning: ISO C++ forbids variable length array ‘real_args’ [-Wvla] ../../../libjava/interpret-run.cc:36:33: warning: ISO C++ forbids variable length array ‘stack’ [-Wvla] ../../../libjava/interpret-run.cc:39:35: warning: ISO C++ forbids variable length array ‘locals’ [-Wvla] ../../../libjava/interpret-run.cc:45:36: warning: ISO C++ forbids variable length array ‘locals_type’ [-Wvla] ../../../libjava/prims.cc:801:24: warning: ISO C++ forbids variable length array ‘sizes’ [-Wvla] ../../../libjava/prims.cc:1533:47: warning: ISO C++ forbids variable length array ‘lib_name’ [-Wvla] ../../../libjava/prims.cc:1578:43: warning: ISO C++ forbids variable length array ‘lib_name’ [-Wvla] ../../../libjava/prims.cc:1730:40: warning: ISO C++ forbids variable length array ‘vmArgs’ [-Wvla] ../../../libjava/verify.cc:898:37: warning: ISO C++ forbids variable length array ‘arrayName’ [-Wvla] ../../../libjava/verify.cc:917:37: warning: ISO C++ forbids variable length array ‘arrayName’ [-Wvla] ../../../libjava/verify.cc:2232:29: warning: ISO C++ forbids variable length array ‘arg_types’ [-Wvla] ../../../libjava/verify.cc:2968:32: warning: ISO C++ forbids variable length array ‘arg_types’ [-Wvla] at least. I wonder why is r234966 apparently more aggressive than what 4.9 had in, because I don't remember such issues in libgcj back then. So, either we need to get rid of the VLAs and replace them say by alloca, or have a way to disable this new stuff (which IMHO has been added way too late) through command line option, or need to link with libsupc++, or provide a stub for the symbol.
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/70655] selectio sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70655 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- not a bug
[Bug c++/70653] bubble sorting algorithm fail to run on the compiler giving a bug in it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70653 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- we're not a tool to find bugs in your code
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Richard Biener --- Please just revert this for GCC 6, I'm sure it didn't fix a regression.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/70646] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-04-14
CC||hubicka at gcc dot gnu.org,
||jamborm at gcc dot gnu.org
Component|c |ipa
Ever confirmed|0 |1
--- Comment #8 from Richard Biener ---
Confirmed.
;; Function broken (broken, funcdef_no=2, decl_uid=1764, cgraph_uid=2,
symbol_order=2) (executed once)
__attribute__((noclone, noinline))
broken (u64 * shost)
{
:
__builtin_unreachable ();
}
after inlining we see:
:
node_name[0] = 255;
node_name[1] = 255;
node_name[2] = 255;
node_name[3] = 255;
node_name[4] = 255;
node_name[5] = 255;
node_name[6] = 255;
node_name[7] = 255;
_14 = MEM[(const u64 *)&node_name];
_15 = __builtin_constant_p (_14);
if (_15 != 0)
goto ;
else
goto ;
...
:
iftmp.0_37 = _39(D);
__builtin_unreachable ();
which seems to be introduced by IPA CP:
__builtin_unreachable/9 (__builtin_unreachable) @0x7f1563274cf0
Type: function
Visibility: external public
References:
Referring:
Availability: not_available
First run: 0
Function flags:
Called by: wwn_to_u64.constprop.0/8
Calls:
wwn_to_u64.constprop.0/8 (wwn_to_u64.constprop) @0x7f1563274000
Type: function definition analyzed
Visibility:
References:
Referring:
Function wwn_to_u64.constprop/8 is inline copy in broken/2
Clone of wwn_to_u64/1
Availability: local
First run: 0
Function flags: local
Called by: broken/2 (inlined) (1.00 per call)
Calls: __builtin_constant_p/5 (1.00 per call) __builtin_unreachable/9
[Bug ipa/70646] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #9 from Richard Biener --- Note that the testcase is strictly invalid as it has 8-byte aligned node_name[] passed to wwn_to_u64 which ends up performing a 64bit load on it via __swab64p.
[Bug ipa/70646] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
--- Comment #10 from Richard Biener ---
Fixing that with
void __attribute__((noinline,noclone)) broken(u64* shost)
{
u8 node_name[8] __attribute__((aligned(__alignof(u64 = { 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
*shost = wwn_to_u64(node_name);
}
still shows broken code. Note __swab64p is a quite stupid implementation
assuming GCC can't constant-fold __builtin_bswap64.
[Bug ada/70645] [4.9/5/6 Regression] -fguess-branch-probability breaks debug-information, only in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70645 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug c++/70656] New: mutation testing of algorithum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70656 Bug ID: 70656 Summary: mutation testing of algorithum Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aqibsarfraz3749 at gmail dot com Target Milestone: --- Created attachment 38262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38262&action=edit bubble sort testing
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #6 from Jakub Jelinek ---
Shorter testcase:
struct A {};
void
foo (struct A a, int b)
{
}
compiles with sparc-solaris C, but doesn't with C++.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #7 from Jakub Jelinek --- Seems sparc-solaris passes even for C the empty struct as a separate argument (the empty struct goes into %o0, the int argument into %o1).
[Bug c++/70656] mutation testing of algorithum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70656 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from ktkachov at gcc dot gnu.org --- Not a bug.
[Bug ipa/70646] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #11 from Richard Biener --- Happens via (gdb) bt #0 redirect_to_unreachable (e=0x76891820) at /space/rguenther/src/svn/trunk3/gcc/ipa-inline-analysis.c:735 #1 0x00bc9325 in edge_set_predicate (e=0x76891820, predicate=0x7fffc980) at /space/rguenther/src/svn/trunk3/gcc/ipa-inline-analysis.c:768 #2 0x00bd1df7 in remap_edge_summaries (inlined_edge=0x768912d8, node=, info=0x76994ba0, callee_info=0x76994c60, operand_map=..., offset_map=..., possible_truths=0, toplev_predicate=0x7fffca30) at /space/rguenther/src/svn/trunk3/gcc/ipa-inline-analysis.c:3500 #3 0x00bd2603 in inline_merge_summary (edge=0x768912d8) at /space/rguenther/src/svn/trunk3/gcc/ipa-inline-analysis.c:3647 #4 0x017f2b84 in inline_call (e=0x768912d8, update_original=true, Python Exception There is no member or method named m_vecpfx.: new_edges=0x7fffd9d0, overall_size=0x25c63e0 <_ZL12overall_size>, update_overall_summary=true, callee_removed=0x0) at /space/rguenther/src/svn/trunk3/gcc/ipa-inline-transform.c:370 #5 0x017e8953 in inline_small_functions () at /space/rguenther/src/svn/trunk3/gcc/ipa-inline.c:2022 #6 0x017e9ca7 in ipa_inline () so somehow it get's confused: BB 2 predicate:(true) _3 = MEM[(const u64 *)wwn_2(D)]; freq:1.00 size: 1 time: 1 50% will be eliminated by inlining Accounting size:0.50, time:0.50 on new predicate:(op0[ref offset: 0] changed) && (not inlined) Accounting size:0.50, time:0.50 on new predicate:(op0[ref offset: 0] changed) _4 = __builtin_constant_p (_3); freq:1.00 size: 0 time: 0 if (_4 != 0) freq:1.00 size: 2 time: 2 Accounting size:2.00, time:2.00 on predicate:(op0[ref offset: 0] changed) BB 4 predicate:(op0[ref offset: 0] not constant) iftmp.0_26 = __builtin_bswap64 (_3); freq:0.61 size: 1 time: 1 BB 3 predicate:(true) _5 = _3 << 56; (BB 3 predicate shouldn't be true) Honza? This seems to be somewhat fragile (redirecting things to unreachable but _not_ changing the actual predicates in the IL). Claiming the predicate is constant true is also a bit bogus (as can be seen in following optimization).
[Bug c++/70540] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in cxx_incomplete_type_diagnostic, at cp/typeck2.c:569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70540 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #5 from Paolo Carlini --- Looking into it.
[Bug c++/70657] New: testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70657 Bug ID: 70657 Summary: testing Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: shumailiftikhar3749 at gmail dot com Target Milestone: --- Created attachment 38263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38263&action=edit mutation testing
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 Richard Biener changed: What|Removed |Added Known to work||4.8.5 Target Milestone|--- |4.9.4 Summary|Corrupt truncated function |[4.9/5/6 Regression] ||Corrupt truncated function Known to fail||4.9.3, 5.3.0, 6.0
[Bug c++/70657] testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70657 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jgreenhalgh at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from James Greenhalgh --- Please, stop this.
[Bug rtl-optimization/63629] ICE in fix_loop_structure, at loop-init.c:251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63629 Jan Smets changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jan Smets --- Seems fixed.
[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64971
--- Comment #11 from Ramana Radhakrishnan ---
(In reply to Jeffrey A. Law from comment #10)
> Ramana, do you want to give this to someone on your team to wrap up?
Kyrill, do you mind picking this up ?
(In reply to Jeffrey A. Law from comment #9)
> Seems rather hackish to start accepting non-Pmode for the address. Though
> looking at the docs, I guess it's not strictly incorrect.
>
> The @code{symbol_ref} contains a mode, which is usually @code{Pmode}.
> Usually that is the only mode for which a symbol is directly valid.
>
> And the *call* pattern documentation waffles a bit too:
>
> Operand 0 should be a @code{mem} RTX whose address is the address of the
> function. Note, however, that this address can be a @code{symbol_ref}
> expression even if it would not be a legitimate memory address on the
> target machine.
>
> So I won't object to the aarch64 maintainers accepting the additional mode
> (Richard's approach), nor will I object to forcing the mode in the expander
> (Andrew's approach)
Forcing the mode in the expander and guarding it with TARGET_ILP32 looks more
appealing to me right now purely because of where we are with the release cycle
though the points Richard makes need to be looked into. I'll let the aarch64
maintainers decide on which one to take.
[Bug target/66931] ICE in convert_move, at expr.c:316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66931 Jan Smets changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jan Smets --- Seems fixed
[Bug target/66920] ICE in expand_debug_locations, at cfgexpand.c:3826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66920 --- Comment #4 from Jan Smets --- Seems fixed.
[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805 Jan Smets changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Jan Smets --- Hopeless
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #37 from Jakub Jelinek --- So the remaining issue is that for one function emitted in the -fdump-final-insns= the cgraph uid is the same, but symbol_order= is different (on the testcase by 1). This is the function with the highest node->order in the file, so potentially it could affect more than that. So, if we really want to make sure that node->order is the same regardless of GC, we should either make sure the cgraph nodes for the constexpr function copies needed for constexpr processing aren't created at all, or ae always created freshly (e.g. by unregistering the cgraph nodes for them when we put them into the freelist), or perhaps just by making sure we always update the order. Let me find out where exactly is the cgraph node creation called from.
[Bug target/64971] [5/6 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64971 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #12 from ktkachov at gcc dot gnu.org --- My preference too at this stage is Andrew's patch. I'll retest it on current trunk and ping it on the list if all goes fine.
[Bug c++/70336] [5 regression] Incorrect Wconversion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70336 Jan Smets changed: What|Removed |Added Severity|normal |minor
[Bug tree-optimization/70614] [4.9/5/6 Regression] GCC gets stuck with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70614 --- Comment #5 from Richard Biener --- We already have --param scev-max-expr-complexity (and --param scev-max-expr-size) for this. But I have a simple fix for the testcase. Index: tree-scalar-evolution.c === --- tree-scalar-evolution.c (revision 234970) +++ tree-scalar-evolution.c (working copy) @@ -1687,6 +1690,8 @@ interpret_condition_phi (struct loop *lo (loop, PHI_ARG_DEF (condition_phi, i)); res = chrec_merge (res, branch_chrec); + if (res == chrec_dont_know) + break; } return res; Improves the testcase to compile in 0.5s.
[Bug libstdc++/70654] failbit is not set sometimes on stream reading double outside presentable range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70654
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-04-14
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
We check for overflow (by comparing to plus or minus HUGE_VAL) but not
underflow.
To check for underflow we need to save and restore errno to see if it is set to
ERANGE by the call to strto{f,d,ld}_l.
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Yeah, we should just reject the code. The ICE happens with cc1plus, too.
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651
--- Comment #3 from Marek Polacek ---
We have the code to reject this, but it happens only when gimplifying:
11695 if (have_va_type == NULL_TREE)
11696 {
11697 error_at (loc, "first argument to % not of type
%");
11698 return GS_ERROR;
11699 }
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #24 from Alan Modra --- Created attachment 38266 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38266&action=edit testcase for gcc.dg/vect/ Revised testcase checking multiple offsets, using an array of structs so not dependent on var layout.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #38 from Jakub Jelinek --- Surprisingly, the actual problem is with __builtin_unreachable. I've instrumented symbol_table::register_symbol, so that it logs this->order and node->name () after assigning node->order, and get: /tmp/orders1:3583 void __builtin_unreachable() /tmp/orders1:3718 void __builtin_unreachable() /tmp/orders1:4151 void __builtin_unreachable() /tmp/orders1:4448 void __builtin_unreachable() /tmp/orders2:3583 void __builtin_unreachable() /tmp/orders2:3718 void __builtin_unreachable() /tmp/orders2:4447 void __builtin_unreachable() the node->order = 4151 case is the one that happens just in one of the copies. The backtrace for that node->order = 4151 is: #0 0x00b305f2 in symbol_table::register_symbol (this=0x715a10a8, node=0x7fffee1cbb80) at ../../gcc/cgraph.h:2455 #1 0x00b2a530 in symtab_node::register_symbol (this=0x7fffee1cbb80) at ../../gcc/symtab.c:375 #2 0x00b358b5 in cgraph_node::create (decl=) at ../../gcc/cgraph.c:507 #3 0x00b359db in cgraph_node::get_create (decl=) at ../../gcc/cgraph.c:529 #4 0x00cfd123 in gimple_get_virt_method_for_vtable (token=2, v=, offset=256, can_refer=0x7fffa0de) at ../../gcc/gimple-fold.c:5758 #5 0x00cfd1c5 in gimple_get_virt_method_for_binfo (token=2, known_binfo=, can_refer=0x7fffa0de) at ../../gcc/gimple-fold.c:5789 #6 0x00db27a9 in possible_polymorphic_call_targets (otr_type=, otr_token=2, context=..., completep=0x7fffa2e7, cache_token=0x0, speculative=false) at ../../gcc/ipa-devirt.c:3164 #7 0x01247bb3 in eliminate_dom_walker::before_dom_children (this=0x7fffa5b0, b=) at ../../gcc/tree-ssa-pre.c:4311 #8 0x01944f05 in dom_walker::walk (this=0x7fffa5b0, bb=) at ../../gcc/domwalk.c:265 #9 0x012484a5 in eliminate (do_pre=false) at ../../gcc/tree-ssa-pre.c:4464 #10 0x012492cb in (anonymous namespace)::pass_fre::execute (this=0x27c9030, fun=0x7fffeea73930) at ../../gcc/tree-ssa-pre.c:4900 #11 0x00f3d84c in execute_one_pass (pass=) at ../../gcc/passes.c:2336 #12 0x00f3db82 in execute_pass_list_1 (pass=) at ../../gcc/passes.c:2420 #13 0x00f3dbb3 in execute_pass_list_1 (pass=) at ../../gcc/passes.c:2421 #14 0x00f3dc0b in execute_pass_list (fn=0x7fffeea73930, pass=) at ../../gcc/passes.c:2431 #15 0x00f3c19f in do_per_function_toporder (callback=0xf3dbce , data=0x27c8bf0) at ../../gcc/passes.c:1725 #16 0x00f3e7f0 in execute_ipa_pass_list (pass=) at ../../gcc/passes.c:2773 #17 0x00b4a7b9 in ipa_passes () at ../../gcc/cgraphunit.c:2265 #18 0x00b4ac2d in symbol_table::compile (this=0x715a10a8) at ../../gcc/cgraphunit.c:2404 #19 0x00b4afd4 in symbol_table::finalize_compilation_unit (this=0x715a10a8) at ../../gcc/cgraphunit.c:2564 #20 0x010513f1 in compile_file () at ../../gcc/toplev.c:490 #21 0x01053948 in do_compile () at ../../gcc/toplev.c:1988 #22 0x01053bcc in toplev::main (this=0x7fffddf0, argc=32, argv=0x7fffdef8) at ../../gcc/toplev.c:2096 #23 0x01a438a6 in main (argc=32, argv=0x7fffdef8) at ../../gcc/main.c:39 I'm really puzzled by multiple cgraph nodes being created for __builtin_unreachable, that really should be the same decl each time. The function in which this happens is not constexpr BTW. I see the __builtin_unreachable first registered through: #0 symbol_table::register_symbol (this=0x715a10a8, node=0x7fffed8e28a0) at ../../gcc/cgraph.h:2448 #1 0x00b2a530 in symtab_node::register_symbol (this=0x7fffed8e28a0) at ../../gcc/symtab.c:375 #2 0x00b358b5 in cgraph_node::create (decl=) at ../../gcc/cgraph.c:507 #3 0x00b359db in cgraph_node::get_create (decl=) at ../../gcc/cgraph.c:529 #4 0x00cfd123 in gimple_get_virt_method_for_vtable (token=2, v=, offset=256, can_refer=0x7fffae1e) at ../../gcc/gimple-fold.c:5758 #5 0x00cfd1c5 in gimple_get_virt_method_for_binfo (token=2, known_binfo=, can_refer=0x7fffae1e) at ../../gcc/gimple-fold.c:5789 #6 0x00db27a9 in possible_polymorphic_call_targets (otr_type=, otr_token=2, context=..., completep=0x7fffb00f, cache_token=0x0, speculative=false) at ../../gcc/ipa-devirt.c:3164 #7 0x00cfee70 in possible_polymorphic_call_targets (ref=, call=, completep=0x7fffb00f, cache_token=0x0) at ../../gcc/ipa-utils.h:131 #8 0x00cf4237 in gimple_fold_call (gsi=0x7fffb350, inplace=false) at ../../gcc/gimple-fold.c:3027 #9 0x00cf6e9b in fold_stmt_1 (gsi=0x7fffb350, inplace=false, valueize=0xcf746d ) at ../../gcc/gimple-fold.c:3726 #10 0x00cf74e7 in fold_stmt (gsi=0x7fffb350) at ../../gcc/gimple-fold.c:3854 #11 0x00d1572d in maybe_fold_stmt (gsi=0x7fffb350) at ../../gcc/gimplify.c:2336 during gimplification, then #1 0x00b3e9d6 in symbol_table::rel
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #39 from Jakub Jelinek --- Sorry, error on my part. There is actually #1 0x00b3e9d6 in symbol_table::release_symbol (this=0x715a10a8, node=, uid=0) at ../../gcc/cgraph.h:2514 #2 0x00b3972a in cgraph_node::remove (this=) at ../../gcc/cgraph.c:1896 #3 0x00df52c0 in symbol_table::remove_unreachable_nodes (this=0x715a10a8, file=0x0) at ../../gcc/ipa.c:531 #4 0x00f3cf1d in execute_todo (flags=448) at ../../gcc/passes.c:2024 #5 0x00f3d9b6 in execute_one_pass (pass=) at ../../gcc/passes.c:2376 #6 0x00f3e798 in execute_ipa_pass_list (pass=) at ../../gcc/passes.c:2766 #7 0x00b4a7b9 in ipa_passes () at ../../gcc/cgraphunit.c:2265 #8 0x00b4ac2d in symbol_table::compile (this=0x715a10a8) at ../../gcc/cgraphunit.c:2404 #9 0x00b4afd4 in symbol_table::finalize_compilation_unit (this=0x715a10a8) at ../../gcc/cgraphunit.c:2564 in between.
[Bug target/70662] New: vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662
Bug ID: 70662
Summary: vpbroadcastq assemble failure with -masm=intel
-mavx512vbmi
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Created attachment 38267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38267&action=edit
reduced testcase
Compiler output:
$ gcc -Og -fschedule-insns -fno-tree-fre -mavx512vbmi
--param=max-sched-ready-insns=1 -masm=intel testcase.c
/tmp/cc4IEVUE.s: Assembler messages:
/tmp/cc4IEVUE.s:383: Error: operand size mismatch for `vpbroadcastq'
The failing instruction is:
vpbroadcastqzmm17{k1}, XMMWORD PTR [rsp+4536]
s/XMMWORD/QWORD/ fixes the assembly. The second operand is a QWORD, but if a
register is referenced, it is an XMM register (only 64 bits are used).
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #12 from H.J. Lu --- It was caused by r208831.
[Bug target/70568] [4.9/5/6 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70568 Richard Biener changed: What|Removed |Added Keywords||ra Target Milestone|--- |4.9.4
[Bug fortran/70330] [5 Regression] ICE with -Wextra -Wno-unused-dummy-argument and unused optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70330 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4
[Bug testsuite/70108] [5/6 Regression] FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g thread simulation test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70108 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4 Summary|[5,6 Regression] FAIL: |[5/6 Regression] FAIL: |gcc.dg/simulate-thread/spec |gcc.dg/simulate-thread/spec |ulative-store-2.c -O0 -g |ulative-store-2.c -O0 -g |thread simulation test |thread simulation test
[Bug c++/70494] [5/6 regression] Internal Compiler Error: Capturing an array of vectors in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70494 Richard Biener changed: What|Removed |Added Known to work||4.9.3 Target Milestone|--- |5.4 Summary|[5 regression] Internal |[5/6 regression] Internal |Compiler Error: Capturing |Compiler Error: Capturing |an array of vectors in a|an array of vectors in a |lambda |lambda
[Bug c++/70627] [6 Regression] internal compiler error: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70627 --- Comment #10 from jseward at acm dot org --- Thank you for fixing this quickly!
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662 Kirill Yukhin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-14 Assignee|unassigned at gcc dot gnu.org |kyukhin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kirill Yukhin --- I'll take a look.
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 --- Comment #4 from Marek Polacek --- And we seem to do the right thing if I just do away with the canon_expr_type: diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 30c815d..8b0a34b 100644 --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -5722,11 +5722,6 @@ build_va_arg (location_t loc, tree expr, tree type) mark_addressable (expr); expr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (expr)), expr); - /* Verify that &ap is still recognized as having va_list type. */ - tree canon_expr_type - = targetm.canonical_va_list_type (TREE_TYPE (expr)); - gcc_assert (canon_expr_type != NULL_TREE); - return build_va_arg_1 (loc, type, expr); } (there are two spots like that)
[Bug c++/70647] Feature request: warning for self-moving in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70647
--- Comment #2 from Matt Godbolt ---
Thanks Manuel. Interestingly this does elicit a warning:
struct B {
int a; int b;
B(B &&o)
: a(static_cast(a)),
b(std::move(o.b)) {}
};
but this does not:
struct B {
int a; int b;
B(B &&o)
: a(static_cast(a)),
b(std::move(o.b)) {}
};
That said; I believe bug 19808 would indeed help in this situation!
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #25 from Bill Schmidt --- I've verified the patch indeed fixes the test from c#11. Regstrap in progress. One nit: The parentheses in the proposed patch are slightly wrong, should be: && (LOOP_VINFO_VECT_FACTOR (loop_vinfo) * GROUP_SIZE (vinfo_for_stmt (GROUP_FIRST_ELEMENT (stmt_info))) % TYPE_VECTOR_SUBPARTS (vectype) != 0))
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #40 from Jakub Jelinek --- So, some further printf debugging shows that the first difference is that in one of the possible_polymorphic_call_targets calls (which creates the node->order == 4151 __builtin_unreachable in one with -g2 only and not with -g2 -gtoggle, the first backtrace in #c38) there is a difference in the context->maybe_in_construction flag - with -g2 it is 0, with -g2 -gtoggle it is 1.
[Bug libstdc++/70664] New: failbit is not set on stream reading negative value into unsigned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70664
Bug ID: 70664
Summary: failbit is not set on stream reading negative value
into unsigned type
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: osternhase at gmx dot de
Target Milestone: ---
I am using Ubuntu 14.04 64-bit (x86_64). Following code snippet:
#include
#include
using namespace std;
template
void test(const char * str)
{
istringstream a(str);
T i;
a >> i;
if (a.fail())
cout << "Ok\n";
else
cout << "Bug\n";
}
int main(int argc, char *argv[])
{
test("2147483648"); // INT_MIN-1
test("-2147483649"); // INT_MAX+1
test("4294967296"); // UINT_MAX+1
test("-1");
return 0;
}
Compile:
g++ t.cpp -o t
result:
Ok
Ok
Ok
Bug
expected:
Ok
Ok
Ok
Ok
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep LIBCXX :
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #26 from Bill Schmidt --- Ah, I see from IRC that Alan has already done a regstrap and reported no failures.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #41 from Richard Biener ---
Maybe decl_maybe_in_construction_p using BLOCKs. I suppose it should restrict
itself to inlined_function_outer_scope_p ()s which we surely preserve.
for (tree block = gimple_block (call); block && TREE_CODE (block) == BLOCK;
block = BLOCK_SUPERCONTEXT (block))
if (tree fn = inlined_polymorphic_ctor_dtor_block_p (block, check_clones))
{
tree type = TYPE_METHOD_BASETYPE (TREE_TYPE (fn));
if (!outer_type || !types_odr_comparable (type, outer_type))
{
if (TREE_CODE (type) == RECORD_TYPE
&& TYPE_BINFO (type)
&& polymorphic_type_binfo_p (TYPE_BINFO (type)))
return true;
}
else if (types_same_for_odr (type, outer_type))
return true;
}
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #27 from Bill Schmidt --- However, that was with the parentheses misplaced. I've completed a bootstrap and regression test on powerpc64le-unknown-linux-gnu with this corrected, and everything is still fine.
[Bug c/70665] New: Seemingly incorrect warning for being const correct with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70665
Bug ID: 70665
Summary: Seemingly incorrect warning for being const correct
with function pointers
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: psusi at ubuntu dot com
Target Milestone: ---
void foo( const char *p );
void bar( char *p ) { foo( p ); }
This is perfectly acceptable and const correct since foo does not want write
access, but being given write access anyway is fine. I have run into a
seemingly incorrect warning though when calling such functions via pointer:
void foo( const char *p );
void bar( void (*fn)(char *p) );
bar( foo );
^^ generates warning about pointers not being compatible.
Apparently gcc thinks that when called via a pointer, it is not correct to pass
a writable pointer where only a read only one is needed.
[Bug tree-optimization/70614] [4.9/5 Regression] GCC gets stuck with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70614 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||6.0 Summary|[4.9/5/6 Regression] GCC|[4.9/5 Regression] GCC gets |gets stuck with -O |stuck with -O Known to fail|6.0 | --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/70614] [4.9/5/6 Regression] GCC gets stuck with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70614 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Apr 14 13:21:40 2016 New Revision: 234972 URL: https://gcc.gnu.org/viewcvs?rev=234972&root=gcc&view=rev Log: 2016-04-14 Richard Biener PR tree-optimization/70614 * tree-scalar-evolution.c (analyze_evolution_in_loop): Terminate loop if the evolution dropped to chrec_dont_know. (interpret_condition_phi): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #28 from Alan Modra --- Bootstrapped and regression testing now completed on both powerpc64le-linux and -m64/-m32 on a power7 powerpc64-linux host, all langs. No regressions found, and it seems this also fixes gcc.dg/vect/slp-perm-12.c on power7 powerpc64-linux. Thanks!
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #42 from Jakub Jelinek ---
I see a difference when tree-ssa-pre.c calls
context.get_dynamic_type (instance, OBJ_TYPE_REF_OBJECT (fn), otr_type, stmt);
in get_dynamic_type, right after the first walk_aliased_vdefs in there, in one
invocation I get:
$16 = {offset = 0, instance = , vtbl_ptr_ref =
,
otr_type = , known_current_type = , known_current_offset = 0, speculative = 14,
type_maybe_changed = false, multiple_types_encountered = false,
seen_unanalyzed_store = true}
and in the other
$15 = {offset = 0, instance = , vtbl_ptr_ref =
,
otr_type = , known_current_type = , known_current_offset = 0, speculative = 13,
type_maybe_changed = false, multiple_types_encountered = false,
seen_unanalyzed_store = false}
[Bug c/70665] Seemingly incorrect warning for being const correct with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70665 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Because const char * and char * are not compatible types. That is they have an implicit conversion between the two but are still not compatible types.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #43 from Richard Biener --- Same walking of BLOCKs in noncall_stmt_may_be_vtbl_ptr_store.
[Bug c/70665] Seemingly incorrect warning for being const correct with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70665 --- Comment #2 from Phillipi Susi --- Yes, so why is there an implicit conversion that does not cause a warning when called directly, but not when called via pointer?
[Bug ada/70645] strange -fguess-branch-probability issue with debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70645 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME Summary|[4.9/5/6 Regression]|strange |-fguess-branch-probability |-fguess-branch-probability |breaks debug-information, |issue with debug info |only in Ada | --- Comment #1 from Eric Botcazou --- I cannot reproduce on Linux. Besides there is no guarantee that debug info be fully correct, except for -O0 and -Og. Try to break on "Hello" instead or to fiddle with the various -gdwarf options since this is Darwin.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #44 from Richard Biener ---
Index: gcc/ipa-polymorphic-call.c
===
--- gcc/ipa-polymorphic-call.c (revision 234971)
+++ gcc/ipa-polymorphic-call.c (working copy)
@@ -485,6 +485,9 @@ contains_type_p (tree outer_type, HOST_W
tree
inlined_polymorphic_ctor_dtor_block_p (tree block, bool check_clones)
{
+ if (! inlined_function_outer_scope_p (block))
+return NULL_TREE;
+
tree fn = block_ultimate_origin (block);
if (fn == NULL || TREE_CODE (fn) != FUNCTION_DECL)
return NULL_TREE;
[Bug middle-end/70643] broken openacc reduction inside a fortran module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70643 --- Comment #1 from cesar at gcc dot gnu.org --- Author: cesar Date: Thu Apr 14 13:44:17 2016 New Revision: 234973 URL: https://gcc.gnu.org/viewcvs?rev=234973&root=gcc&view=rev Log: PR middle-end/70643 gcc/ * omp-low.c (lower_oacc_reductions): Check for TREE_CONSTANT when building a mem ref for the incoming reduction variable. libgomp/ * testsuite/libgomp.oacc-fortran/pr70643.f90: New test. Added: trunk/libgomp/testsuite/libgomp.oacc-fortran/pr70643.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #8 from Jason Merrill --- Created attachment 38269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38269&action=edit patch This fixes the reduced testcase for me on sparc, does it fix bootstrap on the various targets?
[Bug target/70044] [5 Regression] -flto turns on -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044 --- Comment #8 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Apr 14 13:45:34 2016 New Revision: 234974 URL: https://gcc.gnu.org/viewcvs?rev=234974&root=gcc&view=rev Log: [AArch64] Backport of PR target/70044 fix to GCC 5 2016-04-14 Nick Clifton Kyrylo Tkachov PR target/70044 * config/aarch64/aarch64.c (aarch64_override_options_after_change): When forcing flag_omit_frame_pointer to be true, use a special value that can be detected if this function is called again, thus preventing flag_omit_leaf_frame_pointer from being forced to be false. * gcc.target/aarch64/pr70044.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr70044.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #9 from Jack Howarth --- Created attachment 38270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38270&action=edit bzip2 compressed preprocessed source for libstdc++-v3/src/c++11/string-inst.cc on x86_64-apple-darwin15
[Bug target/70044] [5 Regression] -flto turns on -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from ktkachov at gcc dot gnu.org --- Fixed.
[Bug middle-end/70643] broken openacc reduction inside a fortran module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70643 cesar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from cesar at gcc dot gnu.org --- Fixed in r234973.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 Nathan Sidwell changed: What|Removed |Added Assignee|nathan at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #45 from Nathan Sidwell --- I am no longer working on this, Richard appears to have the ball. A patch to stop GC cause the constexpr machinery perturbing DECL_UID is attached to https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00607.html, but currently deemed unnecessary.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #46 from Jakub Jelinek --- So, it seems the ctor BLOCKs are preserved, but others are removed. So, with -g we get: (gdb) p debug_generic_stmt (block_ultimate_origin ($29)) BLOCK #0 SUPERCONTEXT: assign (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext)) assign (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext->block.supercontext)) _M_set_length (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext->block.supercontext->block.supercontext)) BLOCK #0 SUPERCONTEXT: basic_string (gdb) p debug_generic_stmt (block_ultimate_origin ($29->block.supercontext->block.supercontext->block.supercontext->block.supercontext)) basic_string and assign and _M_set_length are FUNCTION_DECLs which aren't cdtors. while with -g0 we get for the same stmt: (gdb) p debug_generic_stmt (block_ultimate_origin ($33)) BLOCK #0 SUPERCONTEXT: assign (gdb) p debug_generic_stmt (block_ultimate_origin ($33->block.supercontext)) BLOCK #0 SUPERCONTEXT: basic_string (gdb) p debug_generic_stmt (block_ultimate_origin ($33->block.supercontext->block.supercontext)) basic_string $29 and $33 above are gimple_block (stmt). This means for -g we have more rich BLOCK tree, with extra 2 BLOCKs in between, which have sadly FUNCTION_DECL block_ultimate_origin.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #10 from Jack Howarth --- (In reply to Jason Merrill from comment #8) > Created attachment 38269 [details] > patch > > This fixes the reduced testcase for me on sparc, does it fix bootstrap on > the various targets? The proposed patch doesn't solve the bootstrap failure on darwin.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/70666] New: SLP vectorization opportunity to use load element + splat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70666 Bug ID: 70666 Summary: SLP vectorization opportunity to use load element + splat Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org CC: dje at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- Target: powerpc*-unknown-linux-gnu As discussed in PR70130, there is an opportunity to produce better code during SLP vectorization for a vector load with a permutation vector where all elements of the permutation are identical. A load of the desired element and a splat would be better than current generated code, which makes use of unaligned loads. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130#c23 for details, and see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130#c11 for a test case that can be used to reproduce the pattern.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #11 from Jack Howarth --- In case it helps, with the proposed patch, the backtrace from fancy_abort in the failing string-inst.cc compilation on darwin appears as... (lldb) bt * thread #1: tid = 0x54d252, 0x0001018798f3 cc1plus`fancy_abort(file="../../gcc-6-20160414/gcc/expr.c", line=3546, function="emit_move_insn") + 19 at diagnostic.c:1329, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0001018798f3 cc1plus`fancy_abort(file="../../gcc-6-20160414/gcc/expr.c", line=3546, function="emit_move_insn") + 19 at diagnostic.c:1329 frame #1: 0x000100da030b cc1plus`emit_move_insn(x=0x00010534cea0, y=0x00010534ce58) + 123 at expr.c:3545 frame #2: 0x000100dca4b0 cc1plus`emit_single_push_insn_1(mode=QImode, x=0x00010534ce58, type=0x0001026b1dc8) + 656 at expr.c:4033 frame #3: 0x000100dab5e9 cc1plus`emit_single_push_insn(mode=QImode, x=0x00010534ce58, type=0x0001026b1dc8) + 57 at expr.c:4045 frame #4: 0x000100dab1a7 cc1plus`emit_push_insn(x=0x00010534ce58, mode=QImode, type=0x0001026b1dc8, size=0x, align=64, partial=0, reg=0x, extra=0, args_addr=0x, args_so_far=0x000144808480, reg_parm_stack_space=0, alignment_pad=0x000144808480, sibcall_p=true) + 3815 at expr.c:4384 frame #5: 0x000100bc315c cc1plus`store_one_arg(arg=0x7fff5fbfd750, argblock=0x, flags=0, variable_size=0, reg_parm_stack_space=0) + 3036 at calls.c:4883 frame #6: 0x000100bbbf16 cc1plus`expand_call(exp=0x000105297b40, target=0x, ignore=1) + 10550 at calls.c:3191 frame #7: 0x000100dbcb8f cc1plus`expand_expr_real_1(exp=0x000105297b40, target=0x, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x, inner_reference_p=false) + 25647 at expr.c:10601 frame #8: 0x000100db4297 cc1plus`expand_expr_real(exp=0x000105297b40, target=0x000144808480, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x, inner_reference_p=false) + 215 at expr.c:7961 frame #9: 0x000100bf44d1 cc1plus`expand_expr(exp=0x000105297b40, target=0x000144808480, mode=VOIDmode, modifier=EXPAND_NORMAL) + 49 at expr.h:256 frame #10: 0x000100bf3a2e cc1plus`expand_call_stmt(stmt=0x000104d79c78) + 2158 at cfgexpand.c:2661 frame #11: 0x000100bf051e cc1plus`expand_gimple_stmt_1(stmt=0x000104d79c78) + 430 at cfgexpand.c:3549 frame #12: 0x000100bee523 cc1plus`expand_gimple_stmt(stmt=0x000104d79c78) + 131 at cfgexpand.c:3715 frame #13: 0x000100bef993 cc1plus`expand_gimple_tailcall(bb=0x000104fb7a28, stmt=0x000104d79c78, can_fallthru=0x7fff5fbff07f) + 35 at cfgexpand.c:3762 frame #14: 0x000100be7ff8 cc1plus`expand_gimple_basic_block(bb=0x000104fb7a28, disable_tail_calls=false) + 4072 at cfgexpand.c:5698 frame #15: 0x000100be4e9a cc1plus`(anonymous namespace)::pass_expand::execute(this=0x000143914260, fun=0x000104d79738) + 4074 at cfgexpand.c:6345 frame #16: 0x0001011eb28a cc1plus`execute_one_pass(pass=0x000143914260) + 762 at passes.c:2336 frame #17: 0x0001011ebdf7 cc1plus`execute_pass_list_1(pass=0x000143914260) + 103 at passes.c:2420 frame #18: 0x0001011dcf6d cc1plus`execute_pass_list(fn=0x000104d79738, pass=0x000143910de0) + 77 at passes.c:2431 frame #19: 0x000100c3c50c cc1plus`cgraph_node::expand(this=0x000104989b80) + 540 at cgraphunit.c:1982 frame #20: 0x000100c4130a cc1plus`expand_all_functions() + 522 at cgraphunit.c:2118 frame #21: 0x000100c4022e cc1plus`symbol_table::compile(this=0x0001448050a8) + 990 at cgraphunit.c:2474 frame #22: 0x000100c414f9 cc1plus`symbol_table::finalize_compilation_unit(this=0x0001448050a8) + 297 at cgraphunit.c:2564 frame #23: 0x000101338cd0 cc1plus`compile_file() + 224 at toplev.c:490 frame #24: 0x000101337318 cc1plus`do_compile() + 328 at toplev.c:1988 frame #25: 0x000101336d48 cc1plus`toplev::main(this=0x7fff5fbff8a8, argc=30, argv=0x7fff5fbff8e8) + 376 at toplev.c:2096 frame #26: 0x00010185fe20 cc1plus`main(argc=30, argv=0x7fff5fbff8e8) + 64 at main.c:39 frame #27: 0x7fff862545ad libdyld.dylib`start + 1 frame #28: 0x7fff862545ad libdyld.dylib`start + 1 (lldb)
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650
--- Comment #12 from Jack Howarth ---
(In reply to Jakub Jelinek from comment #6)
> Shorter testcase:
> struct A {};
>
> void
> foo (struct A a, int b)
> {
> }
> compiles with sparc-solaris C, but doesn't with C++.
This test case doesn't trigger an ICE in the compiler on x86_64 darwin with or
without the proposed patch for the sparc bootstrap failure.
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #29 from Pat Haugen --- Verified the patch also fixes the problem with h264ref benchmark.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
--- Comment #47 from Jakub Jelinek ---
Ok, found one bug in the unused block pruning:
--- gcc/ipa-polymorphic-call.c.jj 2016-03-30 16:00:17.0 +0200
+++ gcc/ipa-polymorphic-call.c 2016-04-14 16:45:45.407754387 +0200
@@ -479,16 +479,12 @@ contains_type_p (tree outer_type, HOST_W
}
-/* Return a FUNCTION_DECL if BLOCK represents a constructor or destructor.
+/* Return a FUNCTION_DECL if FN represent a constructor or destructor.
If CHECK_CLONES is true, also check for clones of ctor/dtors. */
tree
-inlined_polymorphic_ctor_dtor_block_p (tree block, bool check_clones)
+polymorphic_ctor_dtor_p (tree fn, bool check_clones)
{
- tree fn = block_ultimate_origin (block);
- if (fn == NULL || TREE_CODE (fn) != FUNCTION_DECL)
-return NULL_TREE;
-
if (TREE_CODE (TREE_TYPE (fn)) != METHOD_TYPE
|| (!DECL_CXX_CONSTRUCTOR_P (fn) && !DECL_CXX_DESTRUCTOR_P (fn)))
{
@@ -510,6 +506,19 @@ inlined_polymorphic_ctor_dtor_block_p (t
return fn;
}
+/* Return a FUNCTION_DECL if BLOCK represents a constructor or destructor.
+ If CHECK_CLONES is true, also check for clones of ctor/dtors. */
+
+tree
+inlined_polymorphic_ctor_dtor_block_p (tree block, bool check_clones)
+{
+ tree fn = block_ultimate_origin (block);
+ if (fn == NULL || TREE_CODE (fn) != FUNCTION_DECL)
+return NULL_TREE;
+
+ return polymorphic_ctor_dtor_p (fn, check_clones);
+}
+
/* We know that the instance is stored in variable or parameter
(not dynamically allocated) and we want to disprove the fact
--- gcc/ipa-utils.h.jj 2016-01-04 14:55:51.0 +0100
+++ gcc/ipa-utils.h 2016-04-14 16:46:08.828444152 +0200
@@ -70,6 +70,7 @@ void dump_possible_polymorphic_call_targ
bool possible_polymorphic_call_target_p (tree, HOST_WIDE_INT,
const ipa_polymorphic_call_context &,
struct cgraph_node *);
+tree polymorphic_ctor_dtor_p (tree, bool);
tree inlined_polymorphic_ctor_dtor_block_p (tree, bool);
bool decl_maybe_in_construction_p (tree, tree, gimple *, tree);
tree vtable_pointer_value_to_binfo (const_tree);
--- gcc/tree-ssa-live.c.jj 2016-01-04 14:55:51.0 +0100
+++ gcc/tree-ssa-live.c 2016-04-14 16:47:33.343324654 +0200
@@ -855,7 +855,9 @@ remove_unused_locals (void)
cfun->local_decls->truncate (dstidx);
}
- remove_unused_scope_block_p (DECL_INITIAL (current_function_decl), false);
+ remove_unused_scope_block_p (DECL_INITIAL (current_function_decl),
+ polymorphic_ctor_dtor_p (current_function_decl,
+ true) != NULL_TREE);
clear_unused_block_pointer ();
BITMAP_FREE (usedvars);
but sadly this still doesn't fix it (though, fixes at least the first case
where we nuke the needed BLOCK).
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #13 from Jason Merrill --- The darwin problem is with an ipa-icf thunk trying to pass the parameter on directly, which breaks because it's using the parameter's TREE_TYPE rather than DECL_ARG_TYPE. expand_call handles this transparently for integral promotions by way of promote_function_mode, but doesn't know how to do the equivalent here. This is a significant problem with trying to handle this transition in the front end rather than the back end (as H.J.'s patch did).
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #14 from Jack Howarth --- (In reply to Jason Merrill from comment #13) Is darwin the only target using TREE_TYPE rather than DECL_ARG_TYPE?
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #48 from Jakub Jelinek --- Created attachment 38271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38271&action=edit gcc6-pr70594.patch Untested fix. So the other issue is that noncall_stmt_may_be_vtbl_ptr_store looks for BLOCKs with block_ultimate_origin of FUNCTION_DECL (which is correct), and tree-ssa-live.c was doing that too for finding the cdtor BLOCKs (through inlined_polymorphic_ctor_dtor_block_p), but only looked if BLOCK_ABSTRACT_ORIGIN is FUNCTION_DECL inside of those blocks, which is wrong, that is just subset of what block_ultimate_origin returns. As for the changes I've mentioned in the previous comment already and that are included in this patch too, the thing is that while the pruning code works (except for the above mentioned thing) right when we have a cdtor inlined and some other function inlined into it, we can actually lose the needed BLOCKs already earlier, when pruning unused BLOCKs inside of the cdtor itself before it is inlined - then we also have to avoid pruning the BLOCKs with FUNCTION_DECL ultimate origins (except we of course can prune such blocks inside of BLOCKs with FUNCTION_DECL ultimate origins), thus we need to start with the right value of the is_ctor_dtor_block flag - DECL_INITIAL (current_function_block) usually doesn't have block_ultimate_origin a FUNCTION_DECL and even if it does, it is not current_function_decl - only BLOCK_SUPERCONTEXT (DECL_INITIAL (current_function_decl)) is current_function_decl. This patch fixes the -fcompare-debug issue on the Tobias' testcase.
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 --- Comment #5 from Jakub Jelinek --- Yeah, the assertions are clearly bogus. Though perhaps it would be better to just error out at those spots instead of ignoring it and hoping we'll error out later.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #15 from Jason Merrill --- (In reply to Jack Howarth from comment #14) > (In reply to Jason Merrill from comment #13) > Is darwin the only target using TREE_TYPE rather than DECL_ARG_TYPE? No, that should be the same for all targets; I don't know why this would affect darwin and not linux.
[Bug c++/70649] [6 Regression] Incorrect C++ warning on zero-sized array passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70649 --- Comment #1 from Jason Merrill --- Created attachment 38272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38272&action=edit fix
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jason Merrill --- Fixed by reverting the abi change.
[Bug c++/70649] [6 Regression] Incorrect C++ warning on zero-sized array passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70649 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed by reverting the ABI change.
[Bug c++/70667] New: SFINAE error disambiguating using alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70667
Bug ID: 70667
Summary: SFINAE error disambiguating using alignas
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following program tries to use SFINAE to determine whether a non-type
template argument N is a valid alignment. It depends on overload resolution to
choose between two overloads of function template f, only one of which is valid
for the given value of N. Since the first overload isn't viable (3 is not a
valid alignment because it isn't a non-negative power of 2), the second
overload is expected to be selected. But instead, GCC fails with an error.
$ cat u.c && g++ -S -Wall -Wextra -Wpedantic -xc++ u.c
template struct A { alignas (N) int a; };
template struct B { char c; };
template int f (int (*)[sizeof (A)]) { return 0; }
template int f (int (*)[sizeof (B)]) { return 1; }
int i = f<3>();
u.c: In instantiation of ‘struct A<3>’:
u.c:4:40: required by substitution of ‘template int f(int (*)[sizeof
(A)]) [with int N = 3]’
u.c:7:14: required from here
u.c:1:45: error: requested alignment is not a positive power of 2
template struct A { alignas (N) int a; };
^
u.c:7:14: error: no matching function for call to ‘f()’
int i = f<3>();
^
u.c:4:22: note: candidate: template int f(int (*)[sizeof (A)])
template int f (int (*)[sizeof (A)]) { return 0; }
^
u.c:4:22: note: substitution of deduced template arguments resulted in errors
seen above
u.c:5:22: note: candidate: template int f(int (*)[sizeof (B)])
template int f (int (*)[sizeof (B)]) { return 1; }
^
u.c:5:22: note: template argument deduction/substitution failed:
u.c:7:14: note: candidate expects 1 argument, 0 provided
int i = f<3>();
^
[Bug c++/70029] [6 Regression] ICE with C++11 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Thu Apr 14 16:51:16 2016 New Revision: 234979 URL: https://gcc.gnu.org/viewcvs?rev=234979&root=gcc&view=rev Log: PR c++/70029 * tree.c (verify_type): Disable the canonical type of main variant check. * g++.dg/torture/pr70029.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr70029.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug c++/70029] [7 Regression] ICE with C++11 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029 Marek Polacek changed: What|Removed |Added Target Milestone|6.0 |7.0 Summary|[6 Regression] ICE with |[7 Regression] ICE with |C++11 and -flto |C++11 and -flto --- Comment #10 from Marek Polacek --- Resolved for GCC 6 by disabling the check; leaving this open for a proper solution in GCC 7.
[Bug c++/70648] [6 Regression] adplug-xmms fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70648 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-14 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/70543] [6 Regression] wrong non-const error for enable_if and constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70543 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to fail||6.0 --- Comment #4 from Martin Sebor --- The change (r234966) resolves a regression (bug 69517) in how C++ VLAs initialized with excess elements are handled: by throwing an exception in GCC 4.9, and by allowing the program to crash in 5 and 6. Jakub and Jason agreed in an IRC discussion that due to the reported problem and the proximity of GCC 6 release date the change should be backed out and resubmitted in stage 1 for GCC 7. I'll take care of it.
[Bug bootstrap/70650] [6 regression] bootstrap failure: ICE in emit_move_insn, at expr.c:3546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70650 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Jason Merrill --- [...] > This fixes the reduced testcase for me on sparc, does it fix bootstrap on the > various targets? Just for the record, with your patch a sparc-sun-solaris2.12 bootstrap is well into stage2, so the immediate failure is gone. Will be a couple more hours before I have testsuite results. Rainer
[Bug c/70668] New: nds32-elf toolchain fails to compile on OSX"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 Bug ID: 70668 Summary: nds32-elf toolchain fails to compile on OSX" Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stefan.reinauer at coreboot dot org Target Milestone: ---
[Bug c/70668] nds32-elf toolchain fails to compile on OSX"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 --- Comment #1 from Stefan Reinauer --- Created attachment 38273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38273&action=edit minimal example
[Bug bootstrap/70652] [6 Regression] r234966 causes bootstrap to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652 --- Comment #5 from Martin Sebor --- Author: msebor Date: Thu Apr 14 17:35:23 2016 New Revision: 234981 URL: https://gcc.gnu.org/viewcvs?rev=234981&root=gcc&view=rev Log: PR c++/70652 - [6 Regression] r234966 causes bootstrap to fail Revert patch for c++/69517, c++/70019, and c++/70588. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/vla12.C trunk/gcc/testsuite/g++.dg/cpp1y/vla13.C trunk/gcc/testsuite/g++.dg/cpp1y/vla14.C trunk/gcc/testsuite/g++.dg/cpp1y/vla3.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/typeck2.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/vla-1.c trunk/gcc/testsuite/g++.dg/init/array24.C trunk/gcc/testsuite/g++.dg/ubsan/vla-1.C
[Bug c/70668] nds32-elf toolchain fails to compile on OSX"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 Stefan Reinauer changed: What|Removed |Added Target||nds32le-elf Host||Darwin 15.4.0 --- Comment #2 from Stefan Reinauer --- The environment is Mac OS X El Capitan (Darwin 15.4.0) cross compiler build for nds32le-elf fails when building libgcc. So far, I tracked the issue down to cc1 crashing when compiling divfs3.c (or even the attached minimized example of it) - 8< -- 8< --- ./build-nds32le-elf-GCC/gcc/cc1 divsf3.c __divsf3 Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: __divsf3Abort trap: 6 - 8< -- 8< --- Debugger output: - 8< -- 8< --- lldb ./build-nds32le-elf-GCC/gcc/cc1 (lldb) target create "./build-nds32le-elf-GCC/gcc/cc1" Current executable set to './build-nds32le-elf-GCC/gcc/cc1' (x86_64). (lldb) run divsf3.c Process 45989 launched: './build-nds32le-elf-GCC/gcc/cc1' (x86_64) __divsf3 Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: __divsf3Process 45989 stopped * thread #1: tid = 0x5c6719, 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fff9ee20f06 <+10>: jae0x7fff9ee20f10; <+20> 0x7fff9ee20f08 <+12>: movq %rax, %rdi 0x7fff9ee20f0b <+15>: jmp0x7fff9ee1b7cd; cerror_nocancel 0x7fff9ee20f10 <+20>: retq (lldb) bt * thread #1: tid = 0x5c6719, 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x7fff9ee20f06 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x7fff9bf0f4ec libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x7fff98512787 libsystem_c.dylib`__abort + 145 frame #3: 0x7fff98513066 libsystem_c.dylib`__stack_chk_fail + 200 frame #4: 0x0001001198d8 cc1`gen_casesi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) + 392 frame #5: 0x0001006a69bc cc1`insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const + 76 frame #6: 0x000100697b09 cc1`maybe_gen_insn(insn_code, unsigned int, expand_operand*) + 473 frame #7: 0x0001006a4001 cc1`maybe_expand_jump_insn(insn_code, unsigned int, expand_operand*) + 33 frame #8: 0x000100699481 cc1`expand_jump_insn(insn_code, unsigned int, expand_operand*) + 33 frame #9: 0x000100353f20 cc1`try_casesi(tree_node*, tree_node*, tree_node*, tree_node*, rtx_def*, rtx_def*, rtx_def*, int) + 864 frame #10: 0x0001007c0ee9 cc1`emit_case_dispatch_table(tree_node*, tree_node*, case_node*, rtx_def*, tree_node*, tree_node*, tree_node*, basic_block_def*) + 313 frame #11: 0x0001007c07aa cc1`expand_case(gswitch*) + 1290 frame #12: 0x0001001c04b2 cc1`expand_gimple_stmt_1(gimple_statement_base*) + 386 frame #13: 0x0001001beba3 cc1`expand_gimple_stmt(gimple_statement_base*) + 131 frame #14: 0x0001001b989b cc1`expand_gimple_basic_block(basic_block_def*, bool) + 3803 frame #15: 0x0001001b6bef cc1`(anonymous namespace)::pass_expand::execute(function*) + 3199 frame #16: 0x0001006c67b1 cc1`execute_one_pass(opt_pass*) + 721 frame #17: 0x0001006c709e cc1`execute_pass_list_1(opt_pass*) + 78 frame #18: 0x0001006b9732 cc1`execute_pass_list(function*, opt_pass*) + 34 frame #19: 0x0001002008dd cc1`cgraph_node::expand() + 365 frame #20: 0x000100203f45 cc1`output_in_order(bool) + 917 frame #21: 0x0001002035d2 cc1`symbol_table::compile() + 642 frame #22: 0x000100204363 cc1`symbol_table::finalize_compilation_unit() + 179 frame #23: 0x00010001c67a cc1`c_write_global_declarations() + 474 frame #24: 0x0001007d9c47 cc1`compile_file() + 167 frame #25: 0x0001007d8438 cc1`do_compile() + 328 frame #26: 0x0001007d7e83 cc1`toplev::main(int, char**) + 371 frame #27: 0x000100b3dbeb cc1`main + 59 frame #28: 0x7fff90a6b5ad libdyld.dylib`start + 1 frame #29: 0x7fff90a6b5ad libdyld.dylib`start + 1 (lldb) - 8< -- 8< ---
[Bug c/70668] nds32-elf toolchain fails to compile on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 Stefan Reinauer changed: What|Removed |Added Summary|nds32-elf toolchain fails |nds32-elf toolchain fails |to compile on OSX" |to compile on OSX --- Comment #3 from Stefan Reinauer --- Also, I have found out that passing -fno-jump-tables to the compiler call fixes the issue. Interestingly enough, I have built cross toolchains on OS X for i386-elf, x86_64-elf, arm-eabi, aarch64-elf, powerpc64-linux-gnu, mipsel-elf (and riscv with a local patch) and only nds32le-elf is crashing. So, while the same script does not crash on Ubuntu 15.10 compiling a nds32le-elf cross toolchain, it seems it's rather a problem that happens to be exposed on OS X than a problem with OS X.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #60 from Roger Orr --- Thanks; I can now confirm that a full build of our application with distcc works without problems.
