[Bug tree-optimization/106387] [13 regression] ICE when building gcc after r13-1764-g5f59d0f2d9fa92

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2022-07-22

--- Comment #1 from Richard Biener  ---
Mine.  The following should fix it:

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 01d982eea98..f582d238984 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -10017,7 +10017,10 @@ vectorizable_load (vec_info *vinfo,
 (NULL_TREE, BIT_AND_EXPR, ptr,
  build_int_cst
  (TREE_TYPE (ptr), -(HOST_WIDE_INT) align));
-   ptr = copy_ssa_name (ptr, new_stmt);
+   if (TREE_CODE (ptr) == SSA_NAME)
+ ptr = copy_ssa_name (ptr, new_stmt);
+   else
+ ptr = make_ssa_name (TREE_TYPE (ptr), new_stmt);
gimple_assign_set_lhs (new_stmt, ptr);
vect_finish_stmt_generation (vinfo, stmt_info,
 new_stmt, gsi);

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:66e876a91b5d5c1a0c5067f2d8f1d531da3a81f8

commit r11-10161-g66e876a91b5d5c1a0c5067f2d8f1d531da3a81f8
Author: Jonathan Wakely 
Date:   Tue Jun 28 15:56:30 2022 +0100

libstdc++: Fix experimental::filesystem::status on Windows [PR1]

Although the Filesystem TS isn't properly supported on Windows (unlike
the C++17 Filesystem lib), most tests do pass. Two of the failures are
due to PR 1 which was only fixed for std::filesystem not the TS.
This applies the fix to the TS implementation too.

libstdc++-v3/ChangeLog:

PR libstdc++/1
* src/filesystem/ops.cc (has_trailing_slash): New helper
function.
(fs::status): Strip trailing slashes.
(fs::symlink_status): Likewise.
*
testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Clean the environment before each test and use TMP instead of
TMPDIR so the test passes on Windows.

(cherry picked from commit 6c96b14a19a9e6c365eacc59868a866b99f9786d)

[Bug libstdc++/103992] common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:64beecc2201a1da216a8d3feca85974e08e3c890

commit r11-10164-g64beecc2201a1da216a8d3feca85974e08e3c890
Author: Jonathan Wakely 
Date:   Wed Jan 12 16:58:18 2022 +

libstdc++: Use std::construct_at in std::common_iterator [PR103992]

This should have been done as part of the LWG 3574 changes.

libstdc++-v3/ChangeLog:

PR libstdc++/103992
* include/bits/stl_iterator.h (common_iterator): Use
std::construct_at instead of placement new.
* testsuite/24_iterators/common_iterator/1.cc: Check copy
construction is usable in constant expressions.

(cherry picked from commit d67ba1dce9796bff177e52e2bbb68bfa2c69a884)

[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:7cfef93a241e89f7e019cd1048808aa8e8c07836

commit r11-10166-g7cfef93a241e89f7e019cd1048808aa8e8c07836
Author: Jonathan Wakely 
Date:   Wed Jul 20 16:51:44 2022 +0100

libstdc++: Fix std::common_iterator assignment [PR100823]

This fixes the following conformance problems reported in the PR:

- Move constructor and move assignment should be defined.
- Copy assignment from a valueless object should be allowed.

Assignment is completely rewritten by this patch, as the previous
version had a number of problems. The converting assignment failed to
handle the case of assigning a new value to a valueless object, which
should work. It only accepted lvalue arguments, so wasn't usable to
implement the move assignment operator. Finally, it enforced the
precondition that the argument is not valueless, which is correct for
the converting assignment but not for the copy assignment.

A new _M_assign member is added to handle all cases of assignment
(copying from an lvalue, moving from an rvalue, and converting from a
different type). The not valueless precondition is checked in the
converting assignment before calling _M_assign, so isn't enforced for
copy and move assignment. The new function no longer uses a switch, so
handles valueless objects as the LHS or RHS of the assignment.

libstdc++-v3/ChangeLog:

PR libstdc++/100823
* include/bits/stl_iterator.h (common_iterator): Define move
constructor and move assignment operator.
(common_iterator::_M_assign): New function implementing
assignment.
(common_iterator::operator=): Use _M_assign.
(common_iterator::_S_valueless): New constant.
* testsuite/24_iterators/common_iterator/100823.cc: New test.

(cherry picked from commit 56c9998602fd5091ba0985e2e5eaa90c6478)

[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-10165-gc7a7985e5e24d6d13d179006bc748f5a1eaeebfd
Author: Jonathan Wakely 
Date:   Wed Jul 20 12:49:28 2022 +0100

libstdc++: Fix minor bugs in std::common_iterator

The noexcept-specifier for some std::common_iterator constructors was
incorrectly using an rvalue as the first argument of
std::is_nothrow_assignable_v. This gave the wrong answer for some types,
e.g. std::common_iterator, because an rvalue of scalar type
cannot be assigned to.

Also fix the friend declaration to use the same constraints as on the
definition of the class template. G++ fails to diagnose this error, due
to PR c++/96830.

Finally, the copy constructor was using std::move for its argument
in some cases, which should be removed.

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h (common_iterator): Fix incorrect
uses of is_nothrow_assignable_v. Fix inconsistent constraints on
friend declaration. Do not move argument in copy constructor.
* testsuite/24_iterators/common_iterator/1.cc: Check for
noexcept constructibnle/assignable.

(cherry picked from commit 3b5567c3ec7e5759bdecc6a6fc0be2b65a93636e)

[Bug c++/106389] [11/12/13 Regression] IPA modref breaks Safe Bitfields in C++

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|ipa |c++

--- Comment #3 from Richard Biener  ---
There's a similar rule in C and we simply don't implement that - it's a "stupid
rule" given there's no good way to implement it.  Well.  -fno-strict-aliasing.

For GCC the allowed way is to access the common initial sequence through the
_union_ type.  Thus

union U { struct A { int i; } a; struct B { int i; float f; } b; };

union U *p;

p->a.i = 1;
.. = p->b.i;  // OK
B *b = &p->b;
... = b->i; // not OK

IPA modref simply makes this issue more visible (this across function
boundary).

Note the C rule doesn't involve unions but consider

A *a = &p->a;

  a->i = 1;
  ... = b->i;

I read the C++ rule as if that were allowed as well (*a could be inside a
union,
who knows - the union declaration might not even be visible in the TU!).

For the rule to take effect the frontend needs to mark each access that
falls under the rule as to have alias-set zero.

[Bug libstdc++/100823] Special member functions of common_iterator should be conditionally trivial

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.0

--- Comment #6 from Jonathan Wakely  ---
The triviality of special members is only fixed for GCC 13, but the other
conformance bugs are fixed for 11.4 and 12.2

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
   Keywords||rejects-valid
Summary|[10/11 regression] [mingw]  |[12/13 regression] [mingw]
   |"redeclared without |"redeclared without
   |dllimport attribute:|dllimport attribute:
   |previous dllimport ignored" |previous dllimport ignored"
   |on C++ friend   |on C++ friend
  Known to fail||12.1.0
 Target||mingw
  Known to work||10.3.0, 11.2.1

[Bug tree-optimization/106397] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2022-07-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

[Bug c++/106309] ICE: error reporting routines re-entered

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Martin Liška  ---
No, sorry, I was not lucky.

[Bug c++/106202] [11/12/13 Regression] ICE in move_fn_p, at cp/decl.cc:14907 since r12-885-gf71ca97def69b8ae

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Liška  ---
(In reply to tt_1 from comment #8)
> hi, the fix for this is to be found in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106361 , right?

Yes.

[Bug debug/106399] [10/11/12/13 Regression] Wrong debug info for function with nested function under O0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.4.0, 11.3.0, 12.1.0,
   ||9.5.0
   Last reconfirmed||2022-07-22
Summary|Wrong debug info for|[10/11/12/13 Regression]
   |function with nested|Wrong debug info for
   |function under O0   |function with nested
   ||function under O0
   Target Milestone|--- |10.5
 Ever confirmed|0   |1
  Known to work||7.5.0, 8.4.0
   Keywords||needs-bisection,
   ||wrong-debug
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  It works with -O -fno-inline, it also worked at some point.

[Bug analyzer/106401] [13 Regression] ICE: in binding_cluster, at analyzer/store.cc:1110 with -fanalyzer

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
   Target Milestone|--- |13.0
 Status|NEW |RESOLVED

--- Comment #8 from Jonathan Wakely  ---
Fixed by r13-1783-gdf118d7ba138cacb17203d4a1b5f27730347cc77 for PR 98423.

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

[Bug c++/98423] The defaulted default constructor defined as deleted when one of variant member has a default member initializer

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jens.maurer at gmx dot net

--- Comment #4 from Jonathan Wakely  ---
*** Bug 106150 has been marked as a duplicate of this bug. ***

[Bug other/106370] enhancement: last statement of loop is continue is redundant ?

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-1792-gaaf9583d4cf048850b1eb74d25866f45198e35b8
Author: Martin Liska 
Date:   Fri Jul 22 09:28:48 2022 +0200

remove 'continue' as last statement in loop

PR other/106370

gcc/cp/ChangeLog:

* init.cc (sort_mem_initializers): Remove continue as last stmt
in a loop.

libiberty/ChangeLog:

* _doprnt.c: Remove continue as last stmt
in a loop.

[Bug other/106370] enhancement: last statement of loop is continue is redundant ?

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixes 2 locations, for the rest it seems fine to me the way we write empty body
loop:

  for (insn = get_insns (); insn; insn = conditionalize_block (insn))
continue;

The warning should be omitted when the only statement in a loop in 'continue'.

[Bug tree-optimization/106387] [13 regression] ICE when building gcc after r13-1764-g5f59d0f2d9fa92

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Should be fixed.

[Bug tree-optimization/106387] [13 regression] ICE when building gcc after r13-1764-g5f59d0f2d9fa92

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:3c4af0f0549a07799d76e9e48d3d3bd85197b92a

commit r13-1793-g3c4af0f0549a07799d76e9e48d3d3bd85197b92a
Author: Richard Biener 
Date:   Fri Jul 22 09:00:37 2022 +0200

tree-optimization/106387 - properly create SSA name for realigned load

The following fixes an oversight triggering after the recent change
to bump_vector_ptr.

PR tree-optimization/106387
* tree-vect-stmts.cc (vectorizable_load): Use make_ssa_name
if ptr is not an SSA name.

[Bug c++/106398] ICE in finish_expr_stmt at cp/semantics.c:872 for lambda with conditional noexcept against lambda in unevaluated context

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-22

--- Comment #2 from Martin Liška  ---
Started with r9-4045-g0c1e0d63fe0ceabb, it was rejected before the revision
with:

pr106398.c: In function ‘void intersect(const set&, const set&)’:
pr106398.c:13:56: error: lambda-expression in unevaluated context
   13 |   auto f = [&](T1&& _1) noexcept(decltype([] {
  |^
pr106398.c:13:47: error: decltype evaluates to ‘’, which is not a
class or enumeration type
   13 |   auto f = [&](T1&& _1) noexcept(decltype([] {
  |   ^~~~

[Bug tree-optimization/106397] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |check_loop_closed_ssa_def,  |check_loop_closed_ssa_def,
   |at  |at
   |tree-ssa-loop-manip.cc:645  |tree-ssa-loop-manip.cc:645
   ||since
   ||r13-1450-gd2a89809452e

--- Comment #2 from Martin Liška  ---
Btw. started with r13-1450-gd2a89809452e.

[Bug analyzer/106401] [13 Regression] ICE: in binding_cluster, at analyzer/store.cc:1110 with -fanalyzer since r13-1761-g68871a008e686dbe

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-07-22
Summary|[13 Regression] ICE: in |[13 Regression] ICE: in
   |binding_cluster, at |binding_cluster, at
   |analyzer/store.cc:1110 with |analyzer/store.cc:1110 with
   |-fanalyzer  |-fanalyzer since
   ||r13-1761-g68871a008e686dbe
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r13-1761-g68871a008e686dbe.

[Bug tree-optimization/106403] New: [13 Regression] ICE in vect pass

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106403
   Summary: [13 Regression] ICE in vect pass
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

The following crashes:

$ cat matmul.f90
module x
contains
  subroutine mm1(a,b,c)
  end subroutine mm1
end module x
program main
  integer, parameter :: n = 3, m=4, cnt=2
  real, dimension(n,cnt) :: a
  real, dimension(m,cnt) :: b
  real, dimension(n,m) :: c, cres
  real, dimension(:,:), allocatable :: calloc
  calloc = matmul(a,transpose(b)) ! { dg-warning "Code for reallocating the
allocatable array" }
  if (sum(calloc-cres)>1e-4) STOP 6
end program main

$ aarch64-linux-gnu-gcc -O3 matmul.f90 -c
during GIMPLE pass: vect
matmul.f90:14:16:

   14 | end program main
  |^
internal compiler error: Segmentation fault
0xd371ff crash_signal
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/toplev.cc:322
0x778567bf ???
   
/usr/src/debug/glibc-2.35-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xedb0d1 rpo_vn_valueize(tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:7505
0xee545e vn_reference_lookup_3
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:3226
0xe19a2b walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-alias.cc:3880
0xee022d vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:3908
0xee7b23 visit_reference_op_load
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:5548
0xee7b23 visit_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:5997
0xee8156 process_bb
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:7724
0xee9704 do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool,
vn_lookup_kind)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:8323
0xeea953 do_rpo_vn(function*, edge_def*, bitmap_head*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-ssa-sccvn.cc:8419
0xf9eb51 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.cc:1388
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/106403] [13 Regression] ICE in vect pass

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-22

[Bug tree-optimization/106403] [13 Regression] ICE in rpo_vn_valueize at gcc/tree-ssa-sccvn.cc:7505

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Liška  ---
where it gets RHS for:

# .MEM_136 = VDEF <.MEM_129>
MEM  [(real(kind=4) *)vectp.64_120] = .STORE_LANES
(vect_array.66);

[Bug target/106404] New: [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O2 -fno-dce --param=max-cse-insns=1

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106404
   Summary: [13 Regression] ICE: in extract_insn, at recog.cc:2791
(unrecognizable insn) with -O2 -fno-dce
--param=max-cse-insns=1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 53334
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53334&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce --param=max-cse-insns=1 testcase.c 
testcase.c: In function 'foo':
testcase.c:15:1: error: unrecognizable insn:
   15 | }
  | ^
(insn 214 133 139 4 (set (reg:V1TI 238)
(reg:TI 193)) "testcase.c":13:5 -1
 (expr_list:REG_UNUSED (reg:V1TI 238)
(nil)))
during RTL pass: subreg3
testcase.c:15:1: internal compiler error: in extract_insn, at recog.cc:2791
0x7782b8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x77833b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x766bed extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2791
0x2494c77 decompose_multiword_subregs
/repo/gcc-trunk/gcc/lower-subreg.cc:1555
0x2495d9d execute
/repo/gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1791-20220722100642-g1cc0e9a46e7-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1791-20220722100642-g1cc0e9a46e7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220722 (experimental) (GCC)

[Bug tree-optimization/106397] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
The prefetching pass puts a __builtin_ia32_mfence () before the
__builtin_unreachable () at the loop exit.  IIRC there's a related bug that
while return statements have a VUSE alternate "function returns" may lack them
(that includes some EH related returns as well).

Since the function eventually splits loop exit edges it breaks LC SSA anyway
(that's a latent issue I think).

[Bug target/106404] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O2 -fno-dce --param=max-cse-insns=1 since r13-1607-gc3ed9e0d6e96d869

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-07-22
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
Summary|[13 Regression] ICE: in |[13 Regression] ICE: in
   |extract_insn, at|extract_insn, at
   |recog.cc:2791   |recog.cc:2791
   |(unrecognizable insn) with  |(unrecognizable insn) with
   |-O2 -fno-dce|-O2 -fno-dce
   |--param=max-cse-insns=1 |--param=max-cse-insns=1
   ||since
   ||r13-1607-gc3ed9e0d6e96d869
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r13-1607-gc3ed9e0d6e96d869.

[Bug target/106404] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O2 -fno-dce --param=max-cse-insns=1 since r13-1607-gc3ed9e0d6e96d869

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/106403] [13 Regression] ICE in rpo_vn_valueize at gcc/tree-ssa-sccvn.cc:7505

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   Target Milestone|--- |13.0

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

[Bug tree-optimization/106403] [13 Regression] ICE in rpo_vn_valueize at gcc/tree-ssa-sccvn.cc:7505

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
Ah, internal_fn_stored_value_index returns -1 for .STORE_LANES :/  Well, the
fix is reasonably easy.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #7 from Roger Sayle  ---
*** Bug 106404 has been marked as a duplicate of this bug. ***

[Bug target/106404] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O2 -fno-dce --param=max-cse-insns=1 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Roger Sayle  ---
I can confirm that this failure is (will be) fixed by the patch for PR 106303
(thanks to H.J. Lu) that I'm currently bootstrapping and regression testing.

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

[Bug tree-optimization/106397] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r13-1794-gb2e99bb6900f33f46a0f4ca6ae94b8a39b0b9bb1
Author: Richard Biener 
Date:   Fri Jul 22 09:57:38 2022 +0200

tree-optimization/106397 - array prefetch and LC SSA

The following fixes maintaining LC SSA when array prefetch inserts
mfence instructions on loop exits that do not use memory.  It also
fixes the latent issue that it might split exit edges for this
which will break LC SSA for non-virtuals as well.  It should also
make the process cheaper by accumulating the required (LC) SSA
update until the end of the pass.

PR tree-optimization/106397
* tree-ssa-loop-prefetch.cc (emit_mfence_after_loop): Do
not update SSA form here.
(mark_nontemporal_stores): Return whether we marked any
non-temporal stores and inserted mfence.
(loop_prefetch_arrays): Note when we need to update SSA.
(tree_ssa_prefetch_arrays): Perform required (LC) SSA update
at the end of the pass.

* gcc.dg/pr106397.c: New testcase.

[Bug tree-optimization/106403] [13 Regression] ICE in rpo_vn_valueize at gcc/tree-ssa-sccvn.cc:7505

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r13-1795-gd85e5aeb7665ea941ff0ef7c11bfe1d39986b48a
Author: Richard Biener 
Date:   Fri Jul 22 10:13:06 2022 +0200

tree-optimization/106403 - fix ICE with VN of .STORE_LANES

While .STORE_LANES is not supported by the recent VN patch we were
still accessing the stored value and valueizing it - but
internal_fn_stored_value_index does not support .STORE_LANES and
we failed to honor that case.  Fixed by simply moving the affected
code below the check for the actual supported internal functions.

PR tree-optimization/106403
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Move stored
value valueization after check for IFN_MASKED_STORE or
IFN_LEN_STORE.

[Bug tree-optimization/106403] [13 Regression] ICE in rpo_vn_valueize at gcc/tree-ssa-sccvn.cc:7505

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/106397] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/106405] New: GCC incorrectly accepts function template specialization

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 106405
   Summary: GCC incorrectly accepts function template
specialization
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following program is successfully compiled with gcc even though it is not
valid and so should give a compile time error: https://godbolt.org/z/3xsKKbxE3

template< typename T > int func(); // (1)
template< typename ... Args > int func();  // (2)
template<> int func() { return 1; }  //this should give error but gcc
compiles this without any error
int main() {

}

[Bug tree-optimization/101555] Compile slowdown in tree PRE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed in GCC 12.

[Bug rtl-optimization/105376] ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed for GCC 12.2, not a regression.

[Bug c/106406] New: _Static_assert declaration can not be first of for-triplet

[chumarshal at foxmail dot com via Gcc-bugs]

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

Bug ID: 106406
   Summary: _Static_assert declaration can not be first of
for-triplet
   Product: gcc
   Version: rust/master
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chumarshal at foxmail dot com
  Target Milestone: ---

int main()
{
int i = 4;
for (_Static_assert (3, "This is a three"); i < 7; i++) {
i += 2;
}
 }


Gcc can build successfully, but it does not follow C spec:

6.8.5 Iteration statements
(Constraints)
The declaration part of a for statement shall only declare identifiers for
objects having storage class auto or register.

[Bug rtl-optimization/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Surya Kumari Jangala
:

https://gcc.gnu.org/g:2753c7d0cd95a3db9d97c5ee674917ad11de5246

commit r10-10907-g2753c7d0cd95a3db9d97c5ee674917ad11de5246
Author: Surya Kumari Jangala 
Date:   Fri Jun 10 19:52:57 2022 +0530

regrename: Fix -fcompare-debug issue in check_new_reg_p [PR105041]

In check_new_reg_p, the nregs of a du chain is computed by obtaining the
MODE of the first element in the chain, and then calling
hard_regno_nregs() with the MODE. But the first element of the chain can
be a DEBUG_INSN whose mode need not be the same as the rest of the
elements in the du chain. This was resulting in fcompare-debug failure
as check_new_reg_p was returning a different result with -g for the same
candidate register. We can instead obtain nregs from the du chain
itself.

2022-06-10  Surya Kumari Jangala  

gcc/
PR rtl-optimization/105041
* regrename.c (check_new_reg_p): Use nregs value from du chain.

gcc/testsuite/
PR rtl-optimization/105041
* gcc.target/powerpc/pr105041.c: New test.

(cherry picked from commit 3e16b4359e86b36676ed01219e6deafa95f3c16b)

[Bug c++/106405] GCC incorrectly accepts function template specialization

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Jonathan Wakely  ---
MSVC rejects it too, but EDG accepts it in strict mode.

[Bug target/106407] New: [13 Regression] ICE: in copy_to_mode_reg, at explow.cc:652 with -O2 -fno-dce -fno-tree-dce -fno-tree-dse

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106407
   Summary: [13 Regression] ICE: in copy_to_mode_reg, at
explow.cc:652 with -O2 -fno-dce -fno-tree-dce
-fno-tree-dse
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 53335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53335&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-tree-dce -fno-tree-dse testcase.c
-Wno-psabi
during RTL pass: dse1
testcase.c: In function 'bar0':
testcase.c:25:1: internal compiler error: in copy_to_mode_reg, at explow.cc:652
   25 | }
  | ^
0x6ceedf copy_to_mode_reg(machine_mode, rtx_def*)
/repo/gcc-trunk/gcc/explow.cc:652
0x2398123 replace_read
/repo/gcc-trunk/gcc/dse.cc:2020
0x239d310 check_mem_read_rtx
/repo/gcc-trunk/gcc/dse.cc:2296
0x239d310 check_mem_read_use
/repo/gcc-trunk/gcc/dse.cc:2401
0x134ee64 note_uses(rtx_def**, void (*)(rtx_def**, void*), void*)
/repo/gcc-trunk/gcc/rtlanal.cc:2065
0x239a37a scan_insn
/repo/gcc-trunk/gcc/dse.cc:2510
0x239a37a dse_step1
/repo/gcc-trunk/gcc/dse.cc:2775
0x239a37a rest_of_handle_dse
/repo/gcc-trunk/gcc/dse.cc:3692
0x239a37a execute
/repo/gcc-trunk/gcc/dse.cc:3765
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1793-20220722093343-g3c4af0f0549-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1793-20220722093343-g3c4af0f0549-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220722 (experimental) (GCC)

[Bug debug/106399] [10/11/12/13 Regression] Wrong debug info for function with nested function under O0 since r9-1284-gd70ba0c10dec6968

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
   |Wrong debug info for|Wrong debug info for
   |function with nested|function with nested
   |function under O0   |function under O0 since
   ||r9-1284-gd70ba0c10dec6968
   Keywords|needs-bisection |

--- Comment #2 from Martin Liška  ---
Started with r9-1284-gd70ba0c10dec6968.

[Bug target/106346] Potential regression on vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||joelh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|Potential regression on |Potential regression on
   |vectorization of left shift |vectorization of left shift
   |with constants  |with constants since
   ||r11-5160-g9fc9573f9a5e94
   Last reconfirmed||2022-07-22

[Bug target/106407] [13 Regression] ICE: in copy_to_mode_reg, at explow.cc:652 with -O2 -fno-dce -fno-tree-dce -fno-tree-dse since r13-1607-gc3ed9e0d6e96d869

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|[13 Regression] ICE: in |[13 Regression] ICE: in
   |copy_to_mode_reg, at|copy_to_mode_reg, at
   |explow.cc:652 with -O2  |explow.cc:652 with -O2
   |-fno-dce -fno-tree-dce  |-fno-dce -fno-tree-dce
   |-fno-tree-dse   |-fno-tree-dse since
   ||r13-1607-gc3ed9e0d6e96d869
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
   Last reconfirmed||2022-07-22

--- Comment #1 from Martin Liška  ---
Also started with r13-1607-gc3ed9e0d6e96d869.

[Bug rtl-optimization/106078] RTL PRE with non-call-exceptions

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|Invalid loop invariant  |RTL PRE with
   |motion with |non-call-exceptions
   |non-call-exceptions |
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
  Component|middle-end  |rtl-optimization
 Status|ASSIGNED|NEW

--- Comment #6 from Richard Biener  ---
Note it is RTL PRE hoisting the load from b, not invariant motion.  On the
testcase w/o -fnon-call-exceptions it's tree PRE (or if disabled, RTL PRE
again)
doing the hoisting.

For some reason for the non-call-exception PRE case the following does not
help.

diff --git a/gcc/gcse-common.cc b/gcc/gcse-common.cc
index e86d4c4f477..16f804d13f9 100644
--- a/gcc/gcse-common.cc
+++ b/gcc/gcse-common.cc
@@ -82,7 +82,8 @@ record_last_mem_set_info_common (rtx_insn *insn,
   modify_mem_list[bb].safe_push (insn);
   bitmap_set_bit (modify_mem_list_set, bb);

-  if (CALL_P (insn))
+  if (CALL_P (insn)
+  || can_throw_external (insn))
 bitmap_set_bit (blocks_with_calls, bb);
   else
 {
diff --git a/gcc/gcse.cc b/gcc/gcse.cc
index f06278a5534..b138e1e501c 100644
--- a/gcc/gcse.cc
+++ b/gcc/gcse.cc
@@ -1535,13 +1535,14 @@ compute_hash_table_work (struct gcse_hash_table_d
*table)
= insn_callee_abi (insn).full_and_partial_reg_clobbers ();
  EXECUTE_IF_SET_IN_HARD_REG_SET (callee_clobbers, 0, regno, hrsi)
record_last_reg_set_info (insn, regno);
-
- if (! RTL_CONST_OR_PURE_CALL_P (insn)
- || RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)
- || can_throw_external (insn))
-   record_last_mem_set_info (insn);
}

+ if ((CALL_P (insn)
+  && (! RTL_CONST_OR_PURE_CALL_P (insn)
+  || RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)))
+ || can_throw_external (insn))
+   record_last_mem_set_info (insn);
+
  note_stores (insn, record_last_set_info, insn);
}

[Bug middle-end/106408] New: PRE with infinite loops

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106408
   Summary: PRE with infinite loops
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

int array[1];
volatile int val;
int test(short *b,int s)
{
for (int i = 0; i<1;i++)
  {
for (int j = 0; j < 10; j+=s)
val++;
array[i]+=*b;
  }
}

shows we PRE the *b load from both GIMPLE and RTL PRE across the possibly
infinite loop (with s == 0).  The function makes progress by means of
the volatile access which is considered I/O.

[Bug rtl-optimization/106078] RTL PRE with non-call-exceptions

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Richard Biener  ---
I split out the inifinite loop case to PR106408.

[Bug middle-end/106408] PRE with infinite loops

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
An incomplete solution on the GIMPLE level is the following.  It's incomplete
because there's a hole for irreducible regions which we do not represent
explicitely (nor their sub-irreducible regions). 
rev_post_order_and_mark_dfs_back_seme has a simplified loop discovery code
that would properly compute this.

Just considering all blocks in irreducible regions as BB_MAY_NORETURN will
inhibit all in-region PRE which is probably undesirable.  OTOH the code
below will unnecessarily pessimize "well written" loops while leaving the
bug open for the bad ones.

diff --git a/gcc/tree-ssa-pre.cc b/gcc/tree-ssa-pre.cc
index e029bd36da3..76dbef4cff3 100644
--- a/gcc/tree-ssa-pre.cc
+++ b/gcc/tree-ssa-pre.cc
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-cfgcleanup.h"
 #include "alias.h"
 #include "gimple-range.h"
+#include "tree-ssa-loop-niter.h"

 /* Even though this file is called tree-ssa-pre.cc, we actually
implement a bit more than just PRE here.  All of them piggy-back
@@ -3939,6 +3940,12 @@ compute_avail (function *fun)

   BB_MAY_NOTRETURN (block) = 0;

+  /* If block is a loop that is possibly infinite we should not
+hoist across it.  */
+  if (block->loop_father->header == block
+ && !finite_loop_p (block->loop_father))
+   BB_MAY_NOTRETURN (block) = 1;
+
   /* Now compute value numbers and populate value sets with all
 the expressions computed in BLOCK.  */
   bool set_bb_may_notreturn = false;

[Bug target/106346] Potential regression on vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #3 from Tamar Christina  ---
Joel is no longer working on GCC, I'll fix the regression next week when back
from holidays.

[Bug c++/106409] New: GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[lluis.alemany.puig at gmail dot com via Gcc-bugs]

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

Bug ID: 106409
   Summary: GCC with LTO: Warning: argument 1 value ‘18...615’
(SIZE_MAX) exceeds maximum object size
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lluis.alemany.puig at gmail dot com
  Target Milestone: ---

I'm using g++ (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0. I'm getting the following
warning when I compile my code using -flto and -fno-fat-lto-objects:

```
In member function ‘alloc_data’,
inlined from ‘__ct ’ at data_array.hpp:9:67,
inlined from ‘__ct ’ at main.cpp:26:5,
inlined from ‘main’ at main.cpp:61:16:
data_array.hpp:29:50: warning: argument 1 value ‘18446744073709551615’
exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
   29 | m_data = m_size == 0 ? nullptr : new T[m_size];
  |  ^
data_array.hpp: In function ‘main’:
/usr/include/c++/11/new:128:26: note: in a call to allocation function
‘operator new []’ declared here
  128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW
(std::bad_alloc)
  |  ^
```

The two sets of commands I use to compile my code are (-fsanitize=undefined):

```
g++ -pipe -std=c++17 -fPIC -fopenmp -flto -fno-fat-lto-objects -O3 -Wall
-Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused
-Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion
-Wnull-dereference -Wdouble-promotion -Wformat=2 -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wrestrict -UDEBUG -DNDEBUG
-fstrict-aliasing -D_REENTRANT -fPIC -fsanitize=undefined -c main.cpp
g++ -fPIC -O3 -flto -fno-fat-lto-objects -DNDEBUG -UDEBUG -Wl,-O3
-fsanitize=undefined -o main main.o
```

and (-fsanitize=address)

```
g++ -pipe -std=c++17 -fPIC -fopenmp -flto -fno-fat-lto-objects -O3 -Wall
-Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused
-Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion
-Wnull-dereference -Wdouble-promotion -Wformat=2 -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wrestrict -UDEBUG -DNDEBUG
-fstrict-aliasing -D_REENTRANT -fPIC -fsanitize=address -c main.cpp
g++ -fPIC -O3 -flto -fno-fat-lto-objects -DNDEBUG -UDEBUG -Wl,-O3 -o main
main.o -lasan
```

Both sets of commands produce the warning above. With both, the program
executes normally and finishes without issuing any error message.

I generated the *i file with the following command
```
g++ -E -std=c++17 -fPIC -fopenmp -flto -fno-fat-lto-objects -O3 -Wall
-Wextra -Wshadow -Wnon-virtual-dtor -Wold-style-cast -Wcast-align -Wunused
-Woverloaded-virtual -Wpedantic -Wconversion -Wsign-conversion
-Wnull-dereference -Wdouble-promotion -Wformat=2 -Wduplicated-cond
-Wduplicated-branches -Wlogical-op -Wuseless-cast -Wrestrict -UDEBUG -DNDEBUG
-fstrict-aliasing -D_REENTRANT -fPIC -save-temps -c main.cpp
```

[Bug c++/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[lluis.alemany.puig at gmail dot com via Gcc-bugs]

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

--- Comment #1 from llualpu  ---
This was originally submitted at Stack Overflow:
https://stackoverflow.com/questions/73047957/gcc-with-lto-warning-argument-1-value-18-615-size-max-exceeds-maximum-ob

[Bug sanitizer/105531] [13 regression] Recent libsanitizer imports breaks Solaris 11.3 build

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:786e51648bd9a6880339329380751809fb97cd6d

commit r13-1797-g786e51648bd9a6880339329380751809fb97cd6d
Author: Rainer Orth 
Date:   Fri Jul 22 13:18:14 2022 +0200

libsanitizer: Fix Solaris 11.3 compilation [PR105531]

The libsanitizer build has been broken on Solaris 11.3 by the latest
import.  An upstream patch to fix this has now been committed:

[sanitizer_common] Support Solaris < 11.4 in GetStaticTlsBoundary
https://reviews.llvm.org/D120059

I'd like to cherry-pick it into libsanitizer, too.

Bootstrapped without regressions on sparc-sun-solaris2.11,
i386-pc-solaris2.11 (both Solaris 11.3 and 11.4), and
x86_64-pc-linux-gnu.

2022-07-21  Rainer Orth  

libsanitizer:
PR sanitizer/105531
* sanitizer_common/sanitizer_linux_libcdep.cpp,
sanitizer_common/sanitizer_solaris.h:: Cherry-pick
llvm-project revision 3776db9a4fd2080d23d6a5f52e405eea44558761.

[Bug sanitizer/105531] [13 regression] Recent libsanitizer imports breaks Solaris 11.3 build

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

 Resolution|--- |FIXED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2022-July/59
   ||8690.html
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #2 from Rainer Orth  ---
Mine.  Patch posted and commited.

[Bug middle-end/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10168-ge2b97d6883a72b0c51dd0455acea43e21b5537d9
Author: Richard Biener 
Date:   Mon Nov 15 12:13:40 2021 +0100

middle-end/103193 - avoid canonicalizing <= and >= to == for floats

This avoids doing aforementioned canoncalization when -ftrapping-math
is in effect and we honor NaNs.

2021-11-15  Richard Biener  

PR middle-end/103193
* match.pd: Avoid canonicalizing (le/ge @0 @0) to (eq @0 @0)
with NaNs and -ftrapping-math.

(cherry picked from commit d9ca2ca381e44a332703155d07b50b84aa21f80d)

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10167-gff408622a5f8fb395e5584a494d05b3611db
Author: Richard Biener 
Date:   Wed May 4 10:43:07 2022 +0200

tree-optimization/103116 - SLP permutes and peeling for gaps

The testcase shows that we can end up with a contiguous access across
loop iterations but by means of permutations the elements accessed
might only cover parts of a vector.  In this case we end up with
GROUP_GAP == 0 but still need to avoid accessing excess elements
in the last loop iterations.  Peeling for gaps is designed to cover
this but a single scalar iteration might not cover all of the excess
elements.  The following ensures peeling for gaps is done in this
situation and when that isn't sufficient because we need to peel
more than one iteration (gcc.dg/vect/pr103116-2.c), fail the SLP
vectorization.

2022-05-04  Richard Biener  

PR tree-optimization/103116
* tree-vect-stmts.c (get_group_load_store_type): Handle the
case we need peeling for gaps even though GROUP_GAP is zero.

* gcc.dg/vect/pr103116-1.c: New testcase.
* gcc.dg/vect/pr103116-2.c: Likewise.

(cherry picked from commit 52b7b86f8c72eb19e637f1e72ffd10f39b8cb829)

[Bug tree-optimization/105618] [11 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|11.3.1  |11.3.0
  Known to work||11.3.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/105618] [11 Regression] Missed loop body simplification by -O3 (trunk v.s. 10.3)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10169-gdba0883cbbd0ce7545041be96ae75db1d577affb
Author: Richard Biener 
Date:   Tue May 17 09:45:02 2022 +0200

tree-optimization/105618 - restore load sinking

The PR97330 fix caused some missed sinking of loads out of loops
the following patch re-instantiates.

2022-05-17  Richard Biener  

PR tree-optimization/105618
* tree-ssa-sink.c (statement_sink_location): For virtual
PHI uses ignore those defining the used virtual operand.

* gcc.dg/tree-ssa/ssa-sink-19.c: New testcase.

(cherry picked from commit ebce0e9bd8d714a8607ae24331a3d842b0d11859)

[Bug middle-end/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||11.3.0
  Known to work||11.3.1
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Richard Biener  ---
Fixed for GCC 11.4.

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail|11.2.1  |11.3.0
  Known to work||11.3.1

--- Comment #11 from Richard Biener  ---
Fixed for GCC 11+

[Bug c++/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-07-22

--- Comment #2 from Martin Liška  ---
Please attach the pre-processed source file.

[Bug middle-end/106408] PRE with infinite loops

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #2 from Jan Hubicka  ---
> +  /* If block is a loop that is possibly infinite we should not
> +hoist across it.  */
> +  if (block->loop_father->header == block
> + && !finite_loop_p (block->loop_father))
> +   BB_MAY_NOTRETURN (block) = 1;
> +
Don't you just need to handle also BBs that have backedge out that is
not a latch of loop?
(it is an ugly issue overall)

Honza

[Bug middle-end/106408] PRE with infinite loops

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 22 Jul 2022, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106408
> 
> --- Comment #2 from Jan Hubicka  ---
> > +  /* If block is a loop that is possibly infinite we should not
> > +hoist across it.  */
> > +  if (block->loop_father->header == block
> > + && !finite_loop_p (block->loop_father))
> > +   BB_MAY_NOTRETURN (block) = 1;
> > +
> Don't you just need to handle also BBs that have backedge out that is
> not a latch of loop?

I would need to handle all blocks with an incoming backedge,
and for non-irreducible regions can use finite_loop_p, yes.
Not sure what you mean with backedge out.

So the following would handle loops and irreducible regions correctly
I think.

diff --git a/gcc/tree-ssa-pre.cc b/gcc/tree-ssa-pre.cc
index e029bd36da3..a2d8b52f872 100644
--- a/gcc/tree-ssa-pre.cc
+++ b/gcc/tree-ssa-pre.cc
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-cfgcleanup.h"
 #include "alias.h"
 #include "gimple-range.h"
+#include "tree-ssa-loop-niter.h"

 /* Even though this file is called tree-ssa-pre.cc, we actually
implement a bit more than just PRE here.  All of them piggy-back
@@ -3939,6 +3940,16 @@ compute_avail (function *fun)

   BB_MAY_NOTRETURN (block) = 0;

+  /* If this block is an entry into a CFG cycle that is possibly 
infinite
+we should not hoist across it.  */
+  edge_iterator ei;
+  edge e;
+  FOR_EACH_EDGE (e, ei, block->preds)
+   if ((e->flags & EDGE_DFS_BACK)
+   && (block->loop_father->header != block
+   || !finite_loop_p (block->loop_father)))
+ BB_MAY_NOTRETURN (block) = 1;
+
   /* Now compute value numbers and populate value sets with all
 the expressions computed in BLOCK.  */
   bool set_bb_may_notreturn = false;

[Bug target/106407] [13 Regression] ICE: in copy_to_mode_reg, at explow.cc:652 with -O2 -fno-dce -fno-tree-dce -fno-tree-dse since r13-1607-gc3ed9e0d6e96d869

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c/106406] _Static_assert declaration can not be first of for-triplet

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
it doesn't declare anything so why should it be invalid?

[Bug c++/106409] GCC with LTO: Warning: argument 1 value ‘18...615’ (SIZE_MAX) exceeds maximum object size

[lluis.alemany.puig at gmail dot com via Gcc-bugs]

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

--- Comment #3 from llualpu  ---
Created attachment 53336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53336&action=edit
(Compressed) preprocessed file generated by GCC as required by "What we need"

I couldn't upload it raw (in plain text, without compressing) because it was
bigger than the file size limit (around 1300 KB).

[Bug fortran/106410] New: Internal compiler error: with nested parametrized types

[s.lopez at brgm dot fr via Gcc-bugs]

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

Bug ID: 106410
   Summary: Internal compiler error: with nested parametrized
types
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s.lopez at brgm dot fr
  Target Milestone: ---

Compiling the following code :

```
module M

   type A(n)
  integer, len :: n
  real :: a(n)
   end type

   type B(n)
  integer, len :: n
  type(A(n)) :: as
   end type

contains

! subroutine f(a, b)
!type(A(*)), intent(in) :: a
!type(B(a%n)), intent(out) :: b
! end subroutine

subroutine g(b)
   type(B(*)), intent(in) :: b
end subroutine

end module
```

generates an internal compiler error, whereas uncommenting the commented lines
works fine.

[Bug debug/106399] [10/11/12/13 Regression] Wrong debug info for function with nested function under O0 since r9-1284-gd70ba0c10dec6968

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Eric Botcazou  ---
Which version of GDB?  Can you try with a more recent one?

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed|2022-07-04 00:00:00 |2022-07-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #32 from Richard Earnshaw  ---
So the problem is in postreload.

After register allocation we have (rewritten to make the short insns describe
what's happening):
r5=sp+0xb4
r7=sp+0x64
r4=sp+0xa4
r6=sp+0xa4

  102: r0:TI=[sp:SI + 0x84] // Set 5
  103: [r4:SI] = r0:TI  // Set 5

  106: r0:TI=[r4:SI]// Set 0 (memcpy)
  107: [r5:SI] = r0:TI  // Set 0

  110: r0:TI = [r5:SI]  // Set 2
  111: [r8:SI] = r0:TI  // Set 2

  114: r0:TI = [r8:SI]  // Set 2
  115: [lr:SI] = r0:TI  // Set 2

  118: r0:TI = [lr:SI]  // Set 2
  119: [r7:SI] = r0:TI  // Set 2

  122: r0:TI = [r7:SI]  // Set 2
  123: [r5:SI] = r0:TI  // Set 2

  126: r0:TI = [r5:SI]  // Set 2
  127: [SP:SI+0x14] = r0:TI // Set 2

  130: r0:TI = [sp:SI+0x14] // Set 2
  131: [r4:SI] = r0:TI  // Set 2

  143: s14:SF=[r6:SI]   // Set 1

Where alias set 1 is for float, alias set 2 is for v and alias set 5 is
for v.  Alias sets 1 and 2 conflict, but alias set 5 does not.

Posreload removes all the loads except the first and finally removes the store
at insn 131, because value-wise it replicates the store at insn 103.  But that
means that the alias dance through the memcpy is lost and so the compiler feels
it is now free (during sched2) to move insn 143 before insn 103.

[Bug c++/106389] [11/12/13 Regression] IPA modref breaks Safe Bitfields in C++

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Richard Biener from comment #3)
> For the rule to take effect the frontend needs to mark each access that
> falls under the rule as to have alias-set zero.

Something like: make c_common_get_alias_set return -1 for those COMPONENT_REFs
in a standard-layout union that share a common initial sequence, and are
standard-layout structs?

[Bug target/105018] [nvptx] Need better alias support

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/MentorEm
   ||bedded/nvptx-tools/issues/3
   ||2
   Last reconfirmed||2022-07-22
 CC||amonakov at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Thomas Schwinge  ---
(In reply to Tom de Vries from comment #2)
> As mentioned before by amonakov, a possibility is to add alias support to
> the nvptx-tools linker, and use that.

 "[LD] Handle alias in
nvptx-ld as nvptx's .alias does not handle it fully".

Alexander, you don't happen to have started working on this already?

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #33 from Richard Earnshaw  ---
I suspect there is still a question, though, as to whether it is safe in
general for two objects with non-conflicting alias sets to share a stack slot.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791 since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #8 from Roger Sayle  ---
*** Bug 106407 has been marked as a duplicate of this bug. ***

[Bug target/106407] [13 Regression] ICE: in copy_to_mode_reg, at explow.cc:652 with -O2 -fno-dce -fno-tree-dce -fno-tree-dse since r13-1607-gc3ed9e0d6e96d869

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Roger Sayle  ---
I can confirm that this failure is also (will also be) fixed by the patch for
PR 106303 (thanks to H.J. Lu) that I'm currently bootstrapping and regression
testing. Sorry for the inconvenience.

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

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Thomas Schwinge  ---
I looked into this, with the goal of estimating the effort necessary for what
you might call "GPU support for minimal C++ library".  That is, allow use of
standard C++ for host code (in particular, no '-fno-exceptions' required for
host code, etc.), and in offloaded regions support a "reasonable subset of C++"
(not exactly defined at this time).

For my experimenting, I default GCN, nvptx to '-fno-rtti', '-fno-exceptions',
address a few bugs and offload target misconfigurations, small libsupc++
changes, configure GCN, nvptx libstdc++ "freestanding" (manually specifying
'--disable-hosted-libstdcxx'; thus just 'libsupc++.a'), hard-code
'-foffload-options=nvptx-none=-mptx=6.3\ -malias' to work around GCC PR105018
"[nvptx] Need better alias support", and with some more manual hand-holding
etc., I do have the code working that originated this issue, which uses C++
'new' in OpenMP 'target'.  (Yay.)  Resolving all these things properly, I'm
estimating to easily turn into a multi-week effort -- but hey, it's C++, so... 
;-)

---

However...  As soon as you start doing a little bit more C++ in offloaded
regions (like, defining a simple 'std::vector v(100);', how dare you...),
it becomes apparent that the configuration mismatch between host and offload
targets is problematic: GCC/C++ synthesizes/emits constructs that the offload
targets are not prepared for, leading to a good mixture ICEs, 'sorry's,
undefined symbols.  While certainly there are genuine bugs to be addressed, I'm
not convinced anymore that such a setup is going to work easily.

Building full libstdc++ for the offload targets runs into similar ICEs,
'sorry's, still with default '-fno-rtti', '-fno-exceptions'.  We'd need to
resolve these issues, by improving the offload target back ends etc., and/or
GCC/C++ front end down to libstdc++, as appropriate.  This sounds doable, but
not trivial, but we'd still have the issue of, for example, mismatching
'-fexceptions' in host code (thus, exceptions codes may appear in the
offloading code stream), and '-fno-exceptions' configuration for offload
targets.

I'm toying with the idea of looking into "sanitizing" the offloading code
stream (easly pass in offload compilation pipeline), so that it's more
"amenable" for offload compilation, but again I don't know whether that's going
to work out, and how much effort that requires.

---

So, this is just a brain-dump, to report where we are, and/or in case anyone
has any great ideas.  :-)

[Bug c++/25689] missed diagnostic about assignment used as truth value.

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 13 I think?

[Bug c++/106411] New: Wdangling-pointer for a class that cleans up on destruction

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 106411
   Summary: Wdangling-pointer for a class that cleans up on
destruction
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Reduced testcase:

#include 
void g(auto f1) {
auto f2 = std::move(f1);
}
struct F;
struct E {
F* f = nullptr;
};
struct F {
E* e;
explicit F(E* a) : e(a) { e->f = this; }
~F() {
if (e)
e->f = nullptr;
}
F(F&& rhs) : e(std::exchange(rhs.e, nullptr)) {
e->f = this;
}
};
int main() {
E e;
F f(&e);
g(std::move(f));
}

At -O -Wall in 12.1 and current trunk 13.0.0:

In constructor 'F::F(F&&)',
inlined from 'void g(auto:1) [with auto:1 = F]' at :3:10,
inlined from 'int main()' at :23:6:
:17:14: warning: storing the address of local variable 'f2' in
'*__old_val.E::f' [-Wdangling-pointer=]
   17 | e->f = this;
  | ~^~
: In function 'int main()':
:3:10: note: 'f2' declared here
3 | auto f2 = std::move(f1);
  |  ^~
:3:10: note: '.F::e' declared here

It would be helpful if Wdangling-pointer could realize that the stored address
will be cleared when the local variable is destroyed.

Here `g` is reduced from `boost::asio::detail::executor_function::complete` and
`F` is reduced from our own callback type.  The above reduced testcase only
repros at -O but our unreduced code repros at -O3.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Thomas Schwinge  ---
One concrete question, on example of:

(In reply to myself from comment #8)
> hard-code '-foffload-options=nvptx-none=-mptx=6.3\ -malias' to work around 
> GCC PR105018 "[nvptx] Need better alias support"

... this.

Simplified, the GCC/nvptx back end currently doesn't support symbol aliases.

Now, I found that there is a misconfiguration in the GCC/nvptx back end, so
that GCC proper thinks that it actually does support these even if the
experimental/limited support is disabled (details to be shared later).  This
means: with that GCC/nvptx back end misconfiguration fixed, I get libsupc++
built, and the GCC/C++ front end for nvptx target (real target, not offload
target!) works fine with the '!TARGET_SUPPORTS_ALIASES' configuration (just
like for other "embedded" targets, etc., I suppose).  For example, see
'gcc/cp/optimize.cc:can_alias_cdtor':

/* Returns true iff we can make the base and complete [cd]tor aliases of
   the same symbol rather than separate functions.  */

static bool
can_alias_cdtor (tree fn)
{
  /* If aliases aren't supported by the assembler, fail.  */
  if (!TARGET_SUPPORTS_ALIASES)
return false;
[...]

That's fine for GCC/C++ for nvptx target.  However, in a nvptx offload
configuration, the GCC/C++ front end runs on the host (x86_64-pc-linux-gnu or
whatever), and thus has a 'TARGET_SUPPORTS_ALIASES' configuration, and GCC/C++
front end happily generates symbol aliases -- which the nvptx offload
compilation then later falls over.

This problem (and I suspect a few other similar ones) could be avoided if the
GCC/C++ front end didn't look up target properties (such as
'TARGET_SUPPORTS_ALIASES'), and instead left such things in some "defer" state,
and they get resolved/lowered per actual target properties once the offloading
code stream has been spawned off.  (We've similarly changed a few other items,
where the lowering was "too early", as far as I remember.)  At that point then,
the host would decide for 'TARGET_SUPPORTS_ALIASES', and the nvptx offload
target would decide for '!TARGET_SUPPORTS_ALIASES', and lower the "defer"
construct as appropriate.  This of course is more difficult if the target
property causes more compilcated decisions in the GCC/C++ front end.

But, generally (and of course I understand it eventually has to be decided case
by case), is it acceptable to defer such early target property lookup until
later?  Of course, next problem then is potential missed optimizations due to
later lowering, diagnostics changes, and all these things, uh...

(Like, poison all "early" target macro etc. usage, and then selectively
re-enable when appropriate (data types have to match between host and offload
targets, etc.), and otherwise adjust code to resolve "late".  Sounds like a fun
multi-year project, doesn't it...)

Thoughts, on this specific example as well as generally?

[Bug c++/106412] New: Code initializing static variables with local variables compiles without errors or warnings

[menkaur at gmail dot com via Gcc-bugs]

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

Bug ID: 106412
   Summary: Code initializing static variables with local
variables compiles without errors or warnings
   Product: gcc
   Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: menkaur at gmail dot com
  Target Milestone: ---

Created attachment 53337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53337&action=edit
minimal code example

Following code will compile without errors or warnings:


 int main(int argc, char **argv) {
   int i = 0, j = 0;
   static const auto s = i + j;
   return 0;
  }


The bug was found in gcc 12.1.0 on arch linux

[Bug c++/106412] Code initializing static variables with local variables compiles without errors or warnings

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-22
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Arsen Zahray from comment #0)
> Following code will compile without errors or warnings:

Not true, there's a -Wunused-variable warning.

> The bug was found in gcc 12.1.0 on arch linux

Why do you think it's a bug? The code is valid.

[Bug analyzer/106413] New: State explosion on va_arg when va_start is in top-level function of analysis

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106413
   Summary: State explosion on va_arg when va_start is in
top-level function of analysis
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I accidentally introduced:
  FAIL: gcc.dg/analyzer/stdarg-3.c (test for excess errors)
in r13-1786-gb852aa7f265424; the issue is a -Wanalyzer-too-complex warning.

Looks like there's a state explosion in -fanalyzer whenever there's a loop that
calls __builtin_va_arg for the case where the va_start is in the top-level
function of the analysis (i.e. that we *don't* have a specific list of variadic
arguments).

[Bug c++/106412] Code initializing static variables with local variables compiles without errors or warnings

[menkaur at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Arsen Zahray  ---
> Why do you think it's a bug? The code is valid.
The bug I made with a code like this was that I first declared a static
const variable and used it in the program, later on I added local variables
on which the variable would depend, and I forgot to remove the static
modifier, which caused the variable to always have the same value. Static
variable is supposed to be initialized before local variables on the first
call to the function, and to me it seems that using local variables to
initialize it does not make any logical sense and is bug prone

On Fri, Jul 22, 2022 at 2:39 PM redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106412
>
> Jonathan Wakely  changed:
>
>What|Removed |Added
>
> 
>Last reconfirmed||2022-07-22
>  Status|UNCONFIRMED |WAITING
>  Ever confirmed|0   |1
>
> --- Comment #1 from Jonathan Wakely  ---
> (In reply to Arsen Zahray from comment #0)
> > Following code will compile without errors or warnings:
>
> Not true, there's a -Wunused-variable warning.
>
> > The bug was found in gcc 12.1.0 on arch linux
>
> Why do you think it's a bug? The code is valid.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/106412] Code initializing static variables with local variables compiles without errors or warnings

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
(In reply to Arsen Zahray from comment #2)
> Static
> variable is supposed to be initialized before local variables on the first
> call to the function

No, that's not true. It's initialized when control flow reaches it. If that is
after some local variables, then that's what happens.

This is not a bug.

[Bug fortran/106410] Internal compiler error: with nested parametrized types

[kargl at gcc dot gnu.org via Gcc-bugs]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Compiles with 

gfortran -c -O2 --version a.f90
GNU Fortran (GCC) 13.0.0 20220618 (experimental)

[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:36dd51bf87e1c533bf33ad3b16fd3fe06c356746

commit r11-10170-g36dd51bf87e1c533bf33ad3b16fd3fe06c356746
Author: Patrick Palka 
Date:   Fri Jul 22 12:52:03 2022 -0400

libstdc++: Fix backward compatibility of P2325R3 backport [PR106320]

The 11 and 10 partial backports of P2325R3, r11-9555-g92d6121eec and
r10-10808-g22b86cdc4d7fdd, unnecessarily preserved some changes from the
paper that made certain view specializations no longer default
constructible, changes which aren't required to reap the overall benefits
of the paper and which are backward incompatible with pre-P2325R3 code in
practice.

This patch reverts the problematic changes, specifically it relaxes the
constraints on various views' default constructors added by the paper
so that we keep only the constraints that were already implicitly
imposed by the NSDMIs of the view.  Thus for example this patch retains
the default_initializable<_Vp> constraint on transform_view's default
constructor since its '_Vp _M_base = _Vp()' NSDMI already requires this
constraint, and it removes the default_initializable<_Fp> constraint
since the corresponding member '__detail::__box<_Fp> _M_fun' doesn't
require default constructibility (specializations of __box are always
default constructible).

After reverting these changes, all static_asserts from p2325.cc that
verify lack of default constructibility now fail as expected, matching
the pre-P2325R3 behavior.

PR libstdc++/106320

libstdc++-v3/ChangeLog:

* include/std/ranges (single_view): Relax constraints on
default constructor so as to preserve pre-P2325R3 behavior.
(filter_view): Likewise.
(transform_view): Likewise.
(take_while_view): Likewise.
(drop_while_view): Likewise.
* testsuite/std/ranges/adaptors/join.cc (test13): New test.
* testsuite/std/ranges/p2325.cc: Fix S to be only non default
constructible and not also non copy constructible.  XFAIL the
tests that verify a non default constructible functor makes a
view non default constructible (lines 94, 97 and 98).  XFAIL
the test that effectively verifies a non default constructible
element type makes single_view non default constructible (line
114).

[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:2cad5c5c2de819b7a5177aa87e5e2fd088357b01

commit r10-10908-g2cad5c5c2de819b7a5177aa87e5e2fd088357b01
Author: Patrick Palka 
Date:   Fri Jul 22 12:52:03 2022 -0400

libstdc++: Fix backward compatibility of P2325R3 backport [PR106320]

The 11 and 10 partial backports of P2325R3, r11-9555-g92d6121eec and
r10-10808-g22b86cdc4d7fdd, unnecessarily preserved some changes from the
paper that made certain view specializations no longer default
constructible, changes which aren't required to reap the overall benefits
of the paper and which are backward incompatible with pre-P2325R3 code in
practice.

This patch reverts the problematic changes, specifically it relaxes the
constraints on various views' default constructors added by the paper
so that we keep only the constraints that were already implicitly
imposed by the NSDMIs of the view.  Thus for example this patch retains
the default_initializable<_Vp> constraint on transform_view's default
constructor since its '_Vp _M_base = _Vp()' NSDMI already requires this
constraint, and it removes the default_initializable<_Fp> constraint
since the corresponding member '__detail::__box<_Fp> _M_fun' doesn't
require default constructibility (specializations of __box are always
default constructible).

After reverting these changes, all static_asserts from p2325.cc that
verify lack of default constructibility now fail as expected, matching
the pre-P2325R3 behavior.

PR libstdc++/106320

libstdc++-v3/ChangeLog:

* include/std/ranges (single_view): Relax constraints on
default constructor so as to preserve pre-P2325R3 behavior.
(filter_view): Likewise.
(transform_view): Likewise.
(take_while_view): Likewise.
(drop_while_view): Likewise.
* testsuite/std/ranges/adaptors/join.cc (test13): New test.
* testsuite/std/ranges/p2325.cc: Fix S to be only non default
constructible and not also non copy constructible.  XFAIL the
tests that verify a non default constructible functor makes a
view non default constructible (lines 94, 97 and 98).  XFAIL
the test that effectively verifies a non default constructible
element type makes single_view non default constructible (line
114).

(cherry picked from commit 36dd51bf87e1c533bf33ad3b16fd3fe06c356746)

[Bug fortran/106410] Internal compiler error: with nested parametrized types

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-07-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from anlauf at gcc dot gnu.org ---
ICE confirmed on x86_64-pc-linux-gnu.

Not sure if the code is valid.

Intel rejects the code, as well as NAG.  Cray accepts it.

[Bug tree-optimization/106414] New: wrong code at -O1 and above on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106414
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

[672] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220722 (experimental) [master r13-1799-g41da4070a2a] (GCC) 
[673] % 
[673] % gcctk -O0 small.c; ./a.out
[674] % gcctk -O1 small.c
[675] % ./a.out
Aborted
[676] % cat small.c
int printf(const char *, ...);
int a, c, e;
const int b = 1;
char d;
int main() {
  a = ~(e || 0) ^ b & ~d;
  d = ~(a | ~2);
  if (d)
__builtin_abort();
  return 0;
}

[Bug tree-optimization/106415] New: loop-ivopts prevents correct usage of dbra with 16-bit loop counters on m68k

[undefinedopcode2 at gmail dot com via Gcc-bugs]

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

Bug ID: 106415
   Summary: loop-ivopts prevents correct usage of dbra with 16-bit
loop counters on m68k
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: undefinedopcode2 at gmail dot com
  Target Milestone: ---

Created attachment 53338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53338&action=edit
C file that reproduces the problem.

When targeting m68k and compiling certain loops with 16-bit counters that
should trivially generate a DBRA instruction, GCC's optimization passes end up
converting the IV to 32-bit, which  requires extra logic to check the upper
half. More specifically, these are loops where the number of iterations is
known at compile time.

This additional code is completely useless since we know the loop count fits in
16 bits.

I am using GCC 11.2.0 hosted on ARM64 macOS and targeting m68k. All code
snippets were compiled with `-O3 -std=c99 -march=68000 -mtune=68000`.

Consider the following function:
void dbra_test1(short i) {
do {
foo(i);
} while(--i != -1);
}

As expected, the generated body is a tiny loop consisting solely of call setup,
the call itself, call cleanup, and a DBRA:
.L2:
movew %d2,%a0
movel %a0,%sp@-
jsr %a2@
addql #4,%sp
dbra %d2,.L2

Now consider this function, where we change the initial value of the loop count
to be a constant:
void dbra_test2(void) {
short i = 15;
do {
foo(i);
} while(--i != -1);
}

GCC generates the following code for the body of the loop:
.L7:
movel %d2,%sp@-
jsr %a2@
addql #4,%sp
dbra %d2,.L7
clrw %d2
subql #1,%d2
jcc .L7

Note the extraneous clr/subq/jcc.

During ivcanon, GCC transforms the second loop to run from 16 to 0 instead of
15 to -1. Later during ivopts, it transforms back into 15 to -1 form, but
promotes the variable from short to int. Future transformations are no longer
able to optimize around the short variable, and we end up with extraneous
checks inserted during codegen.

I've attached a simple file that reproduces the problem. GCC 2.95.3 performed
the operation correctly, but it's been broken since at least 4.3.2, possibly
earlier.

Thanks
--UD2

[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)

[h2+bugs at fsfe dot org via Gcc-bugs]

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

--- Comment #8 from Hannes Hauswedell  ---
Thanks a lot for fixing this in a way that preserves the backport <3

[Bug fortran/106402] half preicision is not supported by gfortran(real*2).

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
See also thread at: https://gcc.gnu.org/pipermail/fortran/2022-May/057860.html

[Bug fortran/102818] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
The proper function name is diagnosed after the following patch:

diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 7a80dfd063b..0d0221fc3c4 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -2005,7 +2005,9 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus
*where)
gfc_error ("Symbol %qs at %L conflicts with symbol from module %qs, "
   "use-associated at %L", sym->name, where, sym->module,
   &sym->declared_at);
-  else if (sym->attr.function && sym->attr.result)
+  else if ((sym->attr.function && sym->attr.result)
+  || (sym->attr.flavor == FL_PROCEDURE
+  && sym->ns->proc_name && sym->ns->proc_name->name))
gfc_error ("Symbol %qs at %L already has basic type of %s",
   sym->ns->proc_name->name, where, gfc_basic_typename (type));
   else

I do not get an ICE, but valgrind suggests that error recovery is not clean.

[Bug tree-optimization/106415] loop-ivopts prevents correct usage of dbra with 16-bit loop counters on m68k

[undefinedopcode2 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Undefined Opcode  ---
Adding `-fno-tree-loop-ivcanon -fno-ivopts` to the compiler flags ensures the
second example function gets a properly optimized DBRA loop.

[Bug tree-optimization/106414] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu by r13-1779

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||rguenther at suse dot de
Summary|wrong code at -O1 and above |[13 Regression] wrong code
   |on x86_64-linux-gnu |at -O1 and above on
   ||x86_64-linux-gnu by
   ||r13-1779
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-22

--- Comment #1 from H.J. Lu  ---
It is caused by r13-1779

[Bug tree-optimization/106414] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu by r13-1779

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

Version|unknown |13.0
   Target Milestone|--- |13.0

[Bug fortran/106410] Internal compiler error: with nested parametrized types

[kargl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> ICE confirmed on x86_64-pc-linux-gnu.
> 
> Not sure if the code is valid.
> 
> Intel rejects the code, as well as NAG.  Cray accepts it.

Interestingly, I may have done an accidental bisection.

% gfcx -c --version a.f90
GNU Fortran (GCC) 13.0.0 20220621 (experimental)

This fails with an ICE.  The results reported in comment #1
are with gfortran on my laptop.  It may have a few unsubmitted
or committed patches.  I check later today.

[Bug analyzer/106394] False positive from -Wanalyzer-allocation-size with empty array

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tim Lange :

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

commit r13-1802-gb4cc945c045db74f719ab030969806c14e2d5fc3
Author: Tim Lange 
Date:   Fri Jul 22 21:44:07 2022 +0200

Fix handling of zero capacity regions in -Wanalyzer-allocation-size
[PR106394]

This patch unifies the handling of zero capacity regions for structs
and other types in the allocation size checker.
Regression-tested on x86_64 Linux.

2022-07-22  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106394
* region-model.cc (capacity_compatible_with_type): Always return
true
if alloc_size is zero.

gcc/testsuite/ChangeLog:

PR analyzer/106394
* gcc.dg/analyzer/pr106394.c: New test.

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

[tlange at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
Bug 106358 depends on bug 106394, which changed state.

Bug 106394 Summary: False positive from -Wanalyzer-allocation-size with empty 
array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106394

   What|Removed |Added

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