[Bug tree-optimization/101218] [12 Regression] ICE on valid code with -O3 only: Segmentation fault, vect_optimize_slp(vec_info*) since r12-1769-g82ab14927651e0ea

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

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

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

[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||cnsun at uwaterloo dot ca

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

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/101229] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2021-06-28
   Keywords||ice-on-valid-code
Version|tree-ssa|12.0
 Ever confirmed|0   |1

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

[Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-28
Summary|ice in  |[12 Regression] ice in
   |perform_or_defer_access_che |perform_or_defer_access_che
   |ck  |ck since
   ||r12-1804-g65870e75616ee435
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r12-1804-g65870e75616ee435.

[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements

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

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

--- Comment #5 from Richard Biener  ---
Ah, so what happens is that we elide the load permutation that feeds the
plus reduction originally but then we vectorize the live operands of the
minus reduction as BIT_FIELD_REFs ending up extracting the wrong lanes.

Testcase for x86_64:

/* { dg-additional-options "-ftree-slp-vectorize -ffast-math" } */

double a[2];
double x, y;

void __attribute__((noipa)) foo ()
{
  x = a[1] - a[0];
  y = a[0] + a[1];
}

int main()
{
  a[0] = 0.;
  a[1] = 1.;
  foo ();
  if (x != 1. || y != 1.)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11/12 Regression] evrp |[11/12 Regression] evrp
   |produces wrong code |produces wrong code since
   ||r11-3685-gfcae5121154d1c33
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r11-3685-gfcae5121154d1c33.

[Bug tree-optimization/101229] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Just for the record, started with r11-4428-g4a369d199bf2f34e.

[Bug c++/101233] ICE when using ::ranges::v3::to

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-28
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
Am I right, the code is invalid?

[Bug c++/101210] [9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2021-06-28

[Bug other/91085] fixincludes breaks

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #17 from Xi Ruoyao  ---
Revised patch, matching __has_include(...):

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573789.html

[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements

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

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

--- Comment #6 from Richard Biener  ---
Created attachment 51067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51067&action=edit
patch I am testing

[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Richard Biener from comment #6)
> Created attachment 51067 [details]
> patch I am testing

All of the tests now pass on aarch64-linux-gnu with this above patch.

[Bug libstdc++/101234] Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default.

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk  ---
(In reply to Ken Moffat from comment #0)
> In 22_locale/codecvt/out/wchar_t/3.cc and 22_locale/codecvt/in/wchar_t/3.cc
> the tests are only run if dejagnu finds the en_US.ISO-8859-15 locale. I
> assume that glibc used to install that when installing all locales (e.g.
> [https://centos.pkgs.org/8-stream/centos-baseos-x86_64/glibc-langpack-en-2.
> 28-155.el8.x86_64.rpm.html] implies that), but recent glibc does not
> automatically install it.

This locale was and is a Red Hat change, not something that used to be part of
official glibc:
.
This patch is still used by Red Hat now.

(Not that that means the test should continue using this locale.)

[Bug libstdc++/101236] New: [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’

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

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

Bug ID: 101236
   Summary: [12 Regression] bits/unique_ptr.h:658:48: error:
invalid use of incomplete type ‘class llvm::APFloat’
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jwakely at redhat dot com
  Target Milestone: ---

Created attachment 51068
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51068&action=edit
test-case

Happens when one builds something that uses libLLVM:

$ g++ AggregateToScalar.ii -c
In file included from /home/marxin/bin/gcc2/include/c++/12.0.0/memory:76,
 from /usr/include/llvm/ADT/SmallVector.h:30,
 from /usr/include/llvm/ADT/ArrayRef.h:14,
 from /usr/include/llvm/ADT/DenseMapInfo.h:18,
 from /usr/include/llvm/ADT/DenseMap.h:16,
 from
/home/marxin/Programming/cvise/clang_delta/AggregateToScalar.h:16,
 from
/home/marxin/Programming/cvise/clang_delta/AggregateToScalar.cpp:15:
/home/marxin/bin/gcc2/include/c++/12.0.0/bits/unique_ptr.h: In instantiation of
‘typename std::add_lvalue_reference<_Tp>::type std::unique_ptr<_Tp [],
_Dp>::operator[](std::size_t) const [with _Tp = llvm::APFloat; _Dp =
std::default_delete; typename
std::add_lvalue_reference<_Tp>::type = llvm::APFloat&; std::size_t = long
unsigned int]’:
/usr/include/llvm/ADT/APFloat.h:634:40:   required from here
/home/marxin/bin/gcc2/include/c++/12.0.0/bits/unique_ptr.h:658:48: error:
invalid use of incomplete type ‘class llvm::APFloat’
  658 |  
noexcept(noexcept(std::declval()[std::declval()]))
  | ~~~^
In file included from /usr/include/clang/AST/APValue.h:17,
 from /usr/include/clang/AST/Decl.h:16,
 from /usr/include/clang/AST/Attr.h:18,
 from /usr/include/clang/AST/RecursiveASTVisitor.h:16,
 from
/home/marxin/Programming/cvise/clang_delta/AggregateToScalar.cpp:19:
/usr/include/llvm/ADT/APFixedPoint.h:25:7: note: forward declaration of ‘class
llvm::APFloat’
   25 | class APFloat;
  |   ^~~

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[12 Regression] |[12 Regression]
   |bits/unique_ptr.h:658:48:   |bits/unique_ptr.h:658:48:
   |error: invalid use of   |error: invalid use of
   |incomplete type ‘class  |incomplete type ‘class
   |llvm::APFloat’  |llvm::APFloat’ since
   ||r12-1778-g17bc3848e065c0980
   ||523e1a1592f2f03b24b4f1c
   Last reconfirmed||2021-06-28
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c.

[Bug c++/101210] [9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 51069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51069&action=edit
gcc12-pr101210.patch

Untested fix.

[Bug c++/101210] [9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison

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

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

--- Comment #3 from Martin Liška  ---
You should Jakub likely use sanitize_flags_p rather than direct flag_sanitize?

[Bug c++/101210] [9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison

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

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

--- Comment #4 from Jakub Jelinek  ---
It should match what the FE is doing, and it uses
  if (TREE_CODE (stmt) == INTEGER_CST
  && TYPE_REF_P (TREE_TYPE (stmt))
  && (flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT))
  && !wtd->no_sanitize_p)

[Bug target/101235] [11/12 Regression] Fails to bootstrap with binutils 2.32

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

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

--- Comment #3 from Kewen Lin  ---
Will backport the fix after 2021 July 7th (two weeks since it's into trunk) if
this isn't urgent meanwhile got the backport approval.

[Bug c++/101210] [9/10/11/12 regression] spurious "reference binding to misaligned address" ubsan error for integer comparison

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

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

--- Comment #5 from Martin Liška  ---
You are right, it might be a location which I forgot to convert g:45ba13ea.

[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements

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

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

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

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

commit r12-1837-g2ad71efb5de9e929ffd2b8ce0a37c3c34021c0f1
Author: Richard Biener 
Date:   Mon Jun 28 09:42:58 2021 +0200

tree-optimization/101207 - fix BB reduc permute elide with life stmts

This fixes breakage of live lane extracts from permuted loads we elide
from BB reduction vectorization by handling the un-permuting the same
as in the regular eliding code - apply the reverse permute to
both the scalar stmts and the load permutation.

2021-06-28  Richard Biener  

PR tree-optimization/101207
* tree-vect-slp.c (vect_optimize_slp): Do BB reduction
permute eliding for load permutations properly.

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

[Bug tree-optimization/101207] [12 Regression] gcc.dg/vect/vect-strided-*-mult.c fails after SLP improvements

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/101227] Clang++ fails to instantiate std::optional if nested type has a non-static data member initializer

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

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

--- Comment #3 from Jonathan Wakely  ---
Yes. It's basically the same issue as PR 96645. Nested types and default member
initializers are not compatible with standard library wrapper types. Yet
another horrible corner of C++.

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #4 from Jonathan Wakely  ---
 requires TBB, as documented:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017

"Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018
or later. If the  header is included then -ltbb must be used to link
to TBB."

If you use the parallel algos (or just include their headers) then the TBB
headers are included. That's by design, they don't work otherwise. We can't do
anythign about the fact that Intel deprecated their own API shortly after using
contributing the PSTL headers to GCC, which depend on that API.

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug libstdc++/101203] Remove unnecessary empty check in std::function

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

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

--- Comment #4 from Jonathan Wakely  ---
You can't use std::function at all in those environments.

[Bug libstdc++/101234] Two tests require en_US.ISO-8859-15 but glibc no longer installs that by default.

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Looks like the testsuite is incorrect, it should have been 'en_US.ISO8859-15'

I think that's exactly equivalent, the extra dash is optional.

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

[doko at debian dot org via Gcc-bugs]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #5 from Matthias Klose  ---
No, the gcc packages don't depend on any tbb package.  Probably tbb needs an
update to a new upstream version in the distro.

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

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

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

--- Comment #6 from Jonathan Wakely  ---
There's no easy solution. Intel contributed the PSTL headers with a dependency
on TBB task.h header, then deprecated that header in a later TBB release. You
need to either use an older TBB, or suppress the warning.

There is a plan to add an OpenMP backend to PSTL, which will remove the TBB
dependency, but it's not ready yet.

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
You can use incomplete types with std::unique_ptr but the array
specialization, std::unique_ptr, requires T to be a complete type. See
[unique.ptr.runtime.general] p3 in the C++ standard. That requirement has been
there since std::unique_ptr was added in C++11.


So the code is invalid. LLVM needs to ensure the type is complete, or not use
std::unique_ptr there.

[Bug libgomp/100753] Implement in_reduction clause on target construct

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

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

--- Comment #1 from Jakub Jelinek  ---
Partly implemented in r12-1768-g7619d33471c10fe3d149dcbb701d99ed3dd23528
In particular the in_reduction without nowait is implemented and for nowait
there is a hack - presence of in_reduction acts as if nowait wasn't present.
That is hopefully valid, but certainly not desirable state, so extra work is
needed to make it work efficiently.

[Bug middle-end/101237] New: HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t)

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

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

Bug ID: 101237
   Summary: HONOR_SIGNED_ZEROS (element_mode (t)) should be moved
to just HONOR_SIGNED_ZEROS (t)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

This was found really because I copied the code from fold-const.c to match.pd
and there was a requested change as HONOR_SIGNED_ZEROS now handles tree types
too.
See https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573811.html

from a quick grep I find:
fold-const.c: || HONOR_SIGNED_ZEROS (element_mode (type))
fold-const.c:&& !HONOR_SIGNED_ZEROS (element_mode (type))
fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (type)))
fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (type)))
fold-const.c:  if (!HONOR_SIGNED_ZEROS (element_mode (type))
fold-const.c:  if (!HONOR_SIGNED_ZEROS (element_mode (type))
fold-const.c:  if (!HONOR_SIGNED_ZEROS (element_mode (type))
fold-const.c:  && !HONOR_SIGNED_ZEROS (element_mode (arg0))
fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (arg0))
fold-const.c:  && !HONOR_SIGNED_ZEROS (element_mode (arg0))
fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (op1)))
fold-const.c: && !HONOR_SIGNED_ZEROS (element_mode (op2)))
fold-const.c:  if (!HONOR_SIGNED_ZEROS (element_mode (type)))

[Bug driver/101238] New: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

Bug ID: 101238
   Summary: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need
-D__USE_MINGW_ACCESS
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas.kalibera at gmail dot com
  Target Milestone: ---

Created attachment 51070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51070&action=edit
Use -D__USE_MINGW_ACCESS when compiling the driver.

Summary: one needs to add CXXFLAGS+=-D__USE_MINGW_ACCESS to config/mh-mingw so
that the driver finds executables on Windows. This is already fixed in GCC 11,
but not in GCC 10.

More details: GCC 10 driver is compiled with g++ without-D__USE_MINGW_ACCESS on
MinGW. That option is only added to CFLAGS, but not CXXFLAGS. Consequently, the
driver will not find executables such as cc1, because access(,X_OK) will always
return an error on Windows, as access() on Windows does not check for
executability anymore. With __USE_MINGW_ACCESS, MinGW will use its own
implementation of access() which for X_OK behaves the same as R_OK.

I've tested the (trivial) attached patch and it resolved the issue on my system
as expected.

[Bug tree-optimization/101229] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

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

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

commit r12-1840-gf80c4eaca0805bc9e68ed944519519c3dd1c12e1
Author: Richard Biener 
Date:   Mon Jun 28 11:05:46 2021 +0200

tree-optimization/101229 - fix vectorizer SLP hybrid detection with PHIs

This fixes the missing handling of PHIs in gimple_walk_op which causes
the new vectorizer SLP hybrid detection scheme to fail.

2021-06-28  Richard Biener  

PR tree-optimization/101229
* gimple-walk.c (gimple_walk_op): Handle PHIs.

* gcc.dg/torture/pr101229.c: New testcase.

[Bug tree-optimization/101229] [11 Regression] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||12.0
  Known to fail||11.1.0
   Target Milestone|--- |11.2
Summary|ICE on valid code with -O3  |[11 Regression] ICE on
   |only: in|valid code with -O3 only:
   |vect_get_vec_defs_for_opera |in
   |nd, at  |vect_get_vec_defs_for_opera
   |tree-vect-stmts.c:1450  |nd, at
   ||tree-vect-stmts.c:1450

[Bug middle-end/101237] HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-06-28

--- Comment #1 from Andrew Pinski  ---
Looks like when HONOR_SIGNED_ZEROS of tree was added in r5-5768, a grep was
done on HONOR_SIGNED_ZEROS but for TYPE_MODE and had missed the grep on
element_mode .

Mine.

[Bug c++/101233] ICE when using ::ranges::v3::to

[475647575 at qq dot com via Gcc-bugs]

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

--- Comment #2 from 欢乐的0403 <475647575 at qq dot com> ---
This stumps me. I don't know if the code is valid or not.
But these code compiles:

v | ::ranges::v3::to;

v | ::ranges::v3::to_vector;


So I guess the code is more likely to be valid?

[Bug target/101235] [11/12 Regression] Fails to bootstrap with binutils 2.32

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

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

--- Comment #4 from Segher Boessenkool  ---
(In reply to Kewen Lin from comment #3)
> Will backport the fix after 2021 July 7th (two weeks since it's into trunk)
> if this isn't urgent meanwhile got the backport approval.

The reason to not backport immediately is because you end up with a
royal mess if your patch causes regressions.  A week is normally
plenty: there will be lots of test results that can give you
confidence things work.

If a patch caused build failures, we want that fixed as soon as
possible, because we will not have test results at all otherwise :-)

[Bug c++/101239] New: "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

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

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

Bug ID: 101239
   Summary: "Internal compiler error: Error reporting routines
re-entered." in size_in_bytes_loc
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This valid code produces an ICE:

template
struct Blerk
{
  template
static constexpr auto
type(Ptr p = Ptr(), int n = 0)
-> decltype(p[n])
{ return false; }

  template
static constexpr int
type(...)
{ return 1; }

  decltype(type()) f() const;
};

struct S;
extern Blerk p;
auto s = p.f();
struct S { };


ice.C: In substitution of 'template static constexpr decltype (p[n])
Blerk::type(Ptr, int) [with Ptr = S (*)[]]':
ice.C:15:20:   required from 'struct Blerk'
ice.C:20:11:   required from here
ice.C:7:18: error: invalid use of array with unspecified bounds
7 | -> decltype(p[n])
  | ~^
ice.C: In instantiation of 'struct Blerk':
ice.C:20:11:   required from here
ice.C:15:20: error: call of overloaded 'type()' is ambiguous
   15 |   decltype(type()) f() const;
  |^~
'
Internal compiler error: Error reporting routines re-entered.
0x138c3fd size_in_bytes_loc(unsigned int, tree_node const*)
/home/jwakely/src/gcc/gcc/gcc/tree.c:3486
0x138c3fd size_in_bytes_loc(unsigned int, tree_node const*)
/home/jwakely/src/gcc/gcc/gcc/tree.c:3474
0xb5b6ec pointer_int_sum(unsigned int, tree_code, tree_node*, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/c-family/c-common.c:3301
0xb3b078 cp_build_array_ref(unsigned int, tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:3708
0x8f2036 build_new_op_1
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6743
0x8f25ad build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:6772
0xb295df build_x_array_ref(unsigned int, tree_node*, tree_node*, int)
/home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:4385
0xaa51b4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:19874
0xac2677 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:16119
0x9b0580 dump_template_bindings
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:482
0x9a9ba7 dump_substitution
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:1638
0x9a9ba7 dump_substitution
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:1630
0x9a9ba7 dump_function_decl
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:1796
0x9b1a18 decl_to_string
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:3216
0x9b1a18 cp_printer
/home/jwakely/src/gcc/gcc/gcc/cp/error.c:4389
0x1c6ed6c pp_format(pretty_printer*, text_info*)
/home/jwakely/src/gcc/gcc/gcc/pretty-print.c:1475
0x1c52850 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.c:1275
0x1c556b7 diagnostic_impl
/home/jwakely/src/gcc/gcc/gcc/diagnostic.c:1437
0x1c556b7 inform(unsigned int, char const*, ...)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.c:1516
0x8e1cb6 print_z_candidate
/home/jwakely/src/gcc/gcc/gcc/cp/call.c:3782
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

--- Comment #3 from Martin Liška  ---
All right, thanks Jonathan.
I've just created LLVM bug for it: https://bugs.llvm.org/show_bug.cgi?id=50921

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-28

--- Comment #1 from Jonathan Wakely  ---
This slight variation using noexcept in the trailing-return-type was
rejects-valid in 4.7 but is ice-on-valid-code from 4.8 onwards (with the same
ICE):

template
struct Blerk
{
  template
static constexpr auto
type(Ptr p = Ptr(), int n = 0)
-> decltype(noexcept(p[n]))
{ return false; }

  template
static constexpr int
type(...)
{ return 1; }

  decltype(type()) f() const;
};

struct S;
extern Blerk p;
auto s = p.f();
struct S { };

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||101239

--- Comment #4 from Jonathan Wakely  ---
I tried this workaround in unique_ptr so that the undefined LLVM code would
"work" as before:

--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -491,6 +491,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  = __and_< is_base_of<_Tp, _Up>,
__not_, __remove_cv<_Up>>> >;

+  template
+   static constexpr auto
+   _S_nothrow_deref(_Ptr __p = _Ptr(), size_t __n = 0)
+   -> decltype(noexcept(__p[__n]))
+   { return noexcept(__p[__n]); }
+
+  template
+   static constexpr bool
+   _S_nothrow_deref(...)
+   { return noexcept(__p[__n]); }
+
 public:
   using pointer  = typename __uniq_ptr_impl<_Tp, _Dp>::pointer;
   using element_type  = _Tp;
@@ -654,8 +665,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   /// Access an element of owned array.
   typename std::add_lvalue_reference::type
-  operator[](size_t __i) const
-  noexcept(noexcept(std::declval()[std::declval()]))
+  operator[](size_t __i) const noexcept(_S_nothrow_deref())
   {
__glibcxx_assert(get() != pointer());
return get()[__i];


But this gets an ICE, see PR 101239


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239
[Bug 101239] "Internal compiler error: Error reporting routines re-entered." in
size_in_bytes_loc

[Bug c++/101233] ICE when using ::ranges::v3::to

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Keywords||ice-on-valid-code
 CC||jason at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Then let's mark it as ICE on valid code.

[Bug c++/101233] ICE when using ::ranges::v3::to

[475647575 at qq dot com via Gcc-bugs]

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

--- Comment #4 from 欢乐的0403 <475647575 at qq dot com> ---
Good, looking forward to it being fixed.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

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

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

--- Comment #4 from Aldy Hernandez  ---
d is used before being defined.  Isn't this entire test bogus?

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
d is not an automatic variable, so is zero initialized.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

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

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

--- Comment #6 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #5)
> d is not an automatic variable, so is zero initialized.

Whoops.  Sorry for the noise.

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Pilar Latiesa  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #7 from Pilar Latiesa  ---

This appears to be fixed upstream: https://reviews.llvm.org/D87380

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Resolution|INVALID |---

--- Comment #5 from Jonathan Wakely  ---
I have a working workaround. The LLVM code is undefined, but we can make it
work.

[Bug c++/101240] New: [missed optimization] Transitivity of less-than and less-or-equal

[kyrylo.bohdanenko at gmail dot com via Gcc-bugs]

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

Bug ID: 101240
   Summary: [missed optimization] Transitivity of less-than and
less-or-equal
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyrylo.bohdanenko at gmail dot com
  Target Milestone: ---

Consider the following C++ code

#define ALWAYS_TRUE(x) do { if (x) __builtin_unreachable(); } while (false)

int divide(int a, int b) {
  ALWAYS_TRUE(a == b);
  return a / b;
}

void test_array(unsigned (&arr)[3]) {
  ALWAYS_TRUE(a[0] < a[1] && a[1] < a[2]);
  return a[0] < a[2];
}

The first function is optimiozed away:

divide(int, int):
mov eax, 1
ret

While the second still does the comparison:

test_array(unsigned int (&) [3]):
mov eax, DWORD PTR [rdi+8]
cmp DWORD PTR [rdi], eax
setbal
ret

It would be nice if GCC could deduce that 

a < b && b < c --> a < c

And optimize that second function (provided no other UB is involved)

[Bug driver/93645] Support Clang 12 --ld-path=

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

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

--- Comment #10 from Martin Liška  ---
I replied here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573823.html

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[inkerman42 at gmail dot com via Gcc-bugs]

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

Piotr Engelking  changed:

   What|Removed |Added

 CC||inkerman42 at gmail dot com

--- Comment #24 from Piotr Engelking  ---
Created attachment 51071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51071&action=edit
not useful -Wsign-compare warning involving % operator

Another case where the feature would be useful:

extern int
f(short s, unsigned int u)
{
return s == u % 100;
}

It would be nice if the compiler noticed that rhs is always within 0..SHRT_MAX,
so the comparison is not surprisingly affected by integer promotion.

[Bug c++/101241] New: Internal compiler error from MathFunctions.h in the eigen library

[r.langer at itv dot rwth-aachen.de via Gcc-bugs]

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

Bug ID: 101241
   Summary: Internal compiler error from MathFunctions.h in the
eigen library
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r.langer at itv dot rwth-aachen.de
  Target Milestone: ---

I used a docker image of Clean Linux (version 34790) and installed gcc 11.1.1
with:

swupd bundle-add c-basic wget

The following commands produce the error:
wget https://gitlab.com/libeigen/eigen/-/archive/3.4-rc1/eigen-3.4-rc1.tar.bz2
tar -xf eigen-3.4-rc1.tar.bz2
printf "#include \n int main(int,char const*[]){}\n" >
eigen_bug.cpp
g++ eigen_bug.cpp -Ieigen-3.4-rc1/ -Ofast -ffast-math

Expected output from the last command:
In file included from eigen-3.4-rc1/Eigen/Core:171,
 from eigen_bug.cpp:1:
eigen-3.4-rc1/Eigen/src/Core/MathFunctions.h:1036:71: internal compiler error:
in maybe_default_option, at opts.c:332
 1036 | template<> EIGEN_TMP_NOOPT_ATTRIB bool isnan_impl(const long double& x)
{ return __builtin_isnan(x); }
  |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


The following works fine:
g++ eigen_bug.cpp -Ieigen-3.4-rc1/ -O3 -ffast-math

[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-1844-gb7a89c041aa1d67654f1ba7b2839e221c3e14748
Author: Jonathan Wakely 
Date:   Mon Jun 28 12:59:19 2021 +0100

libstdc++: Allow unique_ptr::operator[] [PR 101236]

PR libstdc++/101236 shows that LLVM depends on being able to use
unique_ptr::operator[] when T is incomplete. This is undefined, but
previously worked with libstdc++. When I added the conditional noexcept
to that operator we started to diagnose the incomplete type.

This change restores support for that case, by making the noexcept
condition check that the type is complete before checking whether
indexing on the pointer can throw.  A workaround for PR c++/101239 is
needed to avoid a bogus error where G++ fails to do SFINAE on the
ill-formed p[n] expression and gets an ICE. Instead of checking that the
p[n] expression is valid in the trailing-return-type, we only check that
the element_type is complete.

libstdc++-v3/ChangeLog:

PR libstdc++/101236
* include/bits/unique_ptr.h (unique_ptr::operator[]):
Fail gracefully if element_type is incomplete.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: Clarify that
the standard doesn't require this test to work for array types.
* testsuite/20_util/unique_ptr/lwg2762.cc: Check that incomplete
types can be used with array specialization.
* testsuite/20_util/unique_ptr/101236.cc: New test.

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-1844-gb7a89c041aa1d67654f1ba7b2839e221c3e14748
Author: Jonathan Wakely 
Date:   Mon Jun 28 12:59:19 2021 +0100

libstdc++: Allow unique_ptr::operator[] [PR 101236]

PR libstdc++/101236 shows that LLVM depends on being able to use
unique_ptr::operator[] when T is incomplete. This is undefined, but
previously worked with libstdc++. When I added the conditional noexcept
to that operator we started to diagnose the incomplete type.

This change restores support for that case, by making the noexcept
condition check that the type is complete before checking whether
indexing on the pointer can throw.  A workaround for PR c++/101239 is
needed to avoid a bogus error where G++ fails to do SFINAE on the
ill-formed p[n] expression and gets an ICE. Instead of checking that the
p[n] expression is valid in the trailing-return-type, we only check that
the element_type is complete.

libstdc++-v3/ChangeLog:

PR libstdc++/101236
* include/bits/unique_ptr.h (unique_ptr::operator[]):
Fail gracefully if element_type is incomplete.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: Clarify that
the standard doesn't require this test to work for array types.
* testsuite/20_util/unique_ptr/lwg2762.cc: Check that incomplete
types can be used with array specialization.
* testsuite/20_util/unique_ptr/101236.cc: New test.

[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=50921
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jonathan Wakely  ---
Fixed to accept the bad code.

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|MOVED   |---
 Status|RESOLVED|NEW
 CC||rodgertq at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
Tom, it looks like that fix landed upstream after our last sync. Should we use
it?

[Bug tree-optimization/101242] New: Segfault in SLP vectorizor after 2ad71efb5de

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

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

Bug ID: 101242
   Summary: Segfault in SLP vectorizor after 2ad71efb5de
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Since commit 2ad71efb5de (fix BB reduc permute elide with life stmts), the
following testcase (reduced from 433.milc) ICEs for me when compiled at -Ofast
(on x86_64-linux with generic march):

typedef struct {
  double real;
  double imag;
} complex;
typedef struct {
  complex e[3][3];
} su3_matrix;
su3_matrix check_su3_c;
double check_su3_ar, check_su3_ari, check_su3_max;
int arireturn();
int check_su3() {
  check_su3_ar = check_su3_c.e[0][0].real * check_su3_c.e[1][0].real +
 check_su3_c.e[0][0].imag * check_su3_c.e[1][0].imag +
 check_su3_c.e[0][1].real * check_su3_c.e[1][1].real +
 check_su3_c.e[0][1].imag * check_su3_c.e[1][1].imag +
 check_su3_c.e[0][2].real * check_su3_c.e[1][2].real +
 check_su3_c.e[0][2].imag * check_su3_c.e[1][2].imag;
  check_su3_max = check_su3_c.e[0][0].real * check_su3_c.e[2][0].real +
  check_su3_c.e[0][0].imag * check_su3_c.e[2][0].imag +
  check_su3_c.e[0][1].real * check_su3_c.e[2][1].real +
  check_su3_c.e[0][1].imag * check_su3_c.e[2][1].imag +
  check_su3_c.e[0][2].real * check_su3_c.e[2][2].real +
  check_su3_c.e[0][2].imag * check_su3_c.e[2][2].imag;
  check_su3_ari = check_su3_ar;
  if (check_su3_ari)
check_su3_max = check_su3_c.e[1][0].real * check_su3_c.e[2][0].real +
check_su3_c.e[1][0].imag * check_su3_c.e[2][0].imag +
check_su3_c.e[1][1].real * check_su3_c.e[2][1].real +
check_su3_c.e[1][1].imag * check_su3_c.e[2][1].imag +
check_su3_c.e[1][2].real * check_su3_c.e[2][2].real +
check_su3_c.e[1][2].imag * check_su3_c.e[2][2].imag;
  if (check_su3_max)
arireturn();
  return 0;
}

[Bug tree-optimization/101242] Segfault in SLP vectorizor after 2ad71efb5de

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

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

--- Comment #1 from Martin Jambor  ---
For the reference, this is the backtrace:

mjambor@virgil:/tmp/bbb$ ~/gcc/trunk/inst/bin/gcc -S -Ofast test.i 
during GIMPLE pass: slp
test.i: In function ‘check_su3’:
test.i:11:5: internal compiler error: Segmentation fault
   11 | int check_su3() {
  | ^
0x12ad5a0 crash_signal
/home/mjambor/gcc/trunk/src/gcc/toplev.c:327
0x162643d vec<_stmt_vec_info*, va_heap, vl_embed>::iterate(unsigned int,
_stmt_vec_info**) const
/home/mjambor/gcc/trunk/src/gcc/vec.h:932
0x1625168 vec<_stmt_vec_info*, va_heap, vl_ptr>::iterate(unsigned int,
_stmt_vec_info**) const
/home/mjambor/gcc/trunk/src/gcc/vec.h:1698
0x166d14d vect_optimize_slp(vec_info*)
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:3992
0x1672d1e vect_slp_analyze_bb_1
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5621
0x1673111 vect_slp_region
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5708
0x1673bba vect_slp_bbs
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5858
0x1674063 vect_slp_function(function*)
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:5944
0x168f92b execute
/home/mjambor/gcc/trunk/src/gcc/tree-vectorizer.c:1445
Please submit a full bug report...

[Bug tree-optimization/101242] Segfault in SLP vectorizor after g:2ad71efb5de

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Segfault in SLP vectorizor  |Segfault in SLP vectorizor
   |after 2ad71efb5de   |after g:2ad71efb5de
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-28
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |12.0

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug c++/101243] New: Coroutine lambda capture is destroyed twice

[victor.burckel at gmail dot com via Gcc-bugs]

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

Bug ID: 101243
   Summary: Coroutine lambda capture is destroyed twice
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

In a corourtine expecting a std::function parameter, passing a
temporary lambda with a capture results in the capture being destroyed twice:
See it on gldbolt, gcc vs clang outputs
https://godbolt.org/z/jx9Yh5cqM

#include 

#include 
#include 

#ifdef __clang__
namespace std::experimental {
using std::coroutine_handle;
using std::coroutine_traits;
}  // namespace std::experimental
#endif

struct task {
  struct promise_type;
  using handle_type = std::coroutine_handle;

  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_void() noexcept {}
task get_return_object() noexcept {
  return task{handle_type::from_promise(*this)};
}
void unhandled_exception() noexcept {}
  };

  task(handle_type h) : h{h} {}
  ~task() {
if (h) {
  fmt::print("destroying coroutine\n");
  h.destroy();
  fmt::print("coroutine destroyed\n");
}
  }

  bool await_ready() const noexcept { return false; }
  bool await_suspend(std::coroutine_handle<>) noexcept {
h.resume();
return true;
  }
  void await_resume() noexcept {}

  void resume() { h.resume(); }

  handle_type h;
};

struct S {
  S() { fmt::print("S::S()\n"); }
  S(const S&) { fmt::print("S::S(const S&)\n"); }
  S(S&&) { fmt::print("S::S(S&&)\n"); }
  ~S() { fmt::print("S::~S()\n"); }
};

task g(std::function) {
  fmt::print("in g()\n");
  co_return;
}

task f() {
  fmt::print("calling g()\n");
  co_await g([s=S{}] {});
  fmt::print("g called\n");
}

int main() {
  auto task = f();
  fmt::print("resuming f\n");
  task.resume();
  fmt::print("resuming f\n");
  task.resume();
}

Gcc outputs:
resuming f
calling g()
S::S()
S::S(S&&)
in g()
resuming f
destroying coroutine
S::~S()
coroutine destroyed
S::~S()
S::~S()
g called
destroying coroutine
coroutine destroyed

While clang outputs:
resuming f
calling g()
S::S()
S::S(S&&)
in g()
resuming f
destroying coroutine
S::~S()
coroutine destroyed
S::~S()
g called
destroying coroutine
coroutine destroyed

[Bug c++/101243] Coroutine lambda capture is destroyed twice

[victor.burckel at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Victor Burckel  ---
May be similar to 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401

[Bug c++/101244] New: Wrong path in coroutine returning ternary

[victor.burckel at gmail dot com via Gcc-bugs]

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

Bug ID: 101244
   Summary: Wrong path in coroutine returning ternary
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.burckel at gmail dot com
  Target Milestone: ---

In a coroutine returning a ternary expression with co_await, the co_await part
seems to be evaluated whatever the result of the condition:
See it on godbolt, I added a check of coro.done in the resume operation to
avoid a crash in the clang part as the coroutine is voluntarily resumed one
extra time
https://godbolt.org/z/vzGKoP8d3

#include 

#include 
#include 

#ifdef __clang__
namespace std::experimental {
using std::coroutine_handle;
using std::coroutine_traits;
}  // namespace std::experimental
#endif

struct task {
  struct promise_type;
  using handle_type = std::coroutine_handle;

  struct promise_type {
auto initial_suspend() noexcept { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_value(int v) noexcept { value = v; }
task get_return_object() noexcept {
  return task{handle_type::from_promise(*this)};
}
void unhandled_exception() noexcept {}

int value{};
  };

  task(handle_type h) : h{h} {}
  ~task() {
if (h) {
  fmt::print("destroying coroutine\n");
  h.destroy();
  fmt::print("coroutine destroyed\n");
}
  }

  bool await_ready() const noexcept { return false; }
  bool await_suspend(std::coroutine_handle<>) noexcept {
h.resume();
return true;
  }
  int await_resume() noexcept { return h.promise().value; }

  void resume() {
if (!h.done()) h.resume();
  }

  handle_type h;
};

struct S {
  S() { fmt::print("S::S()\n"); }
  S(const S&) { fmt::print("S::S(const S&)\n"); }
  S(S&&) { fmt::print("S::S(S&&)\n"); }
  ~S() { fmt::print("S::~S()\n"); }
};

task g(S) {
  fmt::print("in g()\n");
  co_return 1;
}

task f(bool b) {
  fmt::print("calling g()\n");
  co_return b ? co_await g(S{}) : 2;
}

int main() {
  auto task = f(false);
  fmt::print("resuming f\n");
  task.resume();
  fmt::print("resuming f\n");
  task.resume();
}

Gcc outputs
resuming f
calling g()
S::S()
S::S(S&&)
in g()
resuming f
destroying coroutine
S::~S()
coroutine destroyed
S::~S()
destroying coroutine
coroutine destroyed

While clang outputs
resuming f
calling g()
resuming f
destroying coroutine
coroutine destroyed

[Bug c++/101244] Wrong path in coroutine returning ternary

[victor.burckel at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Victor Burckel  ---
If ternary is not put in the co_return part but split into assignement return,
the compiler crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101149

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

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

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

--- Comment #25 from Matthias Kretz (Vir)  ---
(In reply to Piotr Engelking from comment #24)
> It would be nice if the compiler noticed that rhs is always within
> 0..SHRT_MAX, so the comparison is not surprisingly affected by integer
> promotion.

The problem is the LHS which can be negative and has to be promoted to
`unsigned int`. This promotion changes the value from s to UINT_MAX + 1 + s. I
don't think this example is a case where -Wsign-compare should be silent.

[Bug libgomp/100753] Implement in_reduction clause on target construct

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

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

--- Comment #2 from Tobias Burnus  ---
Additionally missing: Fortran support.

[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Can you provide the preprocessed source?  Use -save-temps to get it.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #26 from Vincent Lefèvre  ---
(In reply to Matthias Kretz (Vir) from comment #25)
> (In reply to Piotr Engelking from comment #24)
> > It would be nice if the compiler noticed that rhs is always within
> > 0..SHRT_MAX, so the comparison is not surprisingly affected by integer
^^^
> > promotion.
> 
> The problem is the LHS which can be negative and has to be promoted to
> `unsigned int`. This promotion changes the value from s to UINT_MAX + 1 + s.
> I don't think this example is a case where -Wsign-compare should be silent.

But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the
range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said
otherwise, the promotion has no visible effect here (if s is negative, then the
comparison will be false, as if promotion did not occur), so that there is no
need to warn.

That said, this is very specific code, and it might not be worth to handle it.
And IMHO, this is more than what this PR is about.

[Bug tree-optimization/101223] [11/12 Regression] evrp produces wrong code since r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
I think this is our old friend 1-bit signed overflow.

for 1 signed bit values, varying is [-1, 0]  

range-op::build_lt checks to see if UB - 1 overflows, and if it does, then the
result is undefined.

wi::sub  sets the overflow flag for 0 - 1 with 1 bit signed...   so the
comparison ends up being undefined, and we then make incorrect choices because
we think we can.

I think we need to, yet again, special case 1-bit signed values here, and
probably in build_gt as well.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

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

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

--- Comment #27 from Matthias Kretz (Vir)  ---
(In reply to Vincent Lefèvre from comment #26)
> But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the
> range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said
> otherwise, the promotion has no visible effect here (if s is negative, then
> the comparison will be false, as if promotion did not occur), so that there
> is no need to warn.

Fair enough. But how can the compiler be certain that the developer realized u
and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation was
for the RHS to be within [-99..99].

> That said, this is very specific code, and it might not be worth to handle
> it. And IMHO, this is more than what this PR is about.

I tend to agree. It's a slightly different problem and IMHO not a 100% obvious
false positive.

I believe this PR should be about dropping the warning where signed -> unsigned
promotion or implicit conversion cannot change the value because the value
range of the signed variable is limited to values >= 0.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #28 from Vincent Lefèvre  ---
(In reply to Matthias Kretz (Vir) from comment #27)
> Fair enough. But how can the compiler be certain that the developer realized
> u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation
> was for the RHS to be within [-99..99].

Indeed. (I never use % when its LHS can be either positive or negative, so that
I didn't think about this case.)

Now, the cause of the bug in such a case would be that the user messed up with
the signedness of u, not because he forgot about the promotion rule. This is
something rather different.

[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-06-28
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org

[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library

[r.langer at itv dot rwth-aachen.de via Gcc-bugs]

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

--- Comment #2 from Raymond Langer  ---
Created attachment 51072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51072&action=edit
preprocessed output

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

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

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

--- Comment #29 from Matthias Kretz (Vir)  ---
(In reply to Vincent Lefèvre from comment #28)
> (In reply to Matthias Kretz (Vir) from comment #27)
> > Fair enough. But how can the compiler be certain that the developer realized
> > u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation
> > was for the RHS to be within [-99..99].
> 
> Indeed. (I never use % when its LHS can be either positive or negative, so
> that I didn't think about this case.)

FWIW, personally I could use a warning whenever I use % on variables that can
potentially be negative. Because my mental model of % N is that I get a result
in [0..N-1]. I tried to fix it but my head is stubborn. ;)

> Now, the cause of the bug in such a case would be that the user messed up
> with the signedness of u, not because he forgot about the promotion rule.
> This is something rather different.

Right. But if that's the case wouldn't a warning about the unexpected promotion
be useful? (which -Wsign-compare happens to provide)

To reduce the noise, I won't argue this point any further and let whoever
actually implements a fix for the PR decide. :)

[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:75f948f089cebfd00913635264e20610d0f2

commit r12-1845-g75f948f089cebfd00913635264e20610d0f2
Author: Jonathan Wakely 
Date:   Mon Jun 28 15:13:34 2021 +0100

libstdc++: Fix backwards logic in 17_intro/names.cc test [PR 97088]

I meant to undef the names that clash with newlib headers for newlib,
but I only undef'd them for non-newlib targets. This means they still
cause errors for newlib, and aren't tested for other targets.

This fixes the test to check those names for non-newlib targets, and to
undef them to avoid errors for newlib.

libstdc++-v3/ChangeLog:

PR libstdc++/97088
* testsuite/17_intro/names.cc: Fix #if condition for names used
by newlib headers.

[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library

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

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

--- Comment #3 from Marek Polacek  ---
I cannot reproduce this:

$ xg++ -c a-eigen_bug.ii -O3 -ffast-math -march=haswell
compiles.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #30 from Vincent Lefèvre  ---
(In reply to Matthias Kretz (Vir) from comment #29)
> Right. But if that's the case wouldn't a warning about the unexpected
> promotion be useful? (which -Wsign-compare happens to provide)

Yes, and FYI, there were such platform-dependent bugs in GNU MPFR in the past
involving additions or subtractions (not comparisons). I added the following in
its README.dev file:

--
Avoid mixing signed and unsigned integer types, as this can lead signed
types to be automatically converted into unsigned types (usual arithmetic
conversions). If such a signed type contains a negative value, the result
may be incorrect on some platforms. With MPFR 2.x, this problem could
arise with mpfr_exp_t, which is signed, and mpfr_prec_t (mp_prec_t),
which was unsigned (it is now signed), meaning that in general, a cast
of a mpfr_prec_t to a mpfr_exp_t was needed.

Note that such bugs are difficult to detect because they may depend on
the platform (e.g., on LP64, 32-bit unsigned int + 64-bit long will give
a signed type, but on ILP32, 32-bit int + 32-bit unsigned long will give
an unsigned type, which may not be what is expected), but also on the
input values. So, do not rely on tests very much. However, if a test
works on 32 bits but fails on 64 bits in the extended exponent range
(or conversely), the cause may be related to the integer types (e.g. a
signness problem or an integer overflow due to different type sizes).

For instance, in MPFR, such issues were fixed in r1992 and r5588.

An example that will fail with 32-bit int and long:

long long umd(void)
{
  long a = 1;
  unsigned int b = 2;
  return a - b;
}
--

So a warning for such operations would also be useful. But I'm not sure about
potential issues with false positives...

[Bug ipa/93385] [10/11/12 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

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

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

--- Comment #45 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:87467f45e831e8e943efdae8920453741986d355

commit r12-1847-g87467f45e831e8e943efdae8920453741986d355
Author: Martin Jambor 
Date:   Mon Jun 28 18:20:00 2021 +0200

ipa-sra: Restructure how cloning and call redirection communicate (PR
93385)

I was asked by Richi to split my fix for PR 93385 for easier review
into IPA-SRA materialization refactoring and the actual DCE addition.
Fortunately it was mostly natural except for a temporary weird
condition in ipa_param_body_adjustments::modify_call_stmt.
Additionally.  In addition to the patch I posted previously, this one
also deallocated the newly added summary in toplev::finalize and fixes
a mistakenly uninitialized field.

This is the first part which basically replaces performed_splits in
clone_info and the code which generates it, keeps it up-to-date and
consumes it with new edge summaries which are much nicer.  It simply
contains 1) a mapping from the original argument indices to the actual
indices in the call statement as it is now, 2) information needed to
identify arguments representing pass-through IPA-SRA splits with which
have been added to the call arguments in place of an original
argument/reference and 3) a delta to the index where va_args may start
- so basically directly all the information that the consumer of
performed_splits had to compute and we also do not need the weird
dummy declarations.

The main disadvantage is that the information has to be created (and
kept up-to-date) for all call graph edges associated with the given
statement from all clones (including inline clones) of the clone where
splitting or removal happened first.  But all of this happens during
clone materialization so the only effect on WPA memory consumption is
the removal of a pointer from clone_info.

The statement modification code also has to know the statement from
the original function in order to be able to locate the edge summaries
which at this point are still keyed to these.  However, the code is
already quite heavily dependant on how things are structured in
tree-inline.c and in order to fix bugs like these it probably has to
be.

The subsequent patch needs this new information to be able to remove
arguments from calls during materialization and communicate this
information to the call redirection.

gcc/ChangeLog:

2021-05-17  Martin Jambor  

PR ipa/93385
* symtab-clones.h (clone_info): Removed member param_adjustments.
* ipa-param-manipulation.h: Adjust initial comment to reflect how
we
deal with pass-through splits now.
(ipa_param_performed_split): Removed.
(ipa_param_adjustments::modify_call): Adjusted parameters.
(class ipa_param_body_adjustments): Adjusted parameters of
register_replacement, modify_gimple_stmt and modify_call_stmt.
(ipa_verify_edge_has_no_modifications): Declare.
(ipa_edge_modifications_finalize): Declare.
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Remove
performed_splits processing, pas only edge to padjs->modify_call,
check that call arguments were not modified if they should not have
been.
* cgraphclones.c (cgraph_node::create_clone): Do not copy performed
splits.
* ipa-param-manipulation.c (struct pass_through_split_map): New
type.
(ipa_edge_modification_info): Likewise.
(ipa_edge_modification_sum): Likewise.
(ipa_edge_modifications): New edge summary.
(ipa_verify_edge_has_no_modifications): New function.
(transitive_split_p): Removed.
(transitive_split_map): Likewise.
(init_transitive_splits): Likewise.
(ipa_param_adjustments::modify_call): Adjusted to use the new edge
summary instead of performed_splits.
(ipa_param_body_adjustments::register_replacement): Drop dummy
parameter, set base_index of the created
ipa_param_body_replacement.
(phi_arg_will_live_p): New function.
(ipa_param_body_adjustments::common_initialization): Do not create
IPA_SRA dummy decls.
(simple_tree_swap_info): Removed.
(remap_split_decl_to_dummy): Likewise.
(record_argument_state_1): New function.
(record_argument_state): Likewise.
(ipa_param_body_adjustments::modify_call_stmt): New parameter
orig_stmt.  Do not work with dummy decls, save necessary info about
changes to ipa_edge_modifications.
(ipa_param_body_adjustments::modify_gimple_stmt): New parameter
orig_stmt, pass i

[Bug ipa/93385] [10/11/12 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

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

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

--- Comment #46 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:2902991a6b61d473f7cb996a2b80eef4a90f8eda

commit r12-1848-g2902991a6b61d473f7cb996a2b80eef4a90f8eda
Author: Martin Jambor 
Date:   Mon Jun 28 18:20:00 2021 +0200

ipa-sra: Introduce a mini-DCE to tree-inline.c (PR 93385)

I was asked by Richi to split my fix for PR 93385 for easier review
into IPA-SRA materialization refactoring and the actual DCE addition.
This is the second part that actually contains the DCE of statements
that IPA-SRA should not leave behind because they can have problematic
side effects, even if they are useless, so that we do not depend on
tree-dce to remove them for correctness.

The patch fixes the problem by doing a def-use walk when materializing
clones, marking which statements should not be copied and which
SSA_NAMEs do not need to be computed because eventually they would be
DCEd.  We do this on the original function body and tree-inline simply
does not copy statements which are "dead."

The only complication is removing dead argument calls because that
needs to be communicated to callee redirection code using the
infrastructure introduced by the previous patch.

I added all testcases of the original patch to this one, although some
probably test behavior introduced in the previous patch.

gcc/ChangeLog:

2021-05-12  Martin Jambor  

PR ipa/93385
* ipa-param-manipulation.h (class ipa_param_body_adjustments): New
members m_dead_stmts and m_dead_ssas.
* ipa-param-manipulation.c
(ipa_param_body_adjustments::mark_dead_statements): New function.
(ipa_param_body_adjustments::common_initialization): Call it on
all removed but not split parameters.
(ipa_param_body_adjustments::ipa_param_body_adjustments):
Initialize
new mwmbers.
(ipa_param_body_adjustments::modify_call_stmt): Remove arguments
that
are dead.
* tree-inline.c (remap_gimple_stmt): Do not copy dead statements,
reset
dead debug statements.
(copy_phis_for_bb): Do not copy dead PHI nodes.

gcc/testsuite/ChangeLog:

2021-03-22  Martin Jambor  

PR ipa/93385
* gcc.dg/ipa/pr93385.c: New test.
* gcc.dg/ipa/ipa-sra-23.c: Likewise.
* gcc.dg/ipa/ipa-sra-24.c: Likewise.
* g++.dg/ipa/ipa-sra-4.C: Likewise.

[Bug c++/58050] No return value optimization when calling static function through unnamed temporary

[antoshkka at gmail dot com via Gcc-bugs]

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

Antony Polukhin  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #1 from Antony Polukhin  ---
This was fixed in GCC-10.1 https://godbolt.org/z/b4ohfnK3x

[Bug c++/58487] Missed return value optimization

[antoshkka at gmail dot com via Gcc-bugs]

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

Antony Polukhin  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #3 from Antony Polukhin  ---
Minimized example, move constructor should not be called:

struct A {
  A() = default;
  A(A&&);
};

A test() {
  if (true) {
A a;
return a;
  } else {
return A{};
  }
}


Godbolt playground: https://godbolt.org/z/4Pzq83WWY

[Bug target/98784] [9/10/11/12 Regression] problematic build of uClibc with -fPIC

[yann at sionneau dot net via Gcc-bugs]

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

--- Comment #13 from YannSionneau  ---
Created attachment 51073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51073&action=edit
working uClibc build

This is a working libc build, that allows to boot Linux, run init, daemons and
get to usual shell prompt.

[Bug target/98784] [9/10/11/12 Regression] problematic build of uClibc with -fPIC

[yann at sionneau dot net via Gcc-bugs]

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

--- Comment #14 from YannSionneau  ---
Created attachment 51074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51074&action=edit
non-working uClibc-ng build

This is a build of uClibc-ng that does not allow normal Linux booting.
You can boot to a shell by doing init=/bin/sh but any command you type (like
ls) would run the command and then crash the system because init (in fact the
shell, the parent of the forked command) gets killed.

This might be related to issue in signal handling since the parent is supposed
to receive a SIGCHILD signal when its child exits.

Difference with previous attachment is just that the follow buildroot patch is
not applied to gcc:
https://git.buildroot.net/buildroot/commit/?id=4d16e6f5324f0285f51bfbb5a3503584f3b3ad12

[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library

[r.langer at itv dot rwth-aachen.de via Gcc-bugs]

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

--- Comment #4 from Raymond Langer  ---
(In reply to Marek Polacek from comment #3)
> I cannot reproduce this:
> 
> $ xg++ -c a-eigen_bug.ii -O3 -ffast-math -march=haswell
> compiles.

Yes, 
g++ -c a-eigen_bug.ii -O3 -ffast-math -march=haswell
compiles.

However, -Ofast does not work together with -ffast-math:
g++ -c a-eigen_bug.ii -Ofast -ffast-math -march=haswell

[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library

[r.langer at itv dot rwth-aachen.de via Gcc-bugs]

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

--- Comment #5 from Raymond Langer  ---
Using only -Ofast doesn't work either:
g++ -c a-eigen_bug.ii -Ofast

[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.

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

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

Thomas Rodgers  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rodgertq at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #9 from Thomas Rodgers  ---
Yes (I already reviewed it when it arrived upstream). It is probably also safe
to backport to GCC-11 since there's no ABI or ABI stability concerns. I will
have a go at applying *just* this patch (I don't want to commit to trying a
full rebase against upstream at this point).

[Bug c/98892] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c

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

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

--- Comment #4 from Jim Wilson  ---
It turns out that -fmessage-length=0 doesn't work which is odd.  I suspect a
latent bug in the diagnostic code.

I tried -fmessage-length=128, which should work as that is longer than the
error line, and does work for this failure, but that causes a different line to
fail.  Turns out that there is a test that emits a 2.3KB error message.  To
make the entire testcase work, I need a -fmessage-length value longer than the
longest error message, so the smallest power of 2 that works is
-fmessage-length=4096 which seems too stupid to submit as a patch.

[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
   |code with u128 modulo at|code with u128 modulo at
   |-O2 -fno-dce -fno-ipa-cp|-O2 -fno-dce -fno-ipa-cp
   |-fno-tree-dce   |-fno-tree-dce

--- Comment #47 from Martin Jambor  ---
Fixed on master.

Given the size of the fix, it is clearly not suitable for backporting.  This
bug is likely to remain unfixed on GCC 10 and 11, which however should not hurt
anybody who does not explicitly disable DCE.  (An unappealing but realistic
alternative is to add the bail out from comment #11 to those branches.)

[Bug tree-optimization/101242] Segfault in SLP vectorizor after g:2ad71efb5de

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

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

--- Comment #3 from Martin Jambor  ---
Profiled LTO bootstrap also fails with a segfault with the same backtrace.

[Bug c++/101241] Internal compiler error from MathFunctions.h in the eigen library

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Can't reproduce with -Ofast -ffast-math -march=haswell either.

[Bug c++/101243] Coroutine lambda capture is destroyed twice

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Victor Burckel from comment #1)
> May be similar to 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401

I agree this is likely to be a duplicate ( I am in the process of reviewing
coros bugs)

[Bug bootstrap/101245] New: Bootstrap fails for a combined tree with --enable-shared

[christoph.hoeger at celeraone dot com via Gcc-bugs]

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

Bug ID: 101245
   Summary: Bootstrap fails for a combined tree with
--enable-shared
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.hoeger at celeraone dot com
  Target Milestone: ---

Created attachment 51075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51075&action=edit
Reproduction build script

I tried to bootstrap gcc 11.1.0 with binutils 2.36.1 in a combined tree and the
build fails in stage2 when building libiberty.

The failure stems from as not finding its shared libraries (opcode and bfd).
The RPATH is set wrong:

➜  test2 readelf -d build/prev-gas/.libs/lt-as-new | grep RPATH
 0x000f (RPATH)  Library rpath:
[/home/choeger/c1/scratch/gcc-combined/test2/build/opcodes/.libs:/home/choeger/c1/scratch/gcc-combined/test2/build/bfd/.libs:/usr/local/lib]
➜  test2

As you can see, the RPATH is not reset to the prev- directories.

➜  test2 build/prev-gas/as-new 
/home/choeger/c1/scratch/gcc-combined/test2/build/prev-gas/.libs/lt-as-new:
error while loading shared libraries: libopcodes-2.36.1.so: cannot open shared
object file: No such file or directory

Find attached a script to reproduce the issue.

[Bug go/101246] New: gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng

[lancethepants at gmail dot com via Gcc-bugs]

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

Bug ID: 101246
   Summary: gccgo cross-compiler targeting arm fails to build with
gcc 11. Missing structs in runtime.inc. Using
uclibc-ng
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: lancethepants at gmail dot com
CC: cmang at google dot com
  Target Milestone: ---

I've recently run into an issue building a go cross-compiler on x86_64
targeting an arm embedded device (Netgear R7000 router) starting with gcc 11.

I was previously able to build the cross-compiler (c,c++,go) under gcc 9 & 10,
but am getting the errors listed at the bottom.

armv7 cortexa9 cpu (no fpu)
uclibc-ng (latest)
kernel 2.6.36.4.

I don't think the old kernel is an issue because the same errors arise if I use
kernel 5.12.  

I tried building with glibc, and it does work then. So I think the issue is
with uclibc-ng.

So I did use uclibc-ng with gcc 9 & 10 with success, but for some reason with
gcc 11 I am now running into this issue.

My untrained eyes think it may be as easy as a couple missing structs within
runtime.inc.   Is runtime.inc generated? because it doesn't appear in
unconfigured source I've notices.

thanks,
Lance

Build Errors
In file included from ../../../libgo/runtime/runtime.h:105,
  from ../../../libgo/runtime/go-main.c:17:
./runtime.inc:1357:29: error: field ‘__state’ has incomplete type
  1357 | struct ___mbstate_t __state;
   | ^~~
./runtime.inc:1360:33: error: field ‘__lock’ has incomplete type
  1360 | struct _pthread_mutex_t __lock;
   |

[Bug tree-optimization/101186] predictable comparison of integer variables not folded

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #6 from Jeffrey A. Law  ---
I wonder why we don't unswitch the loop twice to pull both conditionals out. 
If we were to do that, the a != 0 loop versions can be removed because they'll
do nothing other than increase the loop counter.

The a==0 variant will just have the printf and increment of b.

[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng

[ian at airs dot com via Gcc-bugs]

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

--- Comment #1 from Ian Lance Taylor  ---
Yes, runtime.inc is a generated file.  Can you post the lines around the
errors? 
 These look like fields in a struct type, and I'd like to know which type it
is.  Thanks.

[Bug c/101212] forward declaration of parameter

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
See the first example in bug 23144.

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

[Bug c/23144] [9/10/11/12 Regression] invalid parameter forward declarations not diagnosed

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #27 from Joseph S. Myers  ---
*** Bug 101212 has been marked as a duplicate of this bug. ***

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build

[dilfridge at gentoo dot org via Gcc-bugs]

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

Andreas K. Huettel  changed:

   What|Removed |Added

 CC||dilfridge at gentoo dot org

--- Comment #14 from Andreas K. Huettel  ---
also seen with 
 *  --host=riscv32-unknown-linux-gnu 
 *  --target=riscv32-unknown-linux-gnu 
 *  --build=x86_64-pc-linux-gnu 

(building a native riscv32 gcc using Gentoo's crossdev)

[Bug libstdc++/80196] fenv_t not declared

[dilfridge at gentoo dot org via Gcc-bugs]

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

Andreas K. Huettel  changed:

   What|Removed |Added

 CC||dilfridge at gentoo dot org

--- Comment #8 from Andreas K. Huettel  ---
Created attachment 51076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51076&action=edit
full build log, xz-compressed