[Bug tree-optimization/95273] [11 regression] many ICEs after r11-564

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95273

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Richard Biener  ---
Mine.

[Bug middle-end/95277] error on alignment for a function argument

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95277

--- Comment #1 from Richard Biener  ---
The question is whether those attributes shall change the ABI or whether it
is enough for GCC to apply this alignment to the incoming variable by
eventually
issueing a callee-copy.  And what happens to C++ type where producing another
copy is not allowed.

Does _Alignas work here?

[Bug tree-optimization/95281] ICE: in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95281

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will take a look.

[Bug tree-optimization/95283] ICE: in hoist_memory_references, at tree-ssa-loop-im.c:2607

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95283

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2020-05-25

--- Comment #1 from Richard Biener  ---
I will take a look.

[Bug tree-optimization/95284] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95284

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-05-25

--- Comment #1 from Richard Biener  ---
Mine.

[Bug tree-optimization/95290] ice in useless_type_conversion_p

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95290

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.0
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-25
  Component|c++ |tree-optimization

--- Comment #1 from Richard Biener  ---
Mine.

[Bug c++/95291] ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||11.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

t.ii:8:54: internal compiler error: Segmentation fault
8 | struct flip_horizontally : window_root< minion::size >{ };
  |  ^
0x167e38f crash_signal
/space/rguenther/src/gcc/gcc/toplev.c:328
0x7f77239f61df ???
   
/usr/src/debug/glibc-2.26-lp151.18.7.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x9e195c resolve_args(vec*, int)
/space/rguenther/src/gcc/gcc/cp/call.c:4482
0xce12bf do_class_deduction
/space/rguenther/src/gcc/gcc/cp/pt.c:28706
0xce1f52 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/space/rguenther/src/gcc/gcc/cp/pt.c:28839
0xc7eb48 convert_template_argument
/space/rguenther/src/gcc/gcc/cp/pt.c:8403
0xc8080c coerce_template_parms
/space/rguenther/src/gcc/gcc/cp/pt.c:8907
0xc80fb3 coerce_innermost_template_parms
/space/rguenther/src/gcc/gcc/cp/pt.c:9053
0xc832fc lookup_template_class_1
/space/rguenther/src/gcc/gcc/cp/pt.c:9744
0xc86161 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/space/rguenther/src/gcc/gcc/cp/pt.c:10128
0xd0d6b7 finish_template_type(tree_node*, tree_node*, int)
/space/rguenther/src/gcc/gcc/cp/semantics.c:3411
0xc078e5 cp_parser_template_id
/space/rguenther/src/gcc/gcc/cp/parser.c:16749
0xc15bba cp_parser_class_name
/space/rguenther/src/gcc/gcc/cp/parser.c:23715
0xbf2c4f cp_parser_qualifying_entity
/space/rguenther/src/gcc/gcc/cp/parser.c:6776
0xbf212d cp_parser_nested_name_specifier_opt
/space/rguenther/src/gcc/gcc/cp/parser.c:6458
0xc1a4f2 cp_parser_base_specifier
/space/rguenther/src/gcc/gcc/cp/parser.c:25721
0xc1a1a7 cp_parser_base_clause
/space/rguenther/src/gcc/gcc/cp/parser.c:25574
0xc185d4 cp_parser_class_head
/space/rguenther/src/gcc/gcc/cp/parser.c:24669
0xc16294 cp_parser_class_specifier_1
/space/rguenther/src/gcc/gcc/cp/parser.c:23838
0xc176d4 cp_parser_class_specifier
/space/rguenther/src/gcc/gcc/cp/parser.c:24212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, mine.

[Bug tree-optimization/95297] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

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-05-25

--- Comment #1 from Richard Biener  ---
Mine.

[Bug c++/95305] Same code takes ~1/4 to 1/7th the time to compile under clang++.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95305

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Richard Biener  ---
Can you attach a "representativ" (maybe the worst?) compilation unit in
preprocessed form?

[Bug tree-optimization/95308] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
(gdb) p debug_generic_expr (addr)
&MEM[symbol: a, index: ivtmp.36_228, step: 4, offset: 0B]

so we're propagating the address of a TMR.  In this case we have an
outer MEM_REF with zero offset so we can canonicalize this to sth valid.
Want to check where this comes from though.

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95309

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |ASSIGNED

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276

--- Comment #9 from Thomas Koenig  ---
So, two bugs, as far as I can see: One in libgfortran, which was warned about.
I will check if this is actually valid, maybe the automated test case reduction
went too far.

The second one about the apparent use of uninitialized memory for the warning.

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[luoxhu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053

--- Comment #6 from luoxhu at gcc dot gnu.org ---
"-O2 -ftree-slp-vectorize" could also generate the expected simple fmrs.

Reason is pass_cselim will transform conditional stores into unconditional ones
with PHI instructions when vectorization and if-conversion is
enabled(gcc/tree-ssa-phiopt.c:2482).

pr70053.c.108t.cdce:
D256_add_finite (_Decimal128 a, _Decimal128 b, _Decimal128 c)
{
  struct TDx2_t D.2914;

   [local count: 1073741824]:
  if (b_4(D) == c_5(D))
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072224]:
  D.2914.td0 = c_5(D);
  D.2914.td1 = c_5(D);
  goto ; [100.00%]

   [local count: 708669601]:
  D.2914.td0 = a_3(D);
  D.2914.td1 = b_4(D);

   [local count: 1073741824]:
  return D.2914;

}

=> pr70053.c.109t.cselim:

D256_add_finite (_Decimal128 a, _Decimal128 b, _Decimal128 c)
{
  struct TDx2_t D.2914;
  _Decimal128 cstore_10;
  _Decimal128 cstore_11;

   [local count: 1073741824]:
  if (b_4(D) == c_5(D))
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669601]:

   [local count: 1073741824]:
  # cstore_10 = PHI 
  # cstore_11 = PHI 
  D.2914.td1 = cstore_11;
  D.2914.td0 = cstore_10;
  return D.2914;

}

Then at expand pass, the PHI instruction "cstore_10 = PHI " will be expanded to move for "-O2 -ftree-slp-vectorize". If no such
PHI generated, bb3 and bb4 in pr70053.c.108t.cdce will be expanded to
STORE/LOAD with TD->DI conversion, causing a lot st/ld conversion finally.

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295

--- Comment #2 from Richard Biener  ---
*** Bug 95283 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/95283] ICE: in hoist_memory_references, at tree-ssa-loop-im.c:2607

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95283

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Richard Biener  ---
The reason this ICEs is the same as for PR95295 and its fix fixes this one as
well.

*** This bug has been marked as a duplicate of bug 95295 ***

[Bug sanitizer/95275] Possible performance regression in libasan with detect_stack_use_after_return=1

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95275

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Martin Liška  ---
Thanks for the report.
I bet it's duplicate of PR94910.

*** This bug has been marked as a duplicate of bug 94910 ***

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910

Martin Liška  changed:

   What|Removed |Added

 CC||frantisek at sumsal dot cz

--- Comment #10 from Martin Liška  ---
*** Bug 95275 has been marked as a duplicate of this bug. ***

[Bug c++/95310] New: [concepts] Unrelated template parameters printed in diagnostic

[ensadc at mailnesia dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95310

Bug ID: 95310
   Summary: [concepts] Unrelated template parameters printed in
diagnostic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
CC: asutton at gcc dot gnu.org
  Target Milestone: ---

https://godbolt.org/z/M8CVwc


template 
using iter_reference_t = decltype(*T{});

template 
struct result {
  using type = iter_reference_t;
};

template 
concept indirectly_writable = requires(Out&& o, T&& t) {
  iter_reference_t(*o) = 0;
};
static_assert(indirectly_writable);


:13:15: error: static assertion failed
   13 | static_assert(indirectly_writable);
  |   ^
:13:15: note: constraints not satisfied
:10:9:   required by the constraints of 'template
concept indirectly_writable'
:10:31:   in requirements with 'Out&& o', 'T&& t' [with F = const int*;
T = int&; Out = const int*]
:11:29: note: the required expression 'decltype(*{})(*o)=0' is invalid
   11 |   iter_reference_t(*o) = 0;
  |   ~~^~~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail


Note "[with F = const int*; T = int&; Out = const int*]". The 'F = const int*;'
part is spurious.

When the template parameter of `result` has the same name as the parameter of
the concept (which is the case I originally encountered), the output can be
quite confusing.

The expression 'decltype(*{})(*o)=0' also seems wrong.

Might be related to bug 94862.

[Bug tree-optimization/95308] [10/11 Regression] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512 since r10-4203-g97c146036750e7cb

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0
Summary|ICE: in |[10/11 Regression] ICE: in
   |maybe_canonicalize_mem_ref_ |maybe_canonicalize_mem_ref_
   |addr with -O3   |addr with -O3
   |-march=skylake-avx512   |-march=skylake-avx512 since
   ||r10-4203-g97c146036750e7cb
 CC||avieira at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||9.3.0

--- Comment #3 from Martin Liška  ---
Using --param=vect-epilogues-nomask=1 it started with
r10-4203-g97c146036750e7cb.

[Bug tree-optimization/95297] ICE: Segmentation fault

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Same can be seen for:
gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vshift-5.c -mavx512vnni
-O3

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95311

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25

[Bug c++/95311] New: [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95311

Bug ID: 95311
   Summary: [11 Regression] ICE in
cp_ubsan_maybe_instrument_member_call at
gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

I see the following ICE:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr63470.C
-fsanitize=undefined -c
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr63470.C: In member
function ‘virtual bool FTjackSupport::m_fn1()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr63470.C:45:1: internal
compiler error: tree check: expected class ‘expression’, have ‘declaration’
(parm_decl) in tree_operand_check, at tree.h:3794
   45 | }
  | ^
0x848120 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9736
0x6408d7 expr_check(tree_node*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3465
0x6408d7 tree_operand_check(tree_node*, int, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3794
0x6408d7 cp_ubsan_maybe_instrument_member_call(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/cp-ubsan.c:136
0x9a4633 cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1713
0x138d083 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11956
0x138d948 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:12286
0x138d948 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:12286
0x9a559a cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1785
0x138d083 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11956
0x9a5da2 cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1455
0x138d083 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11956
0x9a3498 cp_genericize_tree
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1820
0x9a3724 cp_genericize(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1969
0x9e5111 finish_function(bool)
/home/marxin/Programming/gcc/gcc/cp/decl.c:17192
0xa9122a cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:29015
0xa92001 cp_parser_function_definition_from_specifiers_and_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:28928
0xa92001 cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:20685
0xa71253 cp_parser_simple_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:13749
0xa99f47 cp_parser_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:13448
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/95272] ice in vectorizable_reduction, at tree-vect-loop.c:6197 since r11-564-g79f0451c67e8ed56

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95272

--- Comment #2 from Richard Biener  ---
static void
vect_slp_rearrange_stmts (slp_tree node, unsigned int group_size,
  vec permutation,
  hash_set &visited)
{ 
...
  /* ???  Computation nodes are isomorphic and need no rearrangement.
 This is a quick hack to cover those where rearrangement breaks
 semantics because only the first stmt is guaranteed to have the
 correct operation code due to others being swapped or inverted.  */
  stmt_vec_info first = SLP_TREE_SCALAR_STMTS (node)[0];
  if (is_gimple_assign (first->stmt)
  && gimple_assign_rhs_code (first->stmt) == COND_EXPR)
return;

bites back.  This leaves us with an inconsistent SLP tree (harmless before
the change exposing the ICE).

[Bug c++/95292] ICE in expand_expr_real_2, at expr.c:8538

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95292

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|internal compiler error |ICE in expand_expr_real_2,
   ||at expr.c:8538
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25

--- Comment #1 from Martin Liška  ---
Started to ICE with r7-3808-g14a2c9aac04f0132.
Is it a valid code?

[Bug tree-optimization/95297] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

--- Comment #3 from Richard Biener  ---
w/o C++ headers:

extern bool var_10;
extern int var_16;
extern short var_17;
extern long var_18;
extern int arr_3[][13];

int min(const int &a, const int &b)
{
  return a < b ? a : b;
}

void test() {
for (short a = 0; a < 010; a++)
  for (char b = 0; b < 012; b++)
arr_3[a][b] = min(-var_10, 0) + 2147483647 >> var_10;
var_16 = (bool)4;
var_17 = 0;
var_18 = -1594153176;
}

[Bug c++/95291] ICE

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started when -std=c++2a was added r8-3237-g026a79f70cf33f83.

[Bug tree-optimization/95284] ICE: verify_gimple failed

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95284

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:f73f8bab9f2474f175cc5ca5ba8ebb32808a4cae

commit r11-605-gf73f8bab9f2474f175cc5ca5ba8ebb32808a4cae
Author: Richard Biener 
Date:   Mon May 25 09:17:51 2020 +0200

tree-optimization/95284 - amend previous store commoning fix

Generalize check for clobbers.

2020-05-25  Richard Biener  

PR tree-optimization/95284
* tree-ssa-sink.c (sink_common_stores_to_bb): Amend previous
fix.

* g++.dg/torture/pr95284.C: New testcase.

[Bug tree-optimization/95297] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

--- Comment #4 from Richard Biener  ---
OK, so here we're using a scalar shift arg - this is also not reflected in the
SLP tree.  Ideally we'd add a vect_scalar_def for this.

[Bug tree-optimization/95284] ICE: verify_gimple failed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95284

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/95290] ice in useless_type_conversion_p

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95290

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Richard Biener  ---
Same reason/fix as PR95297.

*** This bug has been marked as a duplicate of bug 95297 ***

[Bug tree-optimization/95297] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #5 from Richard Biener  ---
*** Bug 95290 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/95273] [11 regression] many ICEs after r11-564

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95273

--- Comment #3 from Richard Biener  ---
I'll first see what remains fixing the rest of the fallout from the rev.

[Bug tree-optimization/95281] ICE: in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95281

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Richard Biener  ---
Another duplicate.

*** This bug has been marked as a duplicate of bug 95295 ***

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295

--- Comment #3 from Richard Biener  ---
*** Bug 95281 has been marked as a duplicate of this bug. ***

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jakub Jelinek  ---
There is nothing wrong on addition of -1, whether signed or cast to
size_t/uintptr_t, to a pointer, so if clang diagnoses that, it is buggy.
When the pointer points to start of some object, the addition of -1 can be
wrong, sure, but that isn't something in the testcase you've posted, there is
nothing to argue about it because you've used a constant, nor could be e.g. if
the pointer is initialized in some other function etc.  That isn't something
the undefined behavior sanitizer can diagnose, for that something needs to
track the object boundaries at runtime (like e.g. -fsanitize=address does).

typedef __SIZE_TYPE__ size_t;

char *
foo (char *p)
{
  size_t s = -1;
  return p + s;
}

int
main ()
{
  char buf[12] = "abcdefghijk";
  char *p = foo (p + 1);
  if (p != &buf[0])
__builtin_abort ();
  return 0;
}
seems to confirm clang is buggy, or at least the sanitizer mode they are using
here checks something beyond what the standard requires, because this testcase
is just fine.

[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[luoxhu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #7 from luoxhu at gcc dot gnu.org ---
When expanding "D.2914.td0 = c_5(D);" in expand_assignment (to=, from=, nontemporal=false) at
../../gcc-master/gcc/expr.c:5058

1) expr.c:5158:   to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);

gdb pr to_rtx
(mem/c:BLK (reg/f:DI 112 virtual-stack-vars) [2 D.2914+0 S32 A128])

...

2) expr.c:5167:   to_rtx = adjust_address (to_rtx, mode1, 0);

p mode1
$86 = E_TDmode
(gdb) pr to_rtx
(mem/c:TD (reg/f:DI 112 virtual-stack-vars) [2 D.2914+0 S16 A128])

to_rtx is generated with address conversion from DImode to TDmode here.

...

3) expr.c:5374:   result = store_field (to_rtx, bitsize,
bitpos,bitregion_start, bitregion_end, mode1, from, get_alias_set (to),
nontemporal, reversep);

then the assignment instruction is generated as below:

(insn 11 10 12 4 (set (mem/c:TD (reg/f:DI 112 virtual-stack-vars) [1
D.2914.td0+0 S16 A128]) (reg/v:TD 121 [ c ])) "pr70053.c":20:14 -1 (nil))


So if we need remove the redundant store/load in expand, the conversion from
DImode to TDmode should be avoided for this case when using virtual-stack-vars
registers. (For PR65421, there are similar DImode to DFmode conversion). 

pr70053.c.236r.expand with -O2:
1: NOTE_INSN_DELETED
6: NOTE_INSN_BASIC_BLOCK 2
2: r119:TD=%2:TD
3: r120:TD=%4:TD
4: r121:TD=%6:TD
5: NOTE_INSN_FUNCTION_BEG
8: r122:CCFP=cmp(r120:TD,r121:TD)
9: pc={(r122:CCFP!=0)?L16:pc}
  REG_BR_PROB 708669604
   10: NOTE_INSN_BASIC_BLOCK 4
   11: [r112:DI]=r121:TD
   12: r123:DI=r112:DI+0x10
   13: [r123:DI]=r121:TD
   14: pc=L21
   15: barrier
   16: L16:
   17: NOTE_INSN_BASIC_BLOCK 5
   18: [r112:DI]=r119:TD
   19: r124:DI=r112:DI+0x10
   20: [r124:DI]=r120:TD
   21: L21:
   22: NOTE_INSN_BASIC_BLOCK 6
   23: r125:TD=[r112:DI]
   24: r127:DI=r112:DI+0x10
   25: r126:TD=[r127:DI]
   26: r117:TD=r125:TD
   27: r118:TD=r126:TD
   31: %2:TD=r117:TD
   32: %4:TD=r118:TD
   33: use %2:TD
   34: use %4:TD

[Bug c/95312] New: Missing quoting of format directives emitted by -Wformat

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95312

Bug ID: 95312
   Summary: Missing quoting of format directives emitted by
-Wformat
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

All gcc since 4.6, where -Wformat was initially introduced, emit the following
when compiling snippets like that w/ -Wformat:

#include 

int
foo (FILE *f, char *s)
{
  return fscanf (f, "%c%[^\n\n]", s);
}

% gcc-11.0.0 -fsyntax-only -Wformat -c po6k6b4n.c
po6k6b4n.c: In function 'foo':
po6k6b4n.c:6:29: warning: format '%[^

   ' expects a matching 'char *' argument [-Wformat=]
6 |   return fscanf (f, "%c%[^\n\n]", s);
  |~^~
  | |
  | char *

It seems wrong to me that the format directive is not quoted in the warning
text.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[andrey.vihrov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #5 from Andrey Vihrov  ---
Assuming that there indeed is no object at address 0x406310, wouldn't 6.5.6.8
from the C11 standard apply?

> [...] If both the pointer operand and the result point to elements of the same
> array object, or one past the last element of the array object, the evaluation
> shall not produce an overflow; otherwise, the behavior is undefined.

[Bug c/95312] Missing quoting of format directives emitted by -Wformat

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95312

--- Comment #1 from Arseny Solokha  ---
(In reply to Arseny Solokha from comment #0)
> All gcc since 4.6, where -Wformat was initially introduced

(Well, it of course was introduced much earlier, but since that release it
started emitting verbose diagnostics instead of "too few arguments for
format".)

[Bug c++/95307] Compiler accepts reinterpret_cast in constexpr

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307

--- Comment #2 from Jakub Jelinek  ---
For - 0 it is diagnosed by:
  /* Technically we should check this for all subexpressions, but that
 runs into problems with our internal representation of pointer
 subtraction and the 5.19 rules are still in flux.  */
  if (CONVERT_EXPR_CODE_P (TREE_CODE (r))
  && ARITHMETIC_TYPE_P (TREE_TYPE (r))
  && TREE_CODE (TREE_OPERAND (r, 0)) == ADDR_EXPR)
{
  if (!allow_non_constant)
error ("conversion from pointer type %qT "
   "to arithmetic type %qT in a constant expression",
   TREE_TYPE (TREE_OPERAND (r, 0)), TREE_TYPE (r));
  non_constant_p = true;
}
and what matters is what the comment says, we really should be checking it for
subexpressions (therefore move into cxx_eval_constant_expression in
NOP_EXPR/CONVERT_EXPR case).
We have POINTER_DIFF_EXPR now so one would hope we don't run into the issues
mentioned there.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #6 from Jakub Jelinek  ---
How would you know if there is or isn't an object at that those addresses?

Sure, if you in #c4 change p + 1 into p, then it is undefined behavior, but as
I said, UndefinedBehaviorSanitizer has no way to detect that, as doesn't track
the object boundaries etc.
AddressSanitizer (to some extent) does, but it will only complain if one either
dereferences such a pointer, or with
-fsanitize=address,pointer-compare,pointer-subtract can complain about pointer
(non-equality) comparisons or pointer subtractions where the two pointers
provably don't belong to the same object.
In theory one could add similar pointer-arithmetics sanitizer that would use
the asan infrastructure, though I must say it would be very expensive (at
runtime).

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[frantisek at sumsal dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #7 from Frantisek Sumsal  ---
Maybe I'm missing something here, but isn't detecting pointer overflows (even
in cases where it's apparently not an undefined behavior) the sole purpose of
-fsanitize=pointer-overflow (which, to my knowledge, is enabled by default when
using -fsanitize=undefined)?

As described in [0]:
-fsanitize=pointer-overflow

This option enables instrumentation of pointer arithmetics. If the pointer
arithmetics overflows, a run-time error is issued.


[0] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #8 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #4)
> There is nothing wrong on addition of -1, whether signed or cast to
> size_t/uintptr_t, to a pointer,

Looking at the standard (I am not a pro at that), one could easily interpret
that p+(size_t)(-1) means adding a huge number to p, not subtracting 1. It does
not say that the integer is cast to ptrdiff_t or anything like that.

[Bug tree-optimization/95308] [10 Regression] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512 since r10-4203-g97c146036750e7cb

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
  Known to fail|11.0|
   Priority|P3  |P2
Summary|[10/11 Regression] ICE: in  |[10 Regression] ICE: in
   |maybe_canonicalize_mem_ref_ |maybe_canonicalize_mem_ref_
   |addr with -O3   |addr with -O3
   |-march=skylake-avx512 since |-march=skylake-avx512 since
   |r10-4203-g97c146036750e7cb  |r10-4203-g97c146036750e7cb
   Target Milestone|--- |10.2

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/95308] [10/11 Regression] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512 since r10-4203-g97c146036750e7cb

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:a0c623f58198d3c8f767a181574537720386b468

commit r11-606-ga0c623f58198d3c8f767a181574537720386b468
Author: Richard Biener 
Date:   Mon May 25 09:44:50 2020 +0200

tree-optimization/95308 - really avoid forward propagating of &TMR

This fixes a hole that still allowed forwarding of TARGET_MEM_REF
addresses.

2020-05-25  Richard Biener  

PR tree-optimization/95308
* tree-ssa-forwprop.c (pass_forwprop::execute): Generalize
test for TARGET_MEM_REFs.

* g++.dg/torture/pr95308.C: New testcase.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #9 from Jakub Jelinek  ---
(In reply to Frantisek Sumsal from comment #7)
> Maybe I'm missing something here, but isn't detecting pointer overflows
> (even in cases where it's apparently not an undefined behavior) the sole
> purpose of -fsanitize=pointer-overflow (which, to my knowledge, is enabled
> by default when using -fsanitize=undefined)?
> 
> As described in [0]:
> -fsanitize=pointer-overflow
> 
> This option enables instrumentation of pointer arithmetics. If the
> pointer arithmetics overflows, a run-time error is issued.
> 
> 
> [0] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

pointer-overflow is a cheap check without any context, for ptr + off
it will do
uintptr_t res = (uintptr_t) ptr + off;
if (((intptr_t) res) < 0 ? res > (uintptr_t) ptr : res < (uintptr_t) ptr)
runtime_diagnostics ();
and nothing else.
clang is wrong to assume that ptr + (size_t) -1 is standard-wise or
behavior-wise any different from ptr + (-1).
Oh, in #c4 I've made a mistake, obviously it should be buf + 1 rather than p +
1.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #10 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #8)
> (In reply to Jakub Jelinek from comment #4)
> > There is nothing wrong on addition of -1, whether signed or cast to
> > size_t/uintptr_t, to a pointer,
> 
> Looking at the standard (I am not a pro at that), one could easily interpret
> that p+(size_t)(-1) means adding a huge number to p, not subtracting 1. It
> does not say that the integer is cast to ptrdiff_t or anything like that.

I don't read it that way.
Let's use e.g. the C++ wording:
"Otherwise, if P points to an array element i of an array object x with n
elements, the expressions P + J and J + P (where J has the value j) point to
the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the
expression P - J points to the (possibly-hypothetical) array element i−j of x
if 0≤i−j≤n.
In the (#c4 testcase with the s/p + 1/buf + 1/ fix), i is 1, and j is either
-1 or (size_t) -1.  For both, 1 + -1 or 1 + (size_t) -1 give 0 and thus the
pointer addition is well defined and points to the first element of the object.

[Bug tree-optimization/95271] ice in vect_get_constant_vectors, at tree-vect-slp.c:3638 since r11-564-g79f0451c67e8ed56

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95271

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:c0e27f72358794692e367363940c6383e9ad1e45

commit r11-608-gc0e27f72358794692e367363940c6383e9ad1e45
Author: Richard Biener 
Date:   Mon May 25 10:36:39 2020 +0200

tree-optimization/95271 - fix bswap vectorization invariant SLP type

This properly updates invariant SLP nodes vector types for bswap
vectorization.

2020-05-25  Richard Biener  

PR tree-optimization/95271
* tree-vect-stmts.c (vectorizable_bswap): Update invariant SLP
children vector type.
(vectorizable_call): Pass down slp ops.

* gcc.dg/vect/bb-slp-pr95271.c: New testcase.

[Bug tree-optimization/95297] ICE: Segmentation fault

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:d31694544d2d805151899ab0a0bc654767035ad6

commit r11-607-gd31694544d2d805151899ab0a0bc654767035ad6
Author: Richard Biener 
Date:   Mon May 25 11:14:03 2020 +0200

tree-optimization/95297 - handle scalar shift arg for SLP invariant vectype

This skips invariant vector type setting for a scalar shift argument.

2020-05-25  Richard Biener  

PR tree-optimization/95297
* tree-vect-stmts.c (vectorizable_shift): For scalar_shift_arg
skip updating operand 1 vector type.

* g++.dg/vect/pr95297.cc: New testcase.
* g++.dg/vect/pr95290.cc: Likewise.

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95309

--- Comment #1 from Richard Biener  ---
So SLP vectorization decides to vectorize the SImode stores with V1SImode
vector stores because the cited revision does not cost the constant as
SLP_TREE_NUMBER_OF_VEC_STMTS is zero for it.  That's because this wasn't
adjusted when changing what SLP node we pass in and we've never computed
SLP_TREE_NUMBER_OF_VEC_STMTS for invariants sofar.

[Bug tree-optimization/95297] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95297

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/95271] ice in vect_get_constant_vectors, at tree-vect-slp.c:3638 since r11-564-g79f0451c67e8ed56

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95271

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95311

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95211

--- Comment #4 from Jakub Jelinek  ---
Adjusted testcase, so that there is no UB.

void bar (void);

void
foo (long int *x, int y, int *z, int v)
{
  int a[y];
  int b;
  for (b = 0; b < 3; ++b)
z[b] = x[b] + 1.0f;
  if (v)
return;
  bar ();
}

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95211

--- Comment #5 from Uroš Bizjak  ---
This testcase is fixed by [1]

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546408.html

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #9)
> pointer-overflow is a cheap check without any context, for ptr + off
> it will do
> uintptr_t res = (uintptr_t) ptr + off;
> if (((intptr_t) res) < 0 ? res > (uintptr_t) ptr : res < (uintptr_t) ptr)
> runtime_diagnostics ();

Mistyped, (intptr_t) off rather than (intptr_t) res obviously.

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:4acca1c0635dfa43cd8c4bfe2b22e17909fc23a3

commit r11-609-g4acca1c0635dfa43cd8c4bfe2b22e17909fc23a3
Author: Richard Biener 
Date:   Mon May 25 10:09:44 2020 +0200

tree-optimization/95295 - fix wrong-code with SM

We failed to compare the rematerialized store values when merging
paths after walking PHIs.

2020-05-25  Richard Biener  

PR tree-optimization/95295
* tree-ssa-loop-im.c (sm_seq_valid_bb): Compare remat stores
RHSes and drop to full sm_other if they are not equal.

* gcc.dg/torture/pr95295-1.c: New testcase.
* gcc.dg/torture/pr95295-2.c: Likewise.
* gcc.dg/torture/pr95283.c: Likewise.

[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/95308] [10 Regression] ICE: in maybe_canonicalize_mem_ref_addr with -O3 -march=skylake-avx512 since r10-4203-g97c146036750e7cb

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95308

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:67bfbda18f4e6d0d30ad8f8790f1d0d4653131ed

commit r11-610-g67bfbda18f4e6d0d30ad8f8790f1d0d4653131ed
Author: Richard Biener 
Date:   Mon May 25 13:48:57 2020 +0200

tree-optimization/95308 - really avoid forward propagating of &TMR

This fixes a hole that still allowed forwarding of TARGET_MEM_REF
addresses.

2020-05-25  Richard Biener  

PR tree-optimization/95308
* tree-ssa-forwprop.c (pass_forwprop::execute): Generalize
test for TARGET_MEM_REFs.

* g++.dg/torture/pr95308.C: New testcase.

[Bug middle-end/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
  Component|libgomp |middle-end

--- Comment #1 from Jakub Jelinek  ---
The testcase is not valid, target construct accepts both map and firstprivate
clauses and specifying both mapping and data-sharing for the same list item is
invalid, you need to choose one.

[Bug libfortran/95313] New: Possible overflow in itoa_buf

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95313

Bug ID: 95313
   Summary: Possible overflow in itoa_buf
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

For gcc 10 and 11, a possible overflow in itoa_buf is detected. The error
message is strange, see PR 95276 . This is about the buffer overflow
itself.

[Bug middle-end/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[john.donners at atos dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163

--- Comment #2 from John Donners  ---
hmm, indeed I found the applicable text in the standard (2.14) as well:
"The effect of the firstprivate clause is as if it is applied to one or more
constructs as follows: To the target construct if it is among the constituent
constructs and the same list item does not appear in a lastprivate or map
clause."

Apologies for the invalid code. Splitting the two works without problems.

[Bug middle-end/95276] [10/11 Regression] Amusing stringpop-overflow message building libgfortran

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95276

--- Comment #10 from Thomas Koenig  ---
The libgfortran bug is now PR 95313 .

[Bug fortran/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
  Component|middle-end  |fortran

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
  integer :: i
  i = 1
!$omp target map(tofrom: i) firstprivate (i)
  i = i + 1
!$omp end target
end
For C/C++,
void
foo (int i)
{
#pragma omp target map(tofrom: i) firstprivate (i)
  i++;
}

void
bar (int i)
{
#pragma omp target firstprivate (i) map(tofrom: i)
  i++;
}
is rejected already in the FE, so I think we just miss rejecting it in the
Fortran FE.

[Bug fortran/95163] [8/9/10/11 Regression] ICE in gimplify_adjust_omp_clauses, at gimplify.c:10440 since r7-4447-gb4c3a85be9658537

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95163

--- Comment #4 from Tobias Burnus  ---
Likewise crashing is:
  !$omp target map(tofrom: i) map(i)

[Bug jit/95314] New: Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[bouanto at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

Bug ID: 95314
   Summary: Sharing a local reference to a global variable in
multiple functions results in location references
block not in block tree
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
If a create, in a function, a reference (with gcc_jit_lvalue_get_address) to a
global and reuse this local reference in another function, it gives the
following error:

libgccjit.so: error: location references block not in block tree
…
during IPA pass: *free_lang_data
libgccjit.so: error: verify_gimple failed
0x7f83924b35c9 verify_gimple_in_cfg(function*, bool)
../../gcc-10.1.0/gcc/tree-cfg.c:5462
0x7f839236a819 execute_function_todo
../../gcc-10.1.0/gcc/passes.c:1985
0x7f839236add7 do_per_function
../../gcc-10.1.0/gcc/passes.c:1647
0x7f839236b06b do_per_function
../../gcc-10.1.0/gcc/passes.c:2050
0x7f839236b06b execute_todo
../../gcc-10.1.0/gcc/passes.c:2039

I can try to make an example to reproduce this issue if needed.

Is that the expected behavior or should libgccjit gives a proper error?

(Recreating the reference in every function fix this issue.)

Thanks.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

--- Comment #1 from David Malcolm  ---
Thanks for reporting it; this sounds like a bug.

Please can you use attach a reproducer (e.g. using
gcc_jit_context_dump_reproducer_to_file).

Looking at the backtrace, it looks like a bad interaction with inlining, FWIW.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

--- Comment #12 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #10)
> 1 + (size_t) -1 give 0

It wasn't obvious to me that the operation was supposed to happen in some C/C++
type (they don't say which one) or in a mathematical, infinite-precision sense.
After all, they write 0≤i−j≤n which shouldn't be interpreted as C++ code. But
you have more experience with reading these things, I believe you.

[Bug sanitizer/95279] UBSan doesn't seem to detect pointer overflow in certain cases

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Paging language experts.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Generally, most of the trees (with some exceptions) aren't shareable and
shouldn't be used by multiple different functions.  During gimplifications the
function body is unshared, but not sure what the JIT FE does exactly.

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95309

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:dc0c0196340f7ac58b10d0042d7cea776d6f7864

commit r11-615-gdc0c0196340f7ac58b10d0042d7cea776d6f7864
Author: Richard Biener 
Date:   Mon May 25 13:06:03 2020 +0200

tree-optimization/95309 - fix invariant SLP node costing

This makes sure to compute SLP_TREE_NUMBER_OF_VEC_STMTS during SLP
analysis even for invariant / external nodes so costing properly
knows what to cost.

2020-05-25  Richard Biener  

PR tree-optimization/95309
* tree-vect-slp.c (vect_get_constant_vectors): Move number
of vector computation ...
(vect_slp_analyze_node_operations): ... to analysis phase.

[Bug middle-end/95309] [11 Regression] Many targets failing ssa-dom-cse-2.c after vectorizer changes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95309

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed (on ip2000-elf).

[Bug target/95266] [11 regression] gcc.dg/vect/bb-slp-pr69907.c fails on power 7

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95266

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Richard Biener  ---
Dup.

*** This bug has been marked as a duplicate of bug 95058 ***

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95058

--- Comment #7 from Richard Biener  ---
*** Bug 95266 has been marked as a duplicate of this bug. ***

[Bug target/95261] [11 regression] gcc.target/powerpc/pr80695-p8.c and gcc.target/powerpc/pr80695-p9.c fail starting with r11-478

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95261

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Richard Biener  ---
g:dc0c0196340f7ac58b10d0042d7cea776d6f7864 might have fixed this, can you
verify?

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95058

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #8 from Richard Biener  ---
Can you check if the FAILs still occur after
g:dc0c0196340f7ac58b10d0042d7cea776d6f7864

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

--- Comment #3 from David Malcolm  ---
Thanks Jakub, that sounds like the problem: I'm creating a tree per
playback::rvalue (m_inner), and I need to unshare them.

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

--- Comment #4 from Jakub Jelinek  ---
unshare_expr can handle that.

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95197

--- Comment #1 from Jakub Jelinek  ---
For e.g.
void bar (I &a);

void
foo (I &a)
{
  #pragma omp task //firstprivate (a)
  bar (a);
}
with the same templates this is handled by omp_cxx_notice_variable, which will
1068  get_copy_ctor (type, tf_none);
1069  get_dtor (type, tf_none);
because when it is done only during gimplification, we don't instantiate it
anymore.
So, I think I need to go through all the lang_hooks.decls.omp_finish_clause
calls in the gimplifier and deal with it similarly during genericization time.

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95197

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:

// { dg-do link }

typedef __PTRDIFF_TYPE__ ptrdiff_t;

template 
class I
{
public:
  typedef ptrdiff_t difference_type;
  I ();
  ~I ();
  I (T *);
  I (const I &);
  T &operator * ();
  T *operator -> ();
  T &operator [] (const difference_type &) const;
  I &operator = (const I &);
  I &operator ++ ();
  I operator ++ (int);
  I &operator -- ();
  I operator -- (int);
  I &operator += (const difference_type &);
  I &operator -= (const difference_type &);
  I operator + (const difference_type &) const;
  I operator - (const difference_type &) const;
  template  friend bool operator == (I &, I &);
  template  friend bool operator == (const I &, const I &);
  template  friend bool operator < (I &, I &);
  template  friend bool operator < (const I &, const I &);
  template  friend bool operator <= (I &, I &);
  template  friend bool operator <= (const I &, const I &);
  template  friend bool operator > (I &, I &);
  template  friend bool operator > (const I &, const I &);
  template  friend bool operator >= (I &, I &);
  template  friend bool operator >= (const I &, const I &);
  template  friend typename I::difference_type operator - (I
&, I &);
  template  friend typename I::difference_type operator - (const
I &, const I &);
  template  friend I operator + (typename I::difference_type
, const I &);
private:
  T *p;
};
template  I::I () : p (0) {}
template  I::~I () {}
template  I::I (T *x) : p (x) {}
template  I::I (const I &x) : p (x.p) {}
template  T &I::operator * () { return *p; }
template  T *I::operator -> () { return p; }
template  T &I::operator [] (const difference_type &x) const {
return p[x]; }
template  I &I::operator = (const I &x) { p = x.p; return
*this; }
template  I &I::operator ++ () { ++p; return *this; }
template  I I::operator ++ (int) { return I (p++); }
template  I &I::operator -- () { --p; return *this; }
template  I I::operator -- (int) { return I (p--); }
template  I &I::operator += (const difference_type &x) { p +=
x; return *this; }
template  I &I::operator -= (const difference_type &x) { p -=
x; return *this; }
template  I I::operator + (const difference_type &x) const {
return I (p + x); }
template  I I::operator - (const difference_type &x) const {
return I (p - x); }
template  bool operator == (I &x, I &y) { return x.p == y.p;
}
template  bool operator == (const I &x, const I &y) { return
x.p == y.p; }
template  bool operator != (I &x, I &y) { return !(x == y); }
template  bool operator != (const I &x, const I &y) { return
!(x == y); }
template  bool operator < (I &x, I &y) { return x.p < y.p; }
template  bool operator < (const I &x, const I &y) { return
x.p < y.p; }
template  bool operator <= (I &x, I &y) { return x.p <= y.p;
}
template  bool operator <= (const I &x, const I &y) { return
x.p <= y.p; }
template  bool operator > (I &x, I &y) { return x.p > y.p; }
template  bool operator > (const I &x, const I &y) { return
x.p > y.p; }
template  bool operator >= (I &x, I &y) { return x.p >= y.p;
}
template  bool operator >= (const I &x, const I &y) { return
x.p >= y.p; }
template  typename I::difference_type operator - (I &x, I
&y) { return x.p - y.p; }
template  typename I::difference_type operator - (const I &x,
const I &y) { return x.p - y.p; }
template  I operator + (typename I::difference_type x, const
I &y) { return I (x + y.p); }

void
bar (I &a)
{
}

void
foo (const I &a, const I &b)
{
  I i;
  #pragma omp distribute parallel for
  for (i = a; i < b; i++)
bar (i);
}

int
main ()
{
  int a[64];
  foo (&a[0], &a[63]);
}

[Bug middle-end/95315] New: [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry)

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95315

Bug ID: 95315
   Summary: [11 Regression] ICE: Segmentation fault (in
lookup_page_table_entry)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200524 snapshot (g:d176184d98a00ab379ae5959aed1908a79995e6b)
ICEs when compiling gcc/testsuite/c-c++-common/gomp/declare-variant-5.c w/ -O2
-fopenmp --param ggc-min-heapsize=0:

% gcc-11.0.0 -O2 -fopenmp --param ggc-min-heapsize=0 -c
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c: In function 'test':
gcc/testsuite/c-c++-common/gomp/declare-variant-5.c:36:1: internal compiler
error: Segmentation fault
   36 | }
  | ^
0xd9fcff crash_signal
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/toplev.c:328
0x8af45b lookup_page_table_entry
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-page.c:630
0x8af45b ggc_set_mark(void const*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-page.c:1544
0xb0b331 gt_ggc_mx_symtab_node(void*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/build/gcc/gtype-desc.c:1300
0xc58316 gt_ggc_mx_omp_declare_variant_base_entry(void*)
./gt-omp-general.h:47
0xc58316 gt_ggc_mx_omp_declare_variant_base_entry(void*)
./gt-omp-general.h:41
0xc58316 gt_ggc_mx(omp_declare_variant_base_entry*&)
./gt-omp-general.h:65
0xc55121
ggc_remove::ggc_mx(omp_declare_variant_base_entry*&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/hash-traits.h:237
0xc55121
ggc_remove::ggc_maybe_mx(omp_declare_variant_base_entry*&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/hash-traits.h:244
0xc55121 gt_ggc_mx
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/hash-table.h:1163
0xc55121 gt_ggc_mx_hash_table_omp_declare_variant_alt_hasher_(void*)
./gt-omp-general.h:90
0xc55121 gt_ggc_mx_hash_table_omp_declare_variant_alt_hasher_(void*)
./gt-omp-general.h:85
0xa93055 ggc_mark_root_tab
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-common.c:78
0xa9336c ggc_mark_roots()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-common.c:95
0x8afdc8 ggc_collect()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200524/work/gcc-11-20200524/gcc/ggc-page.c:2220

[Bug middle-end/95315] [11 Regression] ICE: Segmentation fault (in lookup_page_table_entry)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95315

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 CC||jakub at gcc dot gnu.org

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[bouanto at zoho dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

--- Comment #5 from bouanto at zoho dot com ---
The reproducer generates a file where the function create_code only contains
this:

  /* Replay of API calls for ctxt_0x7f8079128680.  */

So, no code is actually generated and thus, does not reproduce this issue.

[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92815

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #9 from Arseny Solokha  ---
Created attachment 48593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48593&action=edit
Diff between assembler output produced by gcc and g++ 11

Though there are no flexible array members in C++, is it expected for g++ to
behave differently w/ this testcase?

While compiling it w/ gcc yeilds the following, which is expected:

% gcc-11.0.0 -c gcc/testsuite/gcc.dg/builtin-object-size-21.c
gcc/testsuite/gcc.dg/builtin-object-size-21.c:29:14: error: size of variable
'xm3_4' is too large
   29 | struct Ax_m3 xm3_4 = { { 0 }, { 1, 2, 3, 3 } };   // { dg-error "too
large" }
  |  ^
gcc/testsuite/gcc.dg/builtin-object-size-21.c:43:14: error: size of variable
'xmx_1' is too large
   43 | struct Ax_mx xmx_1 = { { 0 }, { 1 } };// { dg-error "too
large" }
  |

W/ g++ I have

% g++-11.0.0 -c gcc/testsuite/gcc.dg/builtin-object-size-21.c
/tmp/ccPBumhF.s: Assembler messages:
/tmp/ccPBumhF.s: Fatal error: can't write 14 bytes to section .text of
/tmp/ccj6lymE.o: 'file truncated'
/usr/lib/gcc/x86_64-unknown-linux-gnu/11.0.0/../../../../x86_64-unknown-linux-gnu/bin/as:
BFD (Gentoo 2.34 p4) 2.34.0 assertion fail
/var/tmp/portage/sys-devel/binutils-2.34-r1/work/binutils-2.34/bfd/elf.c:3169
/tmp/ccPBumhF.s: Fatal error: can't close /tmp/ccj6lymE.o: file truncated

because of

[pid 1165642] openat(AT_FDCWD, "builtin-object-size-21.o",
O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
<…>
[pid 1165642] fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 1165642] lseek(3, -9223372036854775808, SEEK_SET) = -1 EINVAL (Invalid
argument)

Or, when writing to an "endless" file w/ -o /dev/null:

[pid 1164514] lseek(3, -9223372036854775808, SEEK_SET) = 0
[pid 1164514] read(3, "", 640)  = 0
[pid 1164514] lseek(3, 640, SEEK_CUR)   = 0
[pid 1164514] write(3, "\0builtin-object-size-21.c\0xm3_0\0"..., 96) = 96
[pid 1164514] lseek(3, 0, SEEK_SET) = 0
[pid 1164514] read(3, "", 4096) = 0
[pid 1164514] lseek(3, 64, SEEK_CUR)= 0
[pid 1164514] write(3, "UH\211\345\220]\303UH\211\345\220]\303", 14) = 14
[pid 1164514] lseek(3, 0, SEEK_SET) = 0
[pid 1164514] read(3, "", 4096) = 0
[pid 1164514] lseek(3, 96, SEEK_CUR)= 0
[pid 1164514] write(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
4096
[pid 1164514] write(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
4096
[pid 1164514] write(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) =
4096

[Bug other/95316] New: [10 Regression] binary built with -fopenacc fails to run when not all offload compilers are installed that were configured

[doko at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95316

Bug ID: 95316
   Summary: [10 Regression] binary built with -fopenacc fails to
run when not all offload compilers are installed that
were configured
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

This is usage regression; in gcc-9 building with

  gcc-9 -o mandel-accel mandel.c -Wall -O2 -fopenacc

and running the mandel-accel binary works, if the nvptx offload compiler is
installed.

Building that with gcc-10 leads to:

$ gcc-10 -o mandel-accel mandel.c -Wall -O3 -fopenacc
lto-wrapper: fatal error: could not find accel/amdgcn-amdhsa/mkoffload in
/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
(consider using ‘-B’)
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed

because gcc-10 was configured with more than one offload target.  Installing
all configured offload compilers works around it, or building for the offload
targets explicitly (-foffload=nvptx-none).

Expected behavior:  Just print a warning when an offload compiler for a target
cannot be found.

Note: the packaged compilers for Debian/Ubuntu are gcc-10, gcc-10-offload-nvptx
and gcc-10-offload-amdgcn.

See https://launchpad.net/bugs/1878760

[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314

--- Comment #6 from David Malcolm  ---
Sorry about that; thanks for trying.  I think I can figure out a reproducer,
and will try tomorrow.

[Bug c++/95317] New: [7 regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317

Bug ID: 95317
   Summary: [7 regression] ICE on valid C++14 code, in
tsubst_copy, at cp/pt.c:15649
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

ICE on valid C++14 code:

$ cat b.C
#include 

template 
struct num
{
enum { value = I };
};

#define VALUEOFNUM(x) std::remove_reference_t::value


template 
void foo()
{
auto test = [&](auto i)
{
enum { VALUE = VALUEOFNUM(i) };
std::cout << VALUE;
};

test(num<0>());
test(num<1>());
}

int main()
{
foo();
}

$ g++-9 b.C 
b.C: In instantiation of 'void foo() [with TYPE = void]':
b.C:27:15:   required from here
b.C:18:22: internal compiler error: in tsubst_copy, at cp/pt.c:15649
   18 | std::cout << VALUE;
  |  ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



Works fine with GCC up to version 6, but regresses at 7 and later.

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318

--- Comment #1 from Brett Neumeier  ---
Created attachment 48594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48594&action=edit
preprocessed source

[Bug bootstrap/95318] New: gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318

Bug ID: 95318
   Summary: gcc 10.1 on x86_64 fails to build aarch64
cross-compiler when using default optimization
settings
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bneumeier at gmail dot com
  Target Milestone: ---

This issue is seen when building an X86_64-to-AArch64 cross-compiler
using GCC 10.1.

`gcc -v` on the host computer reports:
--
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/cbl/cbltools/libexec/gcc/x86_64-pc-linux-gnu/10.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /path/to/gcc-10.1.0/configure
  --prefix=/home/cbl/cbltools --with-local-prefix=/home/cbl/cbltools
  --disable-multilib --disable-nls --enable-shared
  --enable-languages=c,c++ --enable-c99 --enable-long-long
  --enable-threads=posix --with-gmp=/home/cbl/cbltools
  --with-mpfr=/home/cbl/cbltools --with-mpc=/home/cbl/cbltools
  --with-isl=/home/cbl/cbltools
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.1 20200507 (GCC)
--

The cross-compiler build was configured with:

../gcc-10.1.0/configure --prefix=/home/cbl/work/cross-tools
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=aarch64-cbl-linux-gnu --with-sysroot=/home/cbl/work/sysroot
--with-build-sysroot=/home/cbl/work/sysroot --disable-decimal-float
--disable-libgomp --disable-libmudflap --disable-libssp --disable-multilib
--disable-nls --disable-shared --disable-threads --enable-languages=c,c++
--with-newlib --without-headers --with-gmp=/home/cbl/cbltools
--with-mpfr=/home/cbl/cbltools --with-mpc=/home/cbl/cbltools
--with-isl=/home/cbl/cbltools --enable-fix-cortex-a53-835769
--enable-fix-cortex-a53-843419 --with-cpu=cortex-a72.cortex-a53

The issue is encountered after successfully completing the `all-gcc` make
target, and running `make all-target-libgcc`. Compilation of libgcc/unwind-c.c
produces errors:

/home/cbl/work/build/build-gcc-2/./gcc/xgcc
-B/home/cbl/work/build/build-gcc-2/./gcc/
-B/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/bin/
-B/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/lib/ -isystem
/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/include -isystem
/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/sys-include
--sysroot=/home/cbl/work/sysroot   -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -fPIC -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC -I.
-I. -I../.././gcc -I/home/cbl/work/build/gcc-10.1.0/libgcc
-I/home/cbl/work/build/gcc-10.1.0/libgcc/.
-I/home/cbl/work/build/gcc-10.1.0/libgcc/../gcc
-I/home/cbl/work/build/gcc-10.1.0/libgcc/../include  -DHAVE_CC_TLS  -o
unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c
/home/cbl/work/build/gcc-10.1.0/libgcc/unwind-c.c -fvisibility=hidden
-DHIDE_EXPORTS

/tmp/cc3usGId.s: Assembler messages:
/tmp/cc3usGId.s: Error: invalid operands (*ABS* and *GAS `expr' section*
sections) for `*' when setting `.LVU94'
/tmp/cc3usGId.s: Error: can't resolve value for symbol `.LVU94'

If I add the `-fno-align-loops` directive, this avoids the errors.

I'm attaching the preprocessed source `unwind-c.i`, and the compiled
`unwind-c.s` both with `-fno-align-loops` (working) and without (error).

After adding `-fno-align-loops` as a workaround, the cross-compiler build
completes without further issues. However, actually using the resulting
cross-compiler to build a target-native GCC (again, unless -fno-align-loops is
specified) fails with similar error messages on several other files, e.g.:

aarch64-cbl-linux-gnu-g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/home/cbl/work/build/gcc-10.1.0/gcc -I/home/cbl/work/build/gcc-10.1.0/gcc/.
-I/home/cbl/work/build/gcc-10.1.0/gcc/../include
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libcpp/include
-I/home/cbl/work/sysroot/scaffolding/include
-I/home/cbl/work/sysroot/scaffolding/include
-I/home/cbl/work/sysroot/scaffolding/include 
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libdecnumber
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libbacktrace
-I/home/cbl/work/sysroot/scaffolding/include  -o gimple-low.o -MT gimple-low.o
-MMD -MP -MF ./.deps/gimple-low.TPo
/home/cbl/work/build/gcc-10.1.0/gcc/gimple-low.c
/tmp/ccMqyaI0.s: Assemb

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318

--- Comment #2 from Brett Neumeier  ---
Created attachment 48595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48595&action=edit
result of compilation with default settings

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95318

--- Comment #3 from Brett Neumeier  ---
Created attachment 48596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48596&action=edit
result of compilation with -fno-align-loop specified

[Bug c++/95319] New: Regression from gcc9.3 when inserting into a vector with an initializer list. Error: a GNU-style designated initializer for class

[haldormnk at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95319

Bug ID: 95319
   Summary: Regression from gcc9.3 when inserting into a vector
with an initializer list. Error: a GNU-style
designated initializer for class
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haldormnk at hotmail dot com
  Target Milestone: ---

https://godbolt.org/z/zZtP9z

#include 
#include 
#include 
int main() {
using Array = std::array;
using ArrayVector = std::vector;
auto vector = ArrayVector();
vector.emplace_back(Array({1,1,1})); // works
vector.insert(std::end(vector),{{2,2,2}}); // fails in gcc10.1
}

With gcc9.3 it compiles, but with gcc10.1, there is an error in the last line:

error: '[0] =' used in a GNU-style designated initializer for class
'std::array'

[Bug ipa/95320] New: [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320

Bug ID: 95320
   Summary: [11 Regression] ICE in odr_type_p, at ipa-utils.h:246,
during IPA pass: pure-const
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

For some reason, this only occurs when compiling for AMDGCN and it seems to be
a recent regression.

The issue seems to affect nearly all testcases in libgomp, I get 2500+ FAIL.

For instance
  gcc -fopenmp libgomp/testsuite/libgomp.c-c++-common/for-11.c
fails as:

during IPA pass: fnsummary
src/gcc-mainline/libgomp/testsuite/libgomp.c-c++-common/for-11.c:5: internal
compiler error: in odr_type_p, at ipa-utils.h:246
0x8b3ccf odr_type_p(tree_node const*)
gcc-mainline/gcc/ipa-utils.h:246
0x8b3ccf local_tree_p
gcc-mainline/gcc/lto-streamer-out.c:594
0x8b3ccf DFS::DFS(output_block*, tree_node*, bool, bool, bool)
gcc-mainline/gcc/lto-streamer-out.c:639


Breakpoint 1, DFS::DFS(output_block*, tree_node*, bool, bool, bool) () at
gcc-mainline/gcc/lto-streamer-out.c:639
639   if (ob->local_trees && local_tree_p (expr))
(gdb) p ob
$1 = 
(gdb) p expr
$2 = (tree) 0x7734ac78
(gdb) p debug_tree(expr)
 

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95197

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25

--- Comment #3 from Jakub Jelinek  ---
Created attachment 48597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48597&action=edit
gcc11-pr95197.patch

Untested fix.

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320

Tobias Burnus  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Forgot to mention: That's still the cc1 compiler
(libexec/gcc/x86_64-none-linux-gnu/11.0.0/cc1) not yet an offloading LTO.

The problem seems to be the followingat ipa-utils.h:246:
  /* We do not have this information when not in LTO, but we do not need
 to care, since it is used only for type merging.  */
  gcc_checking_assert (in_lto_p || flag_lto);


Here, we do not compile with LTO but write LTO for offloading.

That code is called by local_tree_p which was added by
r11-525-g03d90a20a1afcbb9c30da8d4adf4922b0685061f , Honza's
  "Avoid SCC hashing on unmergeable trees"
patch of May 20, 2020.

[Bug c++/95321] New: Run-time crash on valid destructor code

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95321

Bug ID: 95321
   Summary: Run-time crash on valid destructor code
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

// Run-time crash with g++ >= 9 and -Ox, x > 1
// Works perfectly with g++ <= 8.3
class IDestroyable
{
protected:
virtual void  Destroy() = 0;

public:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}
};

class IToto
{
public:
virtual void  Toto() = 0;
};

class ITotoDestroyable : public IToto, public IDestroyable
{
public:
void operator delete (void * ptr)
{
if (ptr != nullptr) delete static_cast(static_cast(ptr));
}
};

template 
class DestroyableBase : public INTERFACE
{
protected:
virtual void  Destroy()
{
::delete this;
}

public:
virtual ~DestroyableBase()
{
}

void operator delete (void * ptr)
{
::operator delete (ptr);
}
};

#include 

class TotoDestroyable : public DestroyableBase
{
public:
~TotoDestroyable()
{
std::cout << "OK Destroyed !\n";
}

void  Toto()
{
std::cout << "Toto !\n";
}
};

int main()
{
ITotoDestroyable * foo = new TotoDestroyable();
// Uncomment to workaround the crash
// foo->Toto();
delete foo;
}



Segfaults at runtime when compiled with G++ >= 9 and -O1 or higher.

Process 52619 launched: '/tmp/a.out' (x86_64)
Process 52619 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x00010d44 a.out`main [inlined] IDestroyable::operator
delete(ptr=0x000100604858) at a.cpp:11:70
   8public:
   9void operator delete (void * ptr)
   10   {
-> 11   if (ptr != nullptr) static_cast(ptr)->Destroy();
   12   }
   13   };
   14

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053

--- Comment #8 from Segher Boessenkool  ---
I see no conversion there?

But, why does it it store to memory at all?

[Bug c++/95321] Run-time crash on valid destructor code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95321

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I don't think this is valid:
BY the time operator delete gets called the deconstructor is called and
therefor the object no longer exists therefor:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}

Is invalid code as the vtable in ptr is no longer valid.

Where is this code from?