[Bug tree-optimization/97539] [10/11 Regression] ICE verify_ssa failed since r10-4200-gb7ff7cef5005721e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97539 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:27c14056f4805c9d8cfc655ef2c846be128b02c9 commit r11-4376-g27c14056f4805c9d8cfc655ef2c846be128b02c9 Author: Richard Biener Date: Mon Oct 26 10:08:38 2020 +0100 tree-optimization/97539 - reset out-of-loop debug uses before peeling This makes sure to reset out-of-loop debug uses before vectorizer loop peeling as we cannot make sure to retain the use-def dominance relationship when there are no LC SSA nodes. 2020-10-26 Richard Biener PR tree-optimization/97539 * tree-vect-loop-manip.c (vect_do_peeling): Reset out-of-loop debug uses before peeling. * gcc.dg/pr97539.c: New testcase.
[Bug tree-optimization/97559] [11 Regression] ICE at -O1 and above on x86_64-pc-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559 Jakub Jelinek changed: What|Removed |Added Summary|ICE at -O1 and above on |[11 Regression] ICE at -O1 |x86_64-pc-linux-gnu:|and above on |verify_ssa failed |x86_64-pc-linux-gnu: ||verify_ssa failed CC||jakub at gcc dot gnu.org Priority|P3 |P1 Target Milestone|--- |11.0
[Bug tree-optimization/97556] [11 Regression] ICE at -O2 and -O3 in 32-bit mode on x86_64-pc-linux-gnu in size_remaining, at builtins.c:235 since r11-3827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97556
--- Comment #2 from Jakub Jelinek ---
I think the problem is that compute_objsize doesn't bother to check for any
kind of overflow on any arithmetics it does.
E.g. in:
4815 offset_int sz = wi::to_offset (tpsize);
4816 orng[0] *= sz;
4817 orng[1] *= sz;
when orng[0] is 10 and orng[1] is -1 and sz is 3, everything is
multiplied by 3, so we end up with 30 and -3. Later on the upper bound
is set to
311 offset_int maxoff = wi::to_offset (TYPE_MAX_VALUE
(ptrdiff_type_node));
312 offrng[1] = maxoff;
and size_remaining then asserts something that the computation can't really
guarantee.
Adjusted testcase that ICEs with -O2 -m64 the same way:
char a[1][3];
int b;
void f () {
unsigned long long c = 700ULL;
if (b)
goto L;
while (b) {
c = ~0ULL;
L:
a[c][0] = 0;
}
}
[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #7 from jbeulich at suse dot com --- For the problem originally reported here (operator name space collision) a workaround could be introduced (e.g. a new operand to .intel_syntax to allow suppressing the recognition of MASM-like operands). I don't, however, see any option for register names (besides ".intel_syntax prefix" of course, but aiui this wouldn't work with the output gcc produces, and of course this mode isn't really "Intel Syntax" anymore anyway).
[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 --- Comment #6 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #3) > The problem is that the intel asm syntax is just badly defined (broken by > design). I'm not aware of any compiler that would emit for such testcases > something that could be assembled correctly with gas. At the risk of stating the obvious, Intel syntax implies that global symbols would have a prefix character appended, typically an underscore, or that otherwise global symbols avoid the assembler recognized identifiers. This sadly is a growing set as new register extensions get added. IOW people wanting to avoid having to rename their symbols eventually would need to also restrict the set of recognized register names via suitable .arch directives.(In reply to Jakub Jelinek from comment #5) > It is far easier to use (the default) assembler syntax that is properly > designed and doesn't have flaws like this. While in the general case I agree, there are downsides when it comes to wanting to make use of macros to "stand in" for instructions, and then wanting to e.g. derive symbols from macro arguments specifying registers. Such macros need to go to some length to get rid of the % character.
[Bug driver/97574] Allow for nul output with Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-26 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Confirmed then.
[Bug tree-optimization/97559] ICE at -O1 and above on x86_64-pc-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Known to fail||11.0 CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Btw. started with r11-3705-gdae673abd37d4004.
[Bug c++/97569] Declaring a struct in a field declaration of another struct. gcc and clang difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #3 from Jonathan Wakely ---
Ah right, so
int main()
{
struct A
{
struct B *b;
struct C {} *c;
};
using U = B;
using V = C;
}
For the `struct C {}` case that explicitly defines (and declares) a new struct
in the scope of A, i.e. A::C, and so it's definitely correct that it isn't
declared in the enclosing block scope. That case is substantially different,
and all compilers agree on that.
For `struct B *b` the standard says that implicitly declares a new type, but
not as a member of A. [basic.scope.pdecl] p7 (7.2) says that the the identifier
B "is declared in the smallest namespace or block scope that contains the
declaration." And that's the block scope of main. So I think GCC is correct,
and Clang is wrong. EDG agrees with GCC FWIW.
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 --- Comment #3 from Richard Biener --- But then in vect_fixup_scalar_cycles_with_patterns we leave us with a reduction chain with eventually half irrelevant stmts because we mix in-pattern and non-in-pattern stmts for gcc.dg/vect/pr83965-2.c. Will think of the situation after some of the current refactoring is finished.
[Bug ipa/97576] [11 Regression] ICE: verify_cgraph_node failed (error: reference to dead statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576 --- Comment #2 from Jan Hubicka --- The problem here is that clone materialization invalidates statement pointers in refs. We clean these at the begining of late optimization, I guess it should be done on demand during materialization (they are not used past that point, but we do not have convenient place to clear them).
[Bug ipa/97576] [11 Regression] ICE: verify_cgraph_node failed (error: reference to dead statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||10.2.0 Last reconfirmed||2020-10-26 Known to fail||11.0 Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-4267-g0e590b68fa374365. Likely another dup.
[Bug ipa/97575] [11 Regression] ICE in try_make_edge_direct_simple_call, at ipa-prop.c:3671 or in propagate_controlled_uses, at ipa-prop.c:4073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97575 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-26 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97551 Priority|P3 |P1 Ever confirmed|0 |1 CC||hubicka at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r11-4267-g0e590b68fa374365. Likely dup.
[Bug driver/97574] Allow for nul output with Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #2 from Tamar Christina --- error is in the driver, it's accidentally adding the suffix when nul device is used and making the filename invalid. diff --git a/gcc/gcc.c b/gcc/gcc.c index ff7b6c4a320..74438f63046 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -3651,7 +3651,7 @@ convert_filename (const char *name, int do_exe ATTRIBUTE_UNUSED, #if defined(HAVE_TARGET_EXECUTABLE_SUFFIX) /* If there is no filetype, make it the executable suffix (which includes the "."). But don't get confused if we have just "-o". */ - if (! do_exe || TARGET_EXECUTABLE_SUFFIX[0] == 0 || (len == 2 && name[0] == '-')) + if (! do_exe || TARGET_EXECUTABLE_SUFFIX[0] == 0 || not_actual_file_p (name)) return name; for (i = len - 1; i >= 0; i--) should fix it, but can't test till later.
[Bug ipa/97551] ICE: verify_cgraph_node failed with "-O2 -fno-toplevel-reorder -fno-tree-dce -fno-tree-forwprop -fno-tree-fre -fipa-cp-clone"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97551 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Known to fail||11.0 Priority|P3 |P1 Ever confirmed|0 |1 Known to work||10.2.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-26 --- Comment #1 from Martin Liška --- Started with r11-4267-g0e590b68fa374365.
[Bug driver/97574] Allow for nul output with Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574 --- Comment #1 from Jonathan Wakely --- I think "nul" should work, but it looks like the error is in the linker, ld.exe, not GCC.
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 --- Comment #2 from Richard Biener --- Huh. OK, so we're having a !relevant and !live stmt in the SLP tree, and the removed check for !vectype caught this.
[Bug tree-optimization/97539] [10/11 Regression] ICE verify_ssa failed since r10-4200-gb7ff7cef5005721e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97539 --- Comment #3 from Richard Biener --- So the fundamental issue is that we have a debug-only live use and we do not have LC SSA for those. When vectorizer epilogue peeling then creates the loop copy the debug use is still refering to the first loop but that def no longer dominates the use because of the branch to the epilogue skipping the vectorized loop. The simplest workaround would be to first to a sweep over the original loop body searching for such uses and resetting the corresponding debug binds.
[Bug preprocessor/97577] New: [11 Regression] ICE: Segmentation fault (in get_location_from_adhoc_loc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97577 Bug ID: 97577 Summary: [11 Regression] ICE: Segmentation fault (in get_location_from_adhoc_loc) Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc-11.0.0-alpha20201025 snapshot (g:308e40331f9d2820f8286769b5fc764671187364) ICEs when compiling the following testcase, reduced from test/Preprocessor/annotate_in_macro_arg.c from the clang 10.0.1 test suite: #define M1() M1( #if M1() #endif #pragma pack() % MALLOC_PERTURB_=1 MALLOC_CHECK_=3 gcc-11.0.0 -c ifhvkm83.c ifhvkm83.c:5:9: error: #if with no expression 5 | #if M1() | ^ ifhvkm83.c:7:9: internal compiler error: Segmentation fault 7 | #pragma pack() | ^~~~ 0xdbaf3f crash_signal /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/toplev.c:330 0x192e151 get_location_from_adhoc_loc(line_maps const*, unsigned int) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/line-map.c:257 0x192e151 linemap_resolve_location(line_maps*, unsigned int, location_resolution_kind, line_map_ordinary const**) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/line-map.c:1540 0x18e8933 diagnostic_report_current_module(diagnostic_context*, unsigned int) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/diagnostic.c:683 0xe15071 diagnostic_report_current_function(diagnostic_context*, diagnostic_info*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-diagnostic.c:39 0xe150d0 default_tree_diagnostic_starter /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-diagnostic.c:48 0x18e6a27 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/diagnostic.c:1206 0x885aaa c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level, cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1]) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/c-family/c-common.c:6364 0x191df49 cpp_diagnostic_at /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/errors.c:42 0x191df49 cpp_diagnostic /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/errors.c:75 0x191e06e cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/errors.c:89 0x1931f58 collect_args /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/macro.c:1267 0x1931f58 funlike_invocation_p /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/macro.c:1326 0x1931f58 enter_macro_context /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/macro.c:1401 0x19326e2 cpp_get_token_1 /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/libcpp/macro.c:2890 0x89fe80 c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/c-family/c-lex.c:457 0x81d67a c_lex_one_token /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/c/c-parser.c:279 0x85005a c_parser_peek_token(c_parser*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/c/c-parser.c:483 0x85005a c_parse_file() /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/c/c-parser.c:21819 0x8abe2d c_common_parse_file() /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/c-family/c-opts.c:1188 I've failed to reproduce it w/ valgrind so far.
[Bug tree-optimization/97559] ICE at -O1 and above on x86_64-pc-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559
--- Comment #2 from Richard Biener ---
OK, so as expected this is
static bool
statement_sink_location (gimple *stmt, basic_block frombb,
gimple_stmt_iterator *togsi, bool *zero_uses_p)
{
...
/* If this is a load then do not sink past any stores.
Look for virtual definitions in the path from frombb to the sink
location computed from the real uses and if found, adjust
that it a common dominator. */
if (gimple_vuse (stmt))
{
...
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vuse (stmt))
{
...
/* In case the PHI node post-dominates the current insert
location
we can disregard it. But make sure it is not dominating
it as well as can happen in a CFG cycle. */
if (commondom != bb
&& !dominated_by_p (CDI_DOMINATORS, commondom, bb)
&& dominated_by_p (CDI_POST_DOMINATORS, commondom, bb))
continue;
where the use stmt is in an irreducible region and thus the dominance
check breaks down. We want to avoid doing a full 'is use_stmt' on a
path from bb to commondom check and thus are employing some heuristics
to capture most cases. We do have natural loops computed here and
irreducible regions marked, need to think about an adjustment to the above.
Meanwhile more testcases are always welcome.
[Bug ipa/97565] -flto -ipa-pta ICE: at cgraph_node::get_untransformed_body()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97565 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-10-26 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I will have a look.
[Bug ipa/97576] [11 Regression] ICE: verify_cgraph_node failed (error: reference to dead statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576 Richard Biener changed: What|Removed |Added Keywords||openmp Target Milestone|--- |11.0
[Bug ipa/97575] [11 Regression] ICE in try_make_edge_direct_simple_call, at ipa-prop.c:3671 or in propagate_controlled_uses, at ipa-prop.c:4073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97575 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug rtl-optimization/97554] ICE: during RTL pass: cprop /segfault in sbitmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97554
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2020-10-26
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Confirmed. We're doing
#1 0x02343be5 in alloc_cprop_mem (n_blocks=249747, n_sets=137435)
at /home/rguenther/src/gcc2/gcc/cprop.c:557
557 cprop_avloc = sbitmap_vector_alloc (n_blocks, n_sets);
where sbitmap_vector_alloc continues to use 'int' for things like size:
139 sbitmap *
140 sbitmap_vector_alloc (unsigned int n_vecs, unsigned int n_elms)
141 {
142 unsigned int i, bytes, offset, elm_bytes, size, amt, vector_bytes;
143 sbitmap *bitmap_vector;
144
and eventually 'amt' overflows:
amt = vector_bytes + (n_vecs * elm_bytes);
(gdb) p vector_bytes
$8 = 1997976
(gdb) p n_vecs
$9 = 249747
(gdb) p elm_bytes
$10 = 17192
(gdb) p amt
$11 = 681104
I'll fix that part.
[Bug tree-optimization/97559] ICE at -O1 and above on x86_64-pc-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97559 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-10-26 --- Comment #1 from Richard Biener --- I will have a look.
[Bug ada/97557] [11 regression] several ada test case failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97557 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Mine.
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #6 from Libin Dang ---
(In reply to Martin Liška from comment #2)
> Using latest GCC release you can see what happens:
>
> $ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
> hello
> libgcov profiling
> error:/home/marxin/Programming/testcases/a-pr96919.gcda:overwriting an
> existing profile data with a different timestamp
> -:0:Source:pr96919.cc
> -:0:Graph:a-pr96919.gcno
> -:0:Data:a-pr96919.gcda
> -:0:Runs:1
> -:1:class Base {
> -:2:public:
> -:3: Base() = default;
>1*:4: virtual ~Base() = default;
> --
> _ZN4BaseD0Ev:
> #:4: virtual ~Base() = default;
> --
> _ZN4BaseD2Ev:
> 1:4: virtual ~Base() = default;
> --
> -:5: virtual void foo() = 0;
> -:6:};
> -:7:class Hello : public Base {
> -:8:public:
> -:9: Hello() = default;
>1*: 10: ~Hello() = default;
> --
> _ZN5HelloD0Ev:
> #: 10: ~Hello() = default;
> --
> _ZN5HelloD2Ev:
> 1: 10: ~Hello() = default;
> --
> -: 11: void foo() override;
> -: 12:};
> -: 13:
> -: 14:#include
> -: 15:
> -: 16:using namespace std;
> -: 17:
> 1: 18:void Hello::foo() {
> 1: 19: cout << "hello" << endl;
> 1: 20:}
> -: 21:
> 1: 22:int main(int argc, char* argv[]) {
> #: 23: Hello hello;
> 1: 24: hello.foo();
> 1: 25: return 0;
> -: 26:}
>
> So yes, it's a virtual destructor _ZN4BaseD0Ev that is not called.
> And the not executed line:
> #:4: Hello hello;
>
> corresponds to a basic block
>
>:
> :
> Hello::~Hello (&hello);
> resx 2
>
> which would be executed when the Hellow constructor fails.
A strange thing about this test case:
If I removed 'return 0;' at line 25, gcov will mark line 23 as executed.
Tested with both gcov 8.3 and 10.2.
