[Bug sanitizer/105235] [12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
A slightly different testcase fails elsewhere:

$ cat testcase.c
int i, j;

void
foo (double d)
{
  i = __builtin_ilogbl (d);
  j = __builtin_sinl (d);
}

$ x86_64-pc-linux-gnu-gcc -O -fno-tree-dominator-opts -fnon-call-exceptions
-fsanitize=thread -fno-tree-fre testcase.c 
testcase.c: In function 'foo':
testcase.c:4:1: error: BB 3 cannot throw but has an EH edge
4 | foo (double d)
  | ^~~
during GIMPLE pass: sincos
testcase.c:4:1: internal compiler error: verify_flow_info failed
0xe7c00e verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:284
0x128704a execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2097
0x128755e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2139
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 sanitizer/105235] New: [12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105235
   Summary: [12 Regression] ICE: in redirect_eh_edge_1, at
tree-eh.cc:2323 with custom flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-dominator-opts -fnon-call-exceptions
-fsanitize=thread -fno-tree-fre testcase.c 
during GIMPLE pass: sink
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in redirect_eh_edge_1, at
tree-eh.cc:2323
2 | foo (double d)
  | ^~~
0x79d4e2 redirect_eh_edge_1
/repo/gcc-trunk/gcc/tree-eh.cc:2323
0x13f6822 redirect_eh_edge(edge_def*, basic_block_def*)
/repo/gcc-trunk/gcc/tree-eh.cc:2388
0xe7c329 redirect_edge_and_branch(edge_def*, basic_block_def*)
/repo/gcc-trunk/gcc/cfghooks.cc:388
0x13c8105 gimple_split_edge
/repo/gcc-trunk/gcc/tree-cfg.cc:2983
0xe7c9a3 split_edge(edge_def*)
/repo/gcc-trunk/gcc/cfghooks.cc:668
0x13db657 split_critical_edges(bool)
/repo/gcc-trunk/gcc/tree-cfg.cc:9172
0x158a5af split_edges_for_insertion()
/repo/gcc-trunk/gcc/tree-cfg.h:130
0x158a5af execute
/repo/gcc-trunk/gcc/tree-ssa-sink.cc:846
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-r12-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-pr105211-pr105214-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/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
--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-r12-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-pr105211-pr105214-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220411 (experimental) (GCC)

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:0899b22d9329c1e8fc12d6f0deee0f87dcc0163a

commit r12-8099-g0899b22d9329c1e8fc12d6f0deee0f87dcc0163a
Author: Jason Merrill 
Date:   Mon Apr 11 14:50:14 2022 -0400

c++: rodata and defaulted ctor [PR104142]

Trivial initialization shouldn't bump a variable out of .rodata; if the
result of build_aggr_init is an empty STATEMENT_LIST, throw it away.

PR c++/104142

gcc/cp/ChangeLog:

* decl.cc (check_initializer): Check TREE_SIDE_EFFECTS.

gcc/testsuite/ChangeLog:

* g++.dg/opt/const7.C: New test.

[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4195fced8a13422db94e179404588d9d887a036a

commit r12-8098-g4195fced8a13422db94e179404588d9d887a036a
Author: Jason Merrill 
Date:   Mon Apr 11 17:51:43 2022 -0400

c++: using operator= [PR105223]

In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet.  In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
type doesn't prevent the implicit declaration.

When I was working on that patch, the change was necessary to avoid another
regression, but apparently it is no longer needed.

PR c++/105223
PR c++/92918

gcc/cp/ChangeLog:

* class.cc (finish_struct): Always using op=.

gcc/testsuite/ChangeLog:

* g++.dg/template/using31.C: New test.

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4195fced8a13422db94e179404588d9d887a036a

commit r12-8098-g4195fced8a13422db94e179404588d9d887a036a
Author: Jason Merrill 
Date:   Mon Apr 11 17:51:43 2022 -0400

c++: using operator= [PR105223]

In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet.  In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
type doesn't prevent the implicit declaration.

When I was working on that patch, the change was necessary to avoid another
regression, but apparently it is no longer needed.

PR c++/105223
PR c++/92918

gcc/cp/ChangeLog:

* class.cc (finish_struct): Always using op=.

gcc/testsuite/ChangeLog:

* g++.dg/template/using31.C: New test.

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
Probably related to below 3 cancelled jump thread which affects pre.

2076Threading through latch before loop opts would create non-empty latch:
2077  Cancelling jump thread: (15, 16) incoming edge;  (16, 43) normal;

3742Path crosses loops:
3743  Cancelling jump thread: (36, 3) incoming edge;  (3, 37) normal (37, 4)
nocopy;

4755Threading through latch before loop opts would create non-empty latch:
4756  Cancelling jump thread: (26, 28) incoming edge;  (28, 40) normal;

[Bug c++/105234] inlining failed in call to 'always_inline' 'memset': target specific option mismatch

[raj.khem at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Khem Raj  ---
Second sample works when I do not use _FORTIFY_SOURCES=2, so perhaps gcc-12
needs to adjust some glibc headers ?

[Bug c++/105234] inlining failed in call to 'always_inline' 'fmt::v8::basic_format_string::basic_format_string(const S&)

[raj.khem at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Khem Raj  ---
Created attachment 52787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52787=edit
test case 2

[Bug c++/105234] inlining failed in call to 'always_inline' 'fmt::v8::basic_format_string::basic_format_string(const S&)

[raj.khem at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Khem Raj  ---
here is another testcase from gnupg on mips with gcc12 failing

$ mips-yoe-linux-gcc dirmngr.i 
In file included from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/gnupg/2.3.4-r0/recipe-sysroot/usr/include/string.h:535,
 from ../../gnupg-2.3.4/dirmngr/dirmngr.c:29:
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/gnupg/2.3.4-r0/recipe-sysroot/usr/include/bits/string_fortified.h:
In function 'start_connection_thread':
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/gnupg/2.3.4-r0/recipe-sysroot/usr/include/bits/string_fortified.h:57:42:
error: inlining failed in call to 'always_inline' 'memset': target specific
option mismatch
   57 | __NTH (memset (void *__dest, int __ch, size_t __len))
  |  ^~
../../gnupg-2.3.4/dirmngr/dirmngr.c:2183:3: note: called from here
 2183 |   memset (, 0, sizeof argval);
  |   ^~

[Bug c++/105234] New: nlining failed in call to 'always_inline' 'fmt::v8::basic_format_string::basic_format_string(const S&)

[raj.khem at gmail dot com via Gcc-bugs]

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

Bug ID: 105234
   Summary: nlining failed in call to 'always_inline'
'fmt::v8::basic_format_string::basic_format_string(const S&)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

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

Attached testcase fails to compile with gcc-12/mips but it works ok with gcc
11.2

$ mips-yoe-linux-musl-g++  -O0  AtomicFile.cpp.i

In file included from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/util/Tokenizer.hpp:23,
 from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/Util.hpp:22,
 from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/AtomicFile.cpp:22:
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/third_party/fmt/core.h:
In constructor 'core::Error::Error(T&& ...) [with T = {const char (&)[31],
const std::__cxx11::basic_string,
std::allocator >&, char*}]':
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/third_party/fmt/core.h:3057:41:
error: inlining failed in call to 'always_inline'
'fmt::v8::basic_format_string::basic_format_string(const S&) [with
S = char [31]; typename std::enable_if >::value, int>::type  = 0; Char =
char; Args = {const std::__cxx11::basic_string,
std::allocator >&, char*}]': target specific option mismatch
 3057 |   FMT_CONSTEVAL FMT_INLINE basic_format_string(const S& s) : str_(s) {
  | ^~~
In file included from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/AtomicFile.cpp:25:
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/core/exceptions.hpp:57:52:
note: called from here
   57 |   : ErrorBase(fmt::format(std::forward(args)...))
  |^
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/third_party/fmt/core.h:3117:45:
error: inlining failed in call to 'always_inline' 'std::string
fmt::v8::format(format_string, T&& ...) [with T = {const
std::__cxx11::basic_string, std::allocator
>&, char*}]': target specific option mismatch
 3117 | FMT_NODISCARD FMT_INLINE auto format(format_string fmt, T&&...
args)
  | ^~
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/core/exceptions.hpp:57:52:
note: called from here
   57 |   : ErrorBase(fmt::format(std::forward(args)...))
  |^

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|linkw at gcc dot gnu.org   |segher at gcc dot 
gnu.org
URL|https://gcc.gnu.org/piperma |
   |il/gcc-patches/2021-Decembe |
   |r/586712.html,https://gcc.g |
   |nu.org/pipermail/gcc-patche |
   |s/2022-March/591147.html|

--- Comment #33 from Kewen Lin  ---
Should be fixed on trunk now.

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #6 from Alexandre Oliva  ---
I confirm that segher's patch restores the expected insns in prefix-no-update.

[Bug c++/105233] New: Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument

[Jonathan.Strobl at gmx dot de via Gcc-bugs]

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

Bug ID: 105233
   Summary: Incorrect "alignment not an integer constant" error in
alignas with template parameter dependent argument
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Jonathan.Strobl at gmx dot de
  Target Milestone: ---

Dear GCC maintainers,

g++ rejects the following code, which I believe to be valid:

g++ -std=c++20 -x c++ - <
template
struct Data {
T m_a;
T m_b;
T m_c;
};
template
struct alignas(std::bit_ceil(sizeof(Data))) AlignedData {
Data m_data;
};
AlignedData g_test;
EOF
: In instantiation of ‘struct AlignedData’:
:12:18:   required from here
:9:48: error: requested alignment is not an integer constant

This bug is present since GCC 10; I have tested all versions up to 12.0 (trunk)
using Godbolt: https://godbolt.org/z/3eaGGrvWM

One strange thing that I noticed: This only occurs when a value that depends on
a template parameter passes through a standard library function. If the
argument passed to std::bit_ceil doesn't depend on a template parameter, the
code compiles fine. Similarly, when std::bit_ceil is replaced with a hand-made
version of the same function, it also compiles.

std::bit_ceil seems to somehow strip the value passed to it of its
"constant-ness", but only if that value depends on a template parameter.

Thank you for your support,
Jonathan

[Bug preprocessor/105207] Translation phase 2: splicing physical source lines to form logical source lines may not work

[pavel.morozkin at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Pavel M  ---
To: Andrew Pinski

At the 1st glance I expected to see that -E produces the output after splicing
is done (i.e. xxx #error). However, the "preprocessing only" is out of scope of
the C11. As stackoverflow.com user rici said: "Serializing the stream of tokens
back into a character string, which is what gcc -E does, is not required or
even mentioned by the standard, and does not form part of the translation
process specified by the standard".

Hence, per C11 the 105207 is "not a problem".

However, per quality-of-implementation matter maybe it will be useful to make
-E produce the output after splicing is done (i.e. xxx #error). What do you
think?

[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r12-8095-gd74c4c6a1b4956b5cd9b2a770bb7261836fa1289
Author: Peter Bergner 
Date:   Mon Apr 11 17:00:44 2022 -0500

rs6000: Handle pcrel sibcalls to longcall functions [PR104894]

Before PCREL in POWER10, we were not allowed to perform sibcalls to
longcall
functions since callee's return would skip the TOC restore in the caller.
However, with PCREL we can now safely perform a sibling call to longcall
functions.  The problem with the current code is that pcrel sibcall
branches to a PLT stub label even though -fno-plt was used.  The solution
here is to check for a pcrel longcall and emit an inline plt stub in
that case.

2022-04-11  Peter Bergner  

gcc/
PR target/104894
* config/rs6000/rs6000.cc (rs6000_sibcall_aix): Handle pcrel
sibcalls
to longcall functions.

gcc/testsuite/
PR target/104894
* gcc.target/powerpc/pr104894.c: New test.
* gcc.target/powerpc/pr104894-2.c: New test.

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

Jason Merrill  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/98249] [9/10/11/12 Regression] Improper ADL on the `arg` in `new (arg) T`

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r12-8093-gd087b59527a658a4de13febbb593edbf03339e93
Author: Jason Merrill 
Date:   Mon Apr 11 13:06:05 2022 -0400

c++: operator new lookup [PR98249]

The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope.  This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.

PR c++/98249

gcc/cp/ChangeLog:

* call.cc (build_operator_new_call): Just look in ::.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/new3.C: New test.

[Bug target/105213] Extend __builtin_{un,}pack_{longdouble,ibm128} valid for soft-float

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:0508f0b810985f4a8543ce44701ec7330ef29796

commit r12-8091-g0508f0b810985f4a8543ce44701ec7330ef29796
Author: Segher Boessenkool 
Date:   Mon Apr 11 15:43:38 2022 +

rs6000: Fix unpack for no-direct-move (PR103623)

The _dm alternative works fine for soft-float, but the _nodm variant
pattern is missing that alternative.  So, let's add that.

There probably should be an r,r,i alternative as well (or we can make it
rm,r,i), but that is for later.

2022-04-11  Segher Boessenkool  

PR target/105213
PR target/103623
* config/rs6000/rs6000.md (unpack_nodm): Add m,r,i
alternative.

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

--- Comment #32 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:0508f0b810985f4a8543ce44701ec7330ef29796

commit r12-8091-g0508f0b810985f4a8543ce44701ec7330ef29796
Author: Segher Boessenkool 
Date:   Mon Apr 11 15:43:38 2022 +

rs6000: Fix unpack for no-direct-move (PR103623)

The _dm alternative works fine for soft-float, but the _nodm variant
pattern is missing that alternative.  So, let's add that.

There probably should be an r,r,i alternative as well (or we can make it
rm,r,i), but that is for later.

2022-04-11  Segher Boessenkool  

PR target/105213
PR target/103623
* config/rs6000/rs6000.md (unpack_nodm): Add m,r,i
alternative.

[Bug tree-optimization/105232] [11/12 Regression] ICE in tree_to_poly_int64 via check_builtin

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
Summary|ICE in tree_to_poly_int64,  |[11/12 Regression] ICE in
   |at tree.cc:3224 |tree_to_poly_int64 via
   ||check_builtin
   Keywords||diagnostic,
   ||ice-on-valid-code
  Component|c   |tree-optimization

[Bug c/105232] New: ICE in tree_to_poly_int64, at tree.cc:3224

[k.even-mendoza at imperial dot ac.uk via Gcc-bugs]

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

Bug ID: 105232
   Summary: ICE in tree_to_poly_int64, at tree.cc:3224
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.even-mendoza at imperial dot ac.uk
  Target Milestone: ---

The following code crashed gcc-12 with all flags, and gcc-11 with -O1, -O2, -O3
and -Os but works fine with -O0. gcc-10 and below works fine.

===
c;
#define d(expr, e)
\
  char *f = expr; 
\
  strlen(f) ?: ++c;
struct {
  char a[0], b[15372286740]
} cma[] = {{}, {}, {}, {}, {}, {}};
g() { d(cma[4].a, ) }
===

crashed with:
/home/user42/data/gcc-csmith-1201/gcc-install/bin/gcc -O2 fuzzer-file-3200.c
...
fuzzer-file-3200-1.c:8:7: note: in expansion of macro ‘d’
8 | g() { d(cma[4].a, ) }
  |   ^
during GIMPLE pass: waccess
fuzzer-file-3200-1.c:8:1: internal compiler error: in tree_to_poly_int64, at
tree.cc:3224
8 | g() { d(cma[4].a, ) }
  | ^
0x7e75cb tree_to_poly_int64(tree_node const*)
.././../gcc-source/gcc/tree.cc:3224
0x7e75cb tree_to_poly_int64(tree_node const*)
.././../gcc-source/gcc/tree.cc:3222
...
0xc0ffb8 check_builtin
.././../gcc-source/gcc/gimple-ssa-warn-access.cc:3181
0xc0ffb8 check_call
.././../gcc-source/gcc/gimple-ssa-warn-access.cc:4280
0xc0ffb8 check_block
.././../gcc-source/gcc/gimple-ssa-warn-access.cc:4393
0xc0ffb8 execute
.././../gcc-source/gcc/gimple-ssa-warn-access.cc:4742

===
With -O0 it ends without crashing and prints the right error:
gcc-11 -O0 fuzzer-file-3200.c
...
fuzzer-file-3200.c:8:7: note: in expansion of macro ‘d’
8 | g() { d(cma[4].a, ) }
  |   ^
fuzzer-file-3200.c: At top level:
fuzzer-file-3200.c:7:3: error: size of variable ‘cma’ is too large
7 | } cma[] = {{}, {}, {}, {}, {}, {}};

[Bug tree-optimization/105226] [10/11/12 Regression] ICE in gimple_split_edge with -Ofast and setjmp (returns twice)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
Summary|[10/11/12 Regression] ICE   |[10/11/12 Regression] ICE
   |in gimple_split_edge, at|in gimple_split_edge with
   |tree-cfg.cc:2960|-Ofast and setjmp (returns
   ||twice)
   Keywords||needs-bisection
   Target Milestone|--- |10.4

[Bug target/89125] Misoptimization of converting sin(x) and cos(x) into sincos(x,,)

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #45592|0   |1
is obsolete||

--- Comment #13 from kargl at gcc dot gnu.org ---
Created attachment 52785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52785=edit
New patch

New patch that deals with the *.c to *.cc rename

[Bug target/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|target
   Target Milestone|--- |12.0

[Bug target/105206] mis-optimization with -ffast-math and __builtin_powf

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Component|middle-end  |target
 Depends on||89125
 Target||x86_64-*-freebsd

--- Comment #5 from kargl at gcc dot gnu.org ---
I've updated the Component to target and added the target triplet.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
[Bug 89125] Misoptimization of converting sin(x) and cos(x) into
sincos(x,,)

[Bug middle-end/105206] mis-optimization with -ffast-math and __builtin_powf

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Mon, Apr 11, 2022 at 02:45:22PM +, kargl at gcc dot gnu.org wrote:
> 
> This might be related to PR89125.  The patch I attached to that PR has never
> found its way into the repository.  I'll do some more testing later today.
> 

Yep.  This is related to PR89125.  GCC does not use configure
to check for the availability of individual C99 libm functions.
After updating the patch in PR89125 for the *.c to *.cc migration
the patch gcc gives

foof:
.LFB3:
.cfi_startproc
mulss   .LC0(%rip), %xmm0
jmp expf
.cfi_endproc

food:
.LFB4:
.cfi_startproc
mulsd   .LC1(%rip), %xmm0
jmp exp
.cfi_endproc

fool:
.LFB5:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
fldt16(%rbp)
popq%rbp
.cfi_def_cfa 7, 8
fldt.LC2(%rip)
fmulp   %st, %st(1)
fldl2e
fmulp   %st, %st(1)
fld %st(0)
frndint
fsubr   %st, %st(1)
fxch%st(1)
f2xm1
fld1
faddp   %st, %st(1)
fscale
fstp%st(1)
ret
.cfi_endproc

[Bug rtl-optimization/105231] New: [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105231
   Summary: [12 Regression] ICE: in rtl_verify_bb_insns, at
cfgrtl.cc:2797 (flow control insn inside a basic
block) with custom flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  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 52784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52784=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fsanitize-coverage=trace-pc
-fnon-call-exceptions --param=max-cse-insns=1 -frounding-math -mstack-arg-probe
-fsanitize=thread -m32 testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: error: in basic block 3:
7 | }
  | ^
testcase.c:7:1: error: flow control insn inside a basic block
(insn 78 22 24 3 (set (reg:XF 99)
(float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
 S4 A32]))) 166 {*extendsfxf2_i387}
 (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
during RTL pass: combine
testcase.c:7:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2797
0x76ddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0xe954e3 rtl_verify_bb_insns
/repo/gcc-trunk/gcc/cfgrtl.cc:2797
0xe9ea5c rtl_verify_flow_info_1
/repo/gcc-trunk/gcc/cfgrtl.cc:2883
0xe83dfa verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:282
0x22a4bb8 checking_verify_flow_info
/repo/gcc-trunk/gcc/cfghooks.h:214
0x22a4bb8 try_optimize_cfg
/repo/gcc-trunk/gcc/cfgcleanup.cc:2980
0x22a4bb8 cleanup_cfg(int)
/repo/gcc-trunk/gcc/cfgcleanup.cc:3143
0x22d0820 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.cc:14942
0x22d0820 execute
/repo/gcc-trunk/gcc/combine.cc:14976
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-r12-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-nobootstrap-pr105211-pr105214-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/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-r12-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-nobootstrap-pr105211-pr105214-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220411 (experimental) (GCC)

Both vanilla gcc r12-8090 and with pr105211 and pr105214 patches applies ICE
the same way.

[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug ipa/105227] [12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|tree-optimization   |ipa
 CC||marxin at gcc dot gnu.org

[Bug fortran/105230] [9/10/11/12 Regression] ICE in find_array_section, at fortran/expr.cc:1634

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-11
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Started with 22015e77d3e4.

I cannot work out the logic here in expr.cc:1595-1603


  if ((begin && begin->expr_type != EXPR_CONSTANT)
  || (finish && finish->expr_type != EXPR_CONSTANT)
  || (step && step->expr_type != EXPR_CONSTANT)
  || (!begin && !lower)
  || (!finish && !upper))
{
  t = false;
  goto cleanup;
}

upper is NULL and later in 1634 it is dereferenced.  This patch fixes
the problem, but the above logic likely needs fixing.

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 86d61fed302..4fcdf009b4b 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1630,6 +1630,11 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
  if (ref->u.ar.dimen_type[d] == DIMEN_ELEMENT)
mpz_set (end [d], begin->value.integer);

+ if (!upper || !lower)
+   {
+ t = false;
+ goto cleanup;
+   }
  /* Check the bounds.  */
  if (mpz_cmp (ctr[d], upper->value.integer) > 0
  || mpz_cmp (end[d], upper->value.integer) > 0

[Bug tree-optimization/105227] [12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
   Priority|P3  |P1
  Component|c++ |tree-optimization
 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Confirmed.

The problem seems to be that free_lang_data_in_decl changes DECL_CONTEXT of
Klass::implementation to be the global scope because it isn't virtual, but
eventually update_vtable_references changes the vtable entry for Klass::magic
to refer to (a local alias for) Klass::implementation, so maybe_record_node's
attempts to ask about its class context fail.

Currently free_lang_data_in_decl works around this issue for destructors
specifically, but not for other member functions.

Not sure if the component should be tree-optimization or lto, but it isn't a
front-end issue.

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

--- Comment #3 from Patrick Palka  ---
FWIW, the problematic hunk from r12-7714 appears to be:

--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
...
@@ -7700,14 +7723,17 @@ finish_struct (tree t, tree attributes)
 lookup not to fail or recurse into bases.  This isn't added
 to the template decl list so we drop this at instantiation
 time.  */
-  tree ass_op = build_lang_decl (USING_DECL, assign_op_identifier,
-NULL_TREE);
-  DECL_CONTEXT (ass_op) = t;
-  USING_DECL_SCOPE (ass_op) = t;
-  DECL_DEPENDENT_P (ass_op) = true;
-  DECL_ARTIFICIAL (ass_op) = true;
-  DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
-  TYPE_FIELDS (t) = ass_op;
+  if (!get_class_binding_direct (t, assign_op_identifier, false))
+   {
+ tree ass_op = build_lang_decl (USING_DECL, assign_op_identifier,
+NULL_TREE);
+ DECL_CONTEXT (ass_op) = t;
+ USING_DECL_SCOPE (ass_op) = t;
+ DECL_DEPENDENT_P (ass_op) = true;
+ DECL_ARTIFICIAL (ass_op) = true;
+ DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
+ TYPE_FIELDS (t) = ass_op;
+   }

   TYPE_SIZE (t) = bitsize_zero_node;
   TYPE_SIZE_UNIT (t) = size_zero_node;


This hunk causes us to no longer create a dependent USING_DECL representing the
implicitly declared operator= for ServiceReference, which means name lookup
for operator= at parse time yields only the ServiceReferenceBase::operator=
members.  This allows us to prune the overload set for the call 'operator=(0)'
ahead of time and hence we end up calling filter_memfn_lookup later at
instantiation time where we crash due comment #2.

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alexandre Oliva
:

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

commit r10-10530-g3ebf64eaf264e1dcb4e72b77f67308fe58d993f8
Author: Alexandre Oliva 
Date:   Mon Apr 11 12:11:10 2022 -0300

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.


for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

(cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

--- Comment #2 from Patrick Palka  ---
The implicitly declared ServiceReference::operator= members lack a
TEMPLATE_INFO, but filter_memfn_lookup expects it (along with all other
non-template member functions from the instantiated class) to have one.

Not sure what the best solution here is, but we can at least work around this
by making filter_memfn_lookup tolerate missing TEMPLATE_INFO in this case:

 gcc/cp/pt.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 78519562953..f359e596846 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -16404,6 +16404,13 @@ filter_memfn_lookup (tree oldfns, tree newfns, tree
newtype)
 look in the old lookup set for the TEMPLATE_DECL from which
 it was specialized.  */
   return visible_set.contains (DECL_TI_TEMPLATE (fn));
+else if (!DECL_TEMPLATE_INFO (fn))
+  {
+   /* FN is an implicitly declared special member function and thus
+  could not have been in the old lookup set.  */
+   gcc_checking_assert (DECL_ARTIFICIAL (fn) && DECL_DEFAULTED_FN (fn));
+   return false;
+  }
 else
   /* FN is a non-template member function from the current class;
 look in the old lookup set for the FUNCTION_DECL from which

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Alexandre Oliva
:

https://gcc.gnu.org/g:20bde90da2ac415d4a06e7a8b2ba770d50385208

commit r11-9810-g20bde90da2ac415d4a06e7a8b2ba770d50385208
Author: Alexandre Oliva 
Date:   Mon Apr 11 12:11:10 2022 -0300

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.


for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

(cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)

[Bug c++/105229] [11/12 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-11
   Target Milestone|--- |11.3

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r11-86-gef3479afc5ab41

commit ef3479afc5ab415f00a53fc6f6a990df7f6a0747
Author: Marek Polacek 
Date:   Tue Apr 28 22:30:44 2020 -0400

c++: Member template function lookup failure [PR94799]

which changed

$ ./cc1plus.r11-85 -quiet ~/105229.C -std=c++2a
/home/mpolacek/105229.C: In function ‘void bar()’:
/home/mpolacek/105229.C:3:12: error: expected ‘(’ before ‘{’ token
3 |   []  {}.operator () <> ();
  |^
  |(
/home/mpolacek/105229.C:3:28: error: expected primary-expression before ‘>’
token
3 |   []  {}.operator () <> ();
  |^
/home/mpolacek/105229.C:3:31: error: expected primary-expression before ‘)’
token
3 |   []  {}.operator () <> ();
  |   ^

to

$ ./cc1plus.r11-86 -quiet ~/105229.C -std=c++2a
/home/mpolacek/105229.C: In function ‘void bar()’:
/home/mpolacek/105229.C:3:12: error: expected ‘(’ before ‘{’ token
3 |   []  {}.operator () <> ();
  |^
  |(
/home/mpolacek/105229.C: In instantiation of ‘void bar() [with
 = int]’:
/home/mpolacek/105229.C:7:13:   required from here
/home/mpolacek/105229.C:3:28: internal compiler error: in
lookup_template_class_1, at cp/pt.c:9891
3 |   []  {}.operator () <> ();
  |   ~^
unrecognized DWARF version in .debug_info at 6
0xbc18c9 lookup_template_class_1
../../gcc/cp/pt.c:9891
0xbc3176 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:10114
0xbd10d0 tsubst_aggr_type
../../gcc/cp/pt.c:13382
0xbdd578 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15169
0xbe0fe1 tsubst_baselink
../../gcc/cp/pt.c:16001
0xbf8c92 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20188
0xbf638e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19730
0xbf1cd2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18753
0xbea656 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17865
0xbea3e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17835
0xbed092 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18154
0xc11905 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:25714
0xc122c4 instantiate_pending_templates(int)
../../gcc/cp/pt.c:25830

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed now.

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:1774ab84863202f5db694914b67e3aef8c6dd807

commit r12-8090-g1774ab84863202f5db694914b67e3aef8c6dd807
Author: Jakub Jelinek 
Date:   Mon Apr 11 19:06:59 2022 +0200

phiopt: Fix up debug handling in the (x != cst1 ? x : cst2) != cst3 opt
[PR105218]

In the PR104639 optimization, I've added code to emit
  # DEBUG D#1 => arg != carg ? arg : oarg
instruction and replace debug uses of the phi with that debug
temp, so that the debug info is still accurrate.
Unfortunately, that is only correct if the middle-bb and
phi bb contain 1 and 2 predecessors, i.e. the ones that
we are using in the optimization (in particular middle-bb has
cond-bb as pred and phi bb cond-bb and middle-bb).
If that is not the case, then we can reach these from another bb
and so the arg SSA_NAME might not be valid there (its definition
doesn't dominate all incoming edges), or, even if it is valid,
might be wrong-debug, e.g. phi argument from some unrelated other
incoming edge might have the carg value that the debug stmt
remaps to oarg.  In theory we could check for that case and
if middle-bb doesn't have a single pred or phi bb 2 preds
check if arg SSA_NAME dominates the phi bb and if all other
phi arguments are expr_not_equal_to the carg value, but this patch
just uses a simpler approach and resets already if we have some
extra incoming edges.

2022-04-11  Jakub Jelinek  

PR tree-optimization/105218
* tree-ssa-phiopt.cc (value_replacement): If middle_bb has
more than one predecessor or phi's bb more than 2 predecessors,
reset phi result uses instead of adding a debug temp.

* gcc.dg/pr105218.c: New test.

[Bug c++/98249] [9/10/11/12 Regression] Improper ADL on the `arg` in `new (arg) T`

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

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-11
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/105031] wrong constexpr if statement in basic_stacktrace::operator=(basic_stacktrace&&)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed, thanks for the report.

[Bug libstdc++/105031] wrong constexpr if statement in basic_stacktrace::operator=(basic_stacktrace&&)

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

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

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

https://gcc.gnu.org/g:73da9ec55609efa532b9ac85ac2dbe121c134e18

commit r12-8089-g73da9ec55609efa532b9ac85ac2dbe121c134e18
Author: Jonathan Wakely 
Date:   Mon Apr 11 17:44:14 2022 +0100

libstdc++: Fix std::basic_stacktrace special members [PR105031]

The PR points out that there is a non-constant condition used for an
if-constexpr statement, but there are several other problems with the
copy, move and swap members of std::basic_stacktrace.

libstdc++-v3/ChangeLog:

PR libstdc++/105031
* include/std/stacktrace (basic_stacktrace::basic_stacktrace):
Fix allocator usage in constructors.
(basic_stacktrace::operator=(const basic_stacktrace&)): Do not
try to reallocate using const allocator.
(basic_stacktrace::operator=(basic_stacktrace&&)): Fix
if-constexpr with non-constant condition. Do not allocate new
storage if allocator propagates. Do not set _M_size if
allocation fails.
(basic_stacktrace::swap(basic_stacktrace&)): Fix typo. Add
assertion that non-propagating allocators are equal.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: New test.

[Bug fortran/105230] New: [9/10/11/12 Regression] ICE in find_array_section, at fortran/expr.cc:1634

[gscfq--- via Gcc-bugs]

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

Bug ID: 105230
   Summary: [9/10/11/12 Regression] ICE in find_array_section, at
fortran/expr.cc:1634
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.f90
program p
   integer, parameter :: a(:) = [1, 2]
   print *, reshape([3, 4], a(1:2))
end


$ cat z2.f90
program p
   integer, parameter :: a(:) = [1, 2]
   print *, reshape(a, a(1:2))
end


$ cat z3.f90
program p
   integer, parameter :: a(:) = [1, 2]
   print *, reshape(a(1:2), a(1:2))
end


$ gfortran-12-20220410 -c z1.f90
z1.f90:2:29:

2 |integer, parameter :: a(:) = [1, 2]
  | 1
Error: Parameter array 'a' at (1) cannot be automatic or of deferred shape
f951: internal compiler error: Segmentation fault
0xe7751f crash_signal
../../gcc/toplev.cc:322
0x736956 find_array_section
../../gcc/fortran/expr.cc:1634
0x73868a simplify_const_ref
../../gcc/fortran/expr.cc:1934
0x7391be gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.cc:2325
0x73942b simplify_parameter_variable
../../gcc/fortran/expr.cc:2154
0x739155 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.cc:2292
0x70a47d gfc_check_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/check.cc:4723
0x74b359 do_check
../../gcc/fortran/intrinsic.cc:4792
0x74b359 check_specific
../../gcc/fortran/intrinsic.cc:4805
0x7533e4 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5042
0x7a7cf8 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x7a7cf8 resolve_function
../../gcc/fortran/resolve.cc:3347
0x7a7cf8 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7187
0x7adeb4 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7154
0x7adeb4 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11949
0x7aca8f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:10965
0x7acde8 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11939
0x7afac7 resolve_codes
../../gcc/fortran/resolve.cc:17567
0x7afb8e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17602
0x797b14 resolve_all_program_units
../../gcc/fortran/parse.cc:6604

[Bug c++/105228] [9/10/11/12 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-11
   Target Milestone|--- |9.5
   Keywords||error-recovery
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/105229] New: [11/12 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111

[gscfq--- via Gcc-bugs]

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

Bug ID: 105229
   Summary: [11/12 Regression] ICE in lookup_template_class_1, at
cp/pt.cc:10111
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20200503 and 20200510 :


$ cat z1.cc
template  void bar ()
{
  []  {}.operator () <> ();
}
void foo ()
{
  bar ();
}


$ g++-12-20220410 -c z1.cc
z1.cc: In instantiation of 'void bar() [with  = int]':
z1.cc:7:12:   required from here
z1.cc:3:28: internal compiler error: in lookup_template_class_1, at
cp/pt.cc:10111
3 |   []  {}.operator () <> ();
  |   ~^
0x990981 lookup_template_class_1
../../gcc/cp/pt.cc:10111
0x990981 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.cc:10350
0x990cb2 tsubst_aggr_type
../../gcc/cp/pt.cc:13738
0x97a962 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15649
0x9a717b tsubst_baselink
../../gcc/cp/pt.cc:16453
0x976d2b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.cc:21028
0x975385 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.cc:20658
0x99b274 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:19473
0x99918d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18486
0x999b9f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18458
0x99b233 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18815
0x97f679 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18444
0x97f679 instantiate_body
../../gcc/cp/pt.cc:26393
0x980da7 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.cc:26685
0x9c780b instantiate_pending_templates(int)
../../gcc/cp/pt.cc:26764
0x8281e6 c_parse_final_cleanups()
../../gcc/cp/decl2.cc:5113

[Bug c++/105228] New: [9/10/11/12 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826

[gscfq--- via Gcc-bugs]

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

Bug ID: 105228
   Summary: [9/10/11/12 Regression] ICE tree check: expected tree
that contains 'decl minimal' structure, have
'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
template class> struct A
{
  template
  static void foo() { foo(); }
};


$ g++-12-20220410 -c z1.cc
z1.cc:1:19: error: 'void' is not a valid type for a template non-type parameter
1 | template class> struct A
  |   ^~~~
z1.cc: In substitution of 'template >
class > template static void A<
 >::foo() [with Args = ;
 = {}]':
z1.cc:4:26:   required from here
z1.cc:4:15: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at
cp/tree.cc:3826
4 |   static void foo() { foo(); }
  |   ^~~
0x6c9ab3 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.cc:8953
0xa1b4ac contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3827
0xa1b4ac decl_anon_ns_mem_p(tree_node const*)
../../gcc/cp/tree.cc:3826
0x8182b7 determine_visibility(tree_node*)
../../gcc/cp/decl2.cc:2867
0x9ae8bf tsubst_function_decl
../../gcc/cp/pt.cc:14305
0x9924f3 tsubst_decl
../../gcc/cp/pt.cc:14585
0x97ad67 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15565
0x9b4cb2 instantiate_template_1
../../gcc/cp/pt.cc:21625
0x9b4cb2 instantiate_template(tree_node*, tree_node*, int)
../../gcc/cp/pt.cc:21684
0x9bc656 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc/cp/pt.cc:22150
0x72543b add_template_candidate_real
../../gcc/cp/call.cc:3544
0x7265a1 add_template_candidate
../../gcc/cp/call.cc:3636
0x7265a1 add_candidates
../../gcc/cp/call.cc:6176
0x736240 add_candidates
../../gcc/cp/call.cc:10994
0x736240 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.cc:11038
0x9e7dde finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2791
0x9189d8 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7880
0x92ffb1 cp_parser_unary_expression
../../gcc/cp/parser.cc:9029
0x8fd91f cp_parser_cast_expression
../../gcc/cp/parser.cc:9933
0x8fe1e1 cp_parser_binary_expression
../../gcc/cp/parser.cc:10035

[Bug c++/105227] New: [12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233

[gscfq--- via Gcc-bugs]

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

Bug ID: 105227
   Summary: [12 Regression] ICE in type_in_anonymous_namespace_p,
at ipa-utils.h:233
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This started between 2024 and 20211121,
with file g++.dg/ext/attr-alias-2.C at -Ofast :


$ g++-12-2024 -c attr-alias-2.C -fPIC -flto -Ofast
$ g++-12-20220410 -c attr-alias-2.C -fPIC -flto -O3
$
$ g++-12-20220410 -c attr-alias-2.C -fPIC -flto -Ofast
during IPA pass: visibility
attr-alias-2.C:37:1: internal compiler error: Segmentation fault
   37 | }
  | ^
0xda8c2f crash_signal
../../gcc/toplev.cc:322
0xb58561 type_in_anonymous_namespace_p(tree_node const*)
../../gcc/ipa-utils.h:233
0xb58561 maybe_record_node
../../gcc/ipa-devirt.cc:2427
0xb5a918 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.cc:3241
0xbd28b9 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:131
0xbd28b9 walk_polymorphic_call_targets
../../gcc/ipa.cc:183
0xbd28b9 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/ipa.cc:431
0xccedbd execute_todo
../../gcc/passes.cc:2153

---

$ g++-12-20220410 -c attr-alias-2.C -fPIC -flto -Ofast   # test version
during IPA pass: visibility
attr-alias-2.C:37:1: internal compiler error: tree check: expected class
'type', have 'declaration' (translation_unit_decl) in type_with_linkage_p, at
ipa-utils.h:198
   37 | }
  | ^
0x6c96a5 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8829
0xe1a61a tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
../../gcc/tree.h:3836
0xe1a61a type_with_linkage_p(tree_node const*)
../../gcc/ipa-utils.h:198
0xe1a61a type_in_anonymous_namespace_p(tree_node const*)
../../gcc/ipa-utils.h:229
0xe14011 maybe_record_node
../../gcc/ipa-devirt.cc:2427
0xe16221 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.cc:3241
0xea0837 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:131
0xea0837 walk_polymorphic_call_targets
../../gcc/ipa.cc:183
0xea0837 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/ipa.cc:431
0xfd533d execute_todo
../../gcc/passes.cc:2153

[Bug c/105226] New: [10/11/12 Regression] ICE in gimple_split_edge, at tree-cfg.cc:2960

[gscfq--- via Gcc-bugs]

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

Bug ID: 105226
   Summary: [10/11/12 Regression] ICE in gimple_split_edge, at
tree-cfg.cc:2960
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190609 and 20190616, at -O3 or -Ofast :


$ cat z1.c
#include 
struct longjmp_buf {
  jmp_buf buf;
};
void g ();
void f ()
{
  int i, n;
  long *a;
  long *args;
  struct longjmp_buf b;
  setjmp (b.buf);
  for (;;)
{
  for (i = 0; i < n; i++)
a[i] = args[i];
  g ();
}
}


$ gcc-10-20190609 -c z1.c -Ofast
$ gcc-12-20220410 -c z1.c -O2
$
$ gcc-12-20220410 -c z1.c -Ofast
during GIMPLE pass: vect
z1.c: In function 'f':
z1.c:6:6: internal compiler error: in gimple_split_edge, at tree-cfg.cc:2960
6 | void f ()
  |  ^
0xe53d86 gimple_split_edge
../../gcc/tree-cfg.cc:2960
0x89f16c split_edge(edge_def*)
../../gcc/cfghooks.cc:668
0x10eec7c vect_loop_versioning(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop-manip.cc:3636
0x10e4e01 vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.cc:9691
0x111ec35 vect_transform_loops
../../gcc/tree-vectorizer.cc:1007
0x111f2e6 try_vectorize_loop_1
../../gcc/tree-vectorizer.cc:1136
0x111f2e6 try_vectorize_loop
../../gcc/tree-vectorizer.cc:1167
0x111f914 execute
../../gcc/tree-vectorizer.cc:1281

[Bug go/105225] New: build failure with musl libc 1.2.3 due to sysinfo.go error: redefinition of 'SYS_SECCOMP'

[ncopa at alpinelinux dot org via Gcc-bugs]

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

Bug ID: 105225
   Summary: build failure with musl libc 1.2.3 due to sysinfo.go
error: redefinition of 'SYS_SECCOMP'
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ncopa at alpinelinux dot org
CC: cmang at google dot com
  Target Milestone: ---

Building gcc 11.2.1 with musl libc 1.2.3 fails with:

11.2.1_git20220219/libgo/go/syscall/time_nofake.go
/home/ncopa/aports/main/gcc/src/gcc-11.2.1_git20220219/libgo/go/syscall/timestruct.go
libcalls.go sysinfo.go syscall_arch.go syscall_linknames.go epoll.go  -fPIC -o
.libs/syscall.o
sysinfo.go:6606:7: error: redefinition of 'SYS_SECCOMP'
 6606 | const SYS_SECCOMP = _SYS_SECCOMP
  |   ^
sysinfo.go:6600:7: note: previous definition of 'SYS_SECCOMP' was here
 6600 | const SYS_SECCOMP = _SYS_seccomp
  |   ^
make[2]: *** [Makefile:3001: syscall.lo] Error 1

The generation of sysinfo.go will try extract syscalls and convert them to
uppercase. It gets duplicated by the uppercase SYS_SECCOMP introduced in with
musl commit:
https://git.musl-libc.org/cgit/musl/commit/?id=3dcbd896907d9d474da811b7c6b769342abaf651

A possible fix is to only grep for syscalls with lowercase letters:
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 6fef104..06289a4 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -126,7 +126,7 @@ if ! grep '^const SIGCLD ' ${OUT} >/dev/null 2>&1; then
 fi

 # The syscall numbers.  We force the names to upper case.
-grep '^const _SYS_' gen-sysinfo.go | \
+grep '^const _SYS_[a-z]' gen-sysinfo.go | \
   sed -e 's/const _\(SYS_[^= ]*\).*$/\1/' | \
   while read sys; do
 sup=`echo $sys | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
struct ServiceReferenceBase {
  void operator=(int);
};

template
struct ServiceReference : ServiceReferenceBase {
  void foo() { operator=(0); }
  using ServiceReferenceBase::operator=;
};

int main() {
  ServiceReference sr;
  sr.foo();
}

[Bug c++/105222] gcc totally broken with ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #4 from 康桓瑋  ---
maybe dup of PR99546.

[Bug c++/105224] New: [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash

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

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

Bug ID: 105224
   Summary: [modules] g++.dg/modules/virt-2_a.C: inline key
methods: c++ modules and arm aapcs clash
   Product: gcc
   Version: unknown
   URL: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/5
92763.html
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aoliva at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---
Target: arm-eabi

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets that use
the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way the clash
between AAPCS and C++ Modules design should be resolved, but currently it
favors AAPCS and thus the test fails.

Skipping the test or conditionally dropping the inline keyword breaks
subsequent tests.  The patchlet in the URL XFAILs the expectations of the keyed
symbols on
arm*-*-*.
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592763.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Alex Coplan from comment #3)
> (In reply to Tamar Christina from comment #1)
> > Smaller reproducer getting rid of the loop nest and simplify the inner
> > condition.
> 
> Hmm, I can't reproduce the issue with this locally (with or without the
> -mtune option). I also seem to need the -mtune option with the original
> reproducer. Are you definitely setting the right VL when running the
> compiled program?

Ah, my sve-max-vq was in the wrong place... I indeed see that the thunderx is
significant now. Will try to reduce a bit again.

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0
 CC||jason at gcc dot gnu.org
   Keywords||ice-on-valid-code

[Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error

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

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

Bug ID: 105223
   Summary: [12 Regression] filter_memfn_lookup internal compiler
error
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Started with r12-7714-g47da5198766256:

commit 47da5198766256be658b4c321cecfd6039b0b91b
Author: Jason Merrill 
Date:   Fri Feb 25 15:07:15 2022 -0400

c++: using lookup within class defn [PR104476]


$ ./cc1plus -quiet ice.C
ice.C: In instantiation of ‘ServiceReference< 
>::ServiceReference(ServiceReferenceBase) [with  = int;
ServiceReferenceBase = ServiceReferenceBase]’:
ice.C:75:54:   required from here
ice.C:50:53: internal compiler error: Segmentation fault
   50 |   ServiceReference(ServiceReferenceBase) { operator=(0); }
  |~^~~
0x1773b61 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:322
0xae557e tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3456
0xe17756 operator()
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16411
0xe1799d filter_memfn_lookup
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16417
0xe180ce tsubst_baselink
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16506
0xe32588 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21028
0xe30427 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20658
0xe2ae60 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19473
0xe22d0e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18486
0xe25b2d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18815
0xe22a79 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18458
0xe25b2d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18815
0xe49a1f instantiate_body
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26393
0xe4b3eb instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26685
0xe4b787 instantiate_pending_templates(int)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26764
0xc4a2b6 c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.cc:5113
0xf9f06d c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.cc:1262

$ cat ice.C
namespace std {
template  class reverse_iterator {
public:
  typename _Iterator::pointer operator->();
};
template 
bool operator!=(reverse_iterator<_Iterator>, reverse_iterator<_Iterator>);
} // namespace std
template  class __normal_iterator {
public:
  typedef _Iterator pointer;
};
namespace std {
template  class allocator;
template  struct allocator_traits;
template  struct allocator_traits> {
  using pointer = _Tp *;
};
} // namespace std
class ServiceRegistrationBase;
struct __alloc_traits
: std::allocator_traits> {};
namespace std {
class __shared_ptr {
public:
  using element_type = int;
  element_type *get();
};
struct _Vector_base {
  typedef __alloc_traits::pointer pointer;
};
class vector {
public:
  typedef std::reverse_iterator<__normal_iterator<_Vector_base::pointer>>
  reverse_iterator;
  reverse_iterator rbegin();
  reverse_iterator rend();
};
template  struct atomic;
template  struct atomic<_Tp *> { _Tp *load(); };
} // namespace std
class ServiceReferenceBasePrivate;
class ServiceReferenceBase {
public:
  void operator=(decltype(nullptr));
  std::atomic d;
};
template  class ServiceReference : public ServiceReferenceBase {
public:
  ServiceReference(ServiceReferenceBase) { operator=(0); }
  using ServiceReferenceBase::operator=;
};
class Bundle {
  friend std::__shared_ptr GetPrivate(Bundle);
};
class ServiceRegistrationBase {
public:
  ServiceReferenceBase GetReference();
};
class BundleContext {
public:
  Bundle GetBundle();
};
class ServiceReferenceBasePrivate {
public:
  std::__shared_ptr GetService(int *);
};
void ServiceHooksFilterServiceEventReceivers() {
  BundleContext __trans_tmp_3;
  std::vector eventListenerHooks;
  auto selfBundle = __trans_tmp_3.GetBundle();
  for (auto sriIter = eventListenerHooks.rbegin(),
sriEnd = eventListenerHooks.rend();
   sriIter != sriEnd;) {
ServiceReference sr = sriIter->GetReference();
int __trans_tmp_2 = *GetPrivate(selfBundle).get();
std::__shared_ptr __trans_tmp_1 = sr.d.load()->GetService(&__trans_tmp_2),
  elh(__trans_tmp_1);
  }
}

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

--- Comment #3 from Alex Coplan  ---
(In reply to Tamar Christina from comment #1)
> Smaller reproducer getting rid of the loop nest and simplify the inner
> condition.

Hmm, I can't reproduce the issue with this locally (with or without the -mtune
option). I also seem to need the -mtune option with the original reproducer.
Are you definitely setting the right VL when running the compiled program?

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

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

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

--- Comment #13 from Kito Cheng  ---
Hi rvalue:

Pushed the fix to trunk and GCC 11 branch for fixing both arch-canonicalize and
multilib-generator script.

Tested GCC 11/trunk with --with-isa-spec=2.2/20191213.

Could you try that to make sure that work to you?

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Kito Cheng :

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

commit r11-9809-gfa21fcfb67587837c1704703a710496999393c1d
Author: Kito Cheng 
Date:   Mon Apr 11 16:29:34 2022 +0800

RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator.
[PR104853]

We migrate the default ISA spec version from 2.2 to 20191213, but those
scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.

gcc/ChangeLog:

PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
multilib-generator.
* config/riscv/arch-canonicalize: Adding -misa-spec option.
(SUPPORTED_ISA_SPEC): New.
(arch_canonicalize): New argument `isa_spec`.
Handle multiple ISA spec versions.
* config/riscv/multilib-generator: Adding -misa-spec option.

(cherry picked from commit 4132f6ba9583e128a00d55961ae8c8e7245b2223)

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.0
 CC||ktkachov at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed then.

[Bug ipa/103818] [12 Regression] ICE: in insert, at ipa-modref-tree.c:591 since r12-3202-gf5ff3a8ed4ca9173

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
For 128-bit math, you can e.g. use poly_offset_int, which generally looks like
a better type for these offsets and sizes (especially if they are counted in
bits not bytes).
Just to perform the <= comparison on the wider poly_offset_int, perhaps:
--- gcc/ipa-modref-tree.cc.jj   2022-04-06 16:44:44.0 +0200
+++ gcc/ipa-modref-tree.cc  2022-04-11 17:50:02.937784764 +0200
@@ -380,9 +380,13 @@ modref_access_node::update2 (poly_int64
 new_max_size = max_size2;
   else
 {
-  new_max_size = max_size2 + offset2 - offset1;
-  if (known_le (new_max_size, max_size1))
+  poly_offset_int n = max_size2;
+  n += offset2;
+  n -= offset1;
+  if (known_le (n, max_size1))
new_max_size = max_size1;
+  else
+   new_max_size = max_size2 + offset2 - offset1;
 }

   update (parm_offset1, offset1,
(though, not sure how can you narrow that back to poly_int64).
Though, the big question is what should one do with these overflows or
underflows that aren't representable, update2 can't fail right now and the
above still ICEs.
Is there some way how to indicate it is an access to an unknown offset?

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60

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

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

--- Comment #2 from Siddhesh Poyarekar  ---
OK, taking a closer look, it looks like clang simply fails to fortify fread
(probably due to https://reviews.llvm.org/D109967 or something similar). 
Modifying the code to use __fread_chk directly:

size_t rdct = __fread_chk (data, __builtin_dynamic_object_size (data, 0),
(size_t)1, rem_sz, fp);

causes clang to crash too because it too comes up with the same __bdos estimate
for size:

```
fread: data=0xf792c0 (dsize: 16344, size: 18446744073709551615), rem_sz=16340
.. read rdct=16340
realloc to=0xf7e490-0xf83489 (newsize=20473)
.. diferent buffer!
fread: data=0xf82484 (dsize: 4101, size: 18446744073709551615), rem_sz=4096
.. read rdct=4096
realloc to=0xf7e490-0xf84489 (newsize=24569)
fread: data=0xf83484 (dsize: 5, size: 18446744073709551615), rem_sz=4096
*** buffer overflow detected ***: terminated
Aborted (core dumped)
```

dsize and size are the actual values that __bdos and __bos resolve to; I simply
modified the fprintf to this:

fprintf(stderr, "fread: data=%p (dsize: %zu, size: %zu), rem_sz=%d\n",
data, __builtin_dynamic_object_size (data, 0), __builtin_object_size (data, 0),
rem_sz);

I haven't looked too closely at the failure mechanism (I will tomorrow), but
this has got me inclined to think that it's an actual autogen bug that got
exposed with _FORTIFY_SOURCE=3.

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
   Last reconfirmed||2022-4-11

--- Comment #1 from Tamar Christina  ---
Smaller reproducer getting rid of the loop nest and simplify the inner
condition.

int a; 
   
   
   char b[60];
short d[19];
long long f;

__attribute__ ((noinline, noipa))  
   
   
   void e(int g, int h, short k[19]) {
for (signed j = 1; j < h + 14; j++) {
  int i = 0;
  b[j] = 1;
  i = 2;
  b[i * 14 + j] = 1;
  a = g ? k[j] : 0;
}
}

__attribute__ ((optimize("O0")))
int main() {
  e(9, 1, d);
  for (long l = 0; l < 6; ++l)
for (long m = 0; m < 4; ++m)
  f ^= b[l + m * 4];
  if (f)
__builtin_abort ();
}

and the -mtune=thunderx doesn't seem needed. I can reproduce with just -O3
-march=armv8.2-a+sve -msve-vector-bits=128.

the write to `a` itself is significant not for the result but to block the loop
from being optimized to a memset.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

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

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

--- Comment #48 from Jakub Jelinek  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #47)
> Sorry for the delay: I haven't been well lately.

I'm sorry to hear that.

Anyway, I'm out of ideas and unfortunately Solaris/x86 is not on GCCFarm.

Why is this a P1 when Solaris/x86 is neither primary nor secondary though?
Unless it reproduces also on Solaris/SPARC, which is primary but is on GCCFarm.

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r12-8087-gab0f04e4df1b7b312a4c9fa9b4d675778a0bae86
Author: Alexandre Oliva 
Date:   Mon Apr 11 12:11:10 2022 -0300

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.


for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

[Bug c++/105220] Incorrect concept evaluation when friend class is involved

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-11
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.3.0, 11.2.0, 12.0

--- Comment #1 from Patrick Palka  ---
Confirmed, reduced rejects-valid testcase:

template
concept fooable = requires(T t) { t.foo(); };

template
struct A;// #1

template
struct A { }; // #2

struct B {
private:
  friend struct A;
  void foo();
};

A a; // should use #2


When determining whether to use #1 or #2 for A, we check #2's constraints in
the context of the template rather than the context of the specialization, so
the friend declaration doesn't apply.  Thus one workaround is to declare a
template friend instead:

  template friend struct A;

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:4132f6ba9583e128a00d55961ae8c8e7245b2223

commit r12-8084-g4132f6ba9583e128a00d55961ae8c8e7245b2223
Author: Kito Cheng 
Date:   Mon Apr 11 16:29:34 2022 +0800

RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator.
[PR104853]

We migrate the default ISA spec version from 2.2 to 20191213, but those
scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.

gcc/ChangeLog:

PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
multilib-generator.
* config/riscv/arch-canonicalize: Adding -misa-spec option.
(SUPPORTED_ISA_SPEC): New.
(arch_canonicalize): New argument `isa_spec`.
Handle multiple ISA spec versions.
* config/riscv/multilib-generator: Adding -misa-spec option.

[Bug c++/105222] gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #3 from 康桓瑋  ---
(In reply to 康桓瑋 from comment #2)
> And gcc accepts the following invalid syntax:
> 
> int main() {
>   auto b = requires { true ? [] : [] {}; };
> }
> 
> https://godbolt.org/z/xeE1oYs1Y

It seems like the single [] makes gcc totally broken.

int main() {
  auto b = requires { true ? [] : []!-!-[]?[]; };
}

https://godbolt.org/z/EPTE6zf5E

[Bug middle-end/105206] mis-optimization with -ffast-math and __builtin_powf

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Hm, it works for me on linux with glibc, can you be more specific as to what
> OS/libc (version) you are using?
> 
> foof:
> .LFB0:
> .cfi_startproc
> mulss   .LC0(%rip), %xmm0
> jmp expf
> 
> food:
> .LFB1:
> .cfi_startproc
> mulsd   .LC1(%rip), %xmm0
> jmp exp

Richard, I'm using x86_64-*-freebsd.  I just checked with powl(), and got 
fool:
.LFB5:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
flds.LC0(%rip)
pushq   24(%rbp)
pushq   16(%rbp)
fstpt   -16(%rbp)
movq-16(%rbp), %rax
movl-8(%rbp), %edx
pushq   %rdx
pushq   %rax
callpowl
addq$32, %rsp
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

with -ffast-math.

This might be related to PR89125.  The patch I attached to that PR has never
found its way into the repository.  I'll do some more testing later today.

[Bug c++/105222] gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #2 from 康桓瑋  ---
And gcc accepts the following invalid syntax:

int main() {
  auto b = requires { true ? [] : [] {}; };
}

https://godbolt.org/z/xeE1oYs1Y

[Bug c++/105222] gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
gcc rejects this valid syntax with

source>:2:32: error: expected ':' before '{' token
2 |   auto b = requires { true ? [] {} : [] {}; };
  |^~
  |:
:2:33: error: expected primary-expression before '{' token
2 |   auto b = requires { true ? [] {} : [] {}; };
  | ^
:2:35: error: expected ';' before ':' token
2 |   auto b = requires { true ? [] {} : [] {}; };
  |   ^~
  |   ;

https://godbolt.org/z/4c3PPb5Pb

[Bug c++/105222] New: gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105222
   Summary: gcc rejects valid syntax of ternary operator for
lambda in requires clause
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

int main() {
  auto b = requires { true ? [] {} : [] {}; };
}

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 52783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52783=edit
gcc12-pr105218.patch

Untested fix.

[Bug c++/105221] New: gcc rejects true ? [](auto) noexcept {} : [](int) {}

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105221
   Summary: gcc rejects true ? [](auto) noexcept {} : [](int) {}
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

int main() {
  true ? [](auto) noexcept {} : [](int) {};
}

GCC-trunk only accepts the above code in C++14 but rejects it in C++17/20.
https://godbolt.org/z/7r4dKbo73

But it seems like it should be well-formed, you can see the explanation in SO:
https://stackoverflow.com/questions/71826315/ternary-operator-applied-to-different-lambdas-produces-inconsistent-results

[Bug target/105197] [12 Regression] SVE: wrong code with -O -ftree-vectorize

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #6 from Tamar Christina  ---
Fixed and no regression from codegen in GCC-11.

[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug analyzer/105103] RFE: detect bogus use of varargs in analyzer

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
I have a prototype implementation of this in my patch queue for GCC 13.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #45 from Jakub Jelinek  ---
> I'd like to ping the #c44 question.  Thanks.

Sorry for the delay: I haven't been well lately.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #46 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #44 from Jakub Jelinek  ---
> Rainer, for pr80334.C, have you been able to test the #c43 patch?

I did: the test FAILs (SEGV) at -m32 -O0 only, same as for unmodified
trunk.

> As for TLS and alignment, to confirm it is a ld bug, can you try #c29 testcase
> with all of gas + gld, gas + sunld and sunas + sunld (or perhaps just the 
> first
> and last from these)?  If gas + gld works and sunas + sunld don't, it would
> confirm the sun ld bug.

I get the same behaviour in all three cases: foo () returns an 8-byte
aligned address.

[Bug target/105197] [12 Regression] SVE: wrong code with -O -ftree-vectorize

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:78c718490bc2843d4dadcef8a0ae14aed1d15a32

commit r12-8080-g78c718490bc2843d4dadcef8a0ae14aed1d15a32
Author: Tamar Christina 
Date:   Mon Apr 11 15:09:05 2022 +0100

middle-end: Prevent the use of the cond inversion detection code when both
conditions are external. [PR105197]

Previously ifcvt used to enforce that a mask A and the inverse of said mask
be
represented as ~A. So for the masks

  _25 = _6 != 0;
  _44 = _4 != 0;

ifcvt would produce for an operation requiring the inverse of said mask

  _26 = ~_25;
  _43 = ~_44;

but now that VN is applied to the entire function body we get a
simplification
on the mask and produce:

  _26 = _6 == 0;
  _43 = _4 == 0;

This in itself is not a problem semantically speaking (though it does
create
more masks that need to be tracked) but when vectorizing the masked
conditional
we would still detect _26 and _43 to be inverses of _25 and _44 and mark
them
as requiring their operands be swapped.

When vectorizing we swap the operands but don't find the BIT_NOT_EXPR to
remove
and so we leave the condition as is which produces invalid code:

-->vectorizing statement: _ifc__41 = _43 ? 0 : _ifc__40;
created new init_stmt: vect_cst__136 = { 0, ... }
add new stmt: _137 = mask__43.26_135 & loop_mask_111
note:  add new stmt: vect__ifc__41.27_138 = VEC_COND_EXPR <_137,
vect__ifc__40.25_133, vect_cst__136>;

This fixes disabling the inversion detection code when the loop isn't
masked
since both conditional would be external.  We'd then not use the new
cond_code
and would incorrectly still swap the operands.

The resulting code is also better than GCC-11 with most operations now
predicated on the loop mask rather than a ptrue.

gcc/ChangeLog:

PR target/105197
* tree-vect-stmts.cc (vectorizable_condition): Prevent cond swap
when
not masked.

gcc/testsuite/ChangeLog:

PR target/105197
* gcc.target/aarch64/sve/pr105197-1.c: New test.
* gcc.target/aarch64/sve/pr105197-2.c: New test.

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

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||2022-04-11
   Priority|P3  |P1
   Target Milestone|--- |12.0

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase for -O2 -g:
int a, c;

void
foo (void)
{
  int b;
  if (a)
b = c;
  if (a)
b = b == 2 ? b == 2 : b;
  while (b)
;
}

[Bug c++/105220] New: Incorrect concept evaluation when friend class is involved

[martin.koch at bachmann dot info via Gcc-bugs]

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

Bug ID: 105220
   Summary: Incorrect concept evaluation when friend class is
involved
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.koch at bachmann dot info
  Target Milestone: ---

Assume we have a concept which checks whether a type implements a method foo:
template 
concept fooable = requires(const T ) {
t.foo();
};

And a class makes use of this concept:
template 
requires fooable
struct A { ... }

And some other class declares A as a friend:
class B {
   private:
friend struct A;
void foo() const {
std::cout << "foo called" << std::endl;
}
};

In this case B is not considered "fooable" in the template specialization of
A.
With clang it works fine. See: https://godbolt.org/z/8qWrPfd4b

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

--- Comment #2 from Jakub Jelinek  ---
Actually, I've managed to reproduce even on x86_64-linux.

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Likely wrong code with  |Likely wrong code with
   |-D_FORTIFY_SOURCE=3 |-D_FORTIFY_SOURCE=3 since
   ||r12-6482-g06bc1b0c539e3a60

--- Comment #1 from Martin Liška  ---
Started with r12-6482-g06bc1b0c539e3a60.

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can you please attach preprocessed source + command line?
Seems it is caused by my r12-8078-ga42aa68bf1ad745a6b36ab9beed1fc2e77ac3f88
change...

[Bug target/105219] New: [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

Bug ID: 105219
   Summary: [12 Regression] SVE: Wrong code with -O3
-msve-vector-bits=128 -mtune=thunderx
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following C program appears to be miscompiled with -O3 -march=armv8.2-a+sve
-msve-vector-bits=128 -mtune=thunderx :

int a;
char b[60];
short c[18];
short d[4][19];
long long f;
void e(int g, int h, short k[][19]) {
  for (signed i = 0; i < 3; i += 2)
for (signed j = 1; j < h + 14; j++) {
  b[i * 14 + j] = 1;
  c[i + j] = k[2][j];
  a = g ? k[i][j] : 0;
}
}
int main() {
  e(9, 1, d);
  for (long l = 0; l < 6; ++l)
for (long m = 0; m < 4; ++m)
  f ^= b[l + m * 4];
  if (f)
__builtin_abort ();
}

Of course the choice of tuning is not sensible when asking for SVE, but GCC
shouldn't produce wrong code in any case. I can't reproduce the problem with
GCC 11.

[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 52782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52782=edit
gcc12-pr105214.patch

Untested fix.
Another option would be not to call emit_jump (label2); but instead
  emit_jump_insn (targetm.gen_jump (label2));
  emit_barrier ();
Either we need to do pending stack adjustment before the conditional jump,
or can't do it on the unconditional jump (in the function it basically emits if
(cond) { ... } else { ... }).

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

[Bug bootstrap/105218] New: [12 regression] bootstrap build error in mpc in stage3

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

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

Bug ID: 105218
   Summary: [12 regression] bootstrap build error in mpc in stage3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This happens during stage 3 and started overnight.  I am still looking for
where it started.

libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-fchecking=1 -DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/mpc/src -I..
-I/home/seurer/gcc/git/build/gcc-test/./gmp
-I/home/seurer/gcc/git/gcc-test/mpfr/src -g -O2 -fchecking=1 -MT mul.lo -MD -MP
-MF .deps/mul.Tpo -c /home/seurer/gcc/git/gcc-test/mpc/src/mul.c -o mul.o
/home/seurer/gcc/git/gcc-test/mpc/src/mul.c: In function 'mpc_mul_karatsuba':
/home/seurer/gcc/git/gcc-test/mpc/src/mul.c:204:1: error: definition in block
13 does not dominate use in block 14
  204 | mpc_mul_karatsuba (mpc_ptr rop, mpc_srcptr op1, mpc_srcptr op2,
mpc_rnd_t rnd)
  | ^
for SSA_NAME: rnd_re_274 in statement:
# DEBUG D#5 => rnd_re_274 != 3 ? rnd_re_274 : 2
during GIMPLE pass: phiopt
/home/seurer/gcc/git/gcc-test/mpc/src/mul.c:204:1: internal compiler error:
verify_ssa failed
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[5]: *** [Makefile:584: mul.lo] Error 1

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2021-09-03 00:00:00 |2022-4-11

--- Comment #31 from Richard Biener  ---
For the testcase I still see 58 vmovq GPR <-> XMM at -Ofast -march=znver2,
resulting from spilling of xmms.  And there's still cases like

movq.LC0(%rip), %rax
...
vmovq   %rax, %xmm2
vmovq   %rax, %xmm4

Honza - you said you wanted to have some look here.  As I understand Vlad
costing isn't taken into account when choosing alternatives for reloading.

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-11
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/105217] New: Likely wrong code with -D_FORTIFY_SOURCE=3

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

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

Bug ID: 105217
   Summary: Likely wrong code with -D_FORTIFY_SOURCE=3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
  Target Milestone: ---

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

Isolated from autogen, where we originally created the following issue:
https://sourceforge.net/p/autogen/bugs/212/

I isolated that to the attached test-case:

$ head -c 20k  /tmp/1
$ gcc snippet.c -O2 -D_FORTIFY_SOURCE=3 -g && ./a.out /tmp/1
fread: data=0x2052c0, rem_sz=16340
.. read rdct=16340
realloc to=0x20a490-0x20f489 (newsize=20473)
.. diferent buffer!
fread: data=0x20e484, rem_sz=4096
.. read rdct=4096
realloc to=0x20a490-0x210489 (newsize=24569)
fread: data=0x20f484, rem_sz=4096
*** buffer overflow detected ***: terminated
Aborted (core dumped)

$ clang snippet.c -O2 -D_FORTIFY_SOURCE=3 -g && ./a.out /tmp/1
fread: data=0x4052c0, rem_sz=16340
.. read rdct=16340
realloc to=0x40a490-0x40f489 (newsize=20473)
.. diferent buffer!
fread: data=0x40e484, rem_sz=4096
.. read rdct=4096
realloc to=0x40a490-0x410489 (newsize=24569)
fread: data=0x40f484, rem_sz=4096
.. read rdct=44
fread: data=0x40f4b0, rem_sz=4052
.. read rdct=0

[Bug c/50486] No warning at signed -> unsigned casting

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

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

--- Comment #3 from Manuel López-Ibáñez  ---
Clang warns:

 :16:18: warning: implicit conversion changes signedness: 'int' to
'enum e' [-Wsign-conversion]
return a(-1);
   ~ ^~

Not sure why gcc doesn't but it should.

[Bug c++/100370] [11/12 Regression] Incorrect -Wplacement-new with union

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:790b02af6a1fcfa07dba6129909b3578a55a51fa

commit r12-8079-g790b02af6a1fcfa07dba6129909b3578a55a51fa
Author: Jason Merrill 
Date:   Tue Apr 5 22:29:06 2022 -0400

c++: -Wplacement-new and anon union member [PR100370]

This bug was an object/value confusion; we are interested in the size
of *b.ip, but instead the code was calculating the size of b.ip itself.

This seems to be because compute_objsize will compute the size of whatever
object it can find in the argument: if you pass it a VAR_DECL, it gives you
the size of that variable.  If you pass it an ADDR_EXPR of a VAR_DECL, it
again gives you the size of the variable.  The way you can tell the
difference is by looking at the deref member of access_ref: if it's -1, the
argument is a pointer to the object.  Since that's what we're interested
in,
we should check for that, like check_dangling_stores does.

This regressed some tests because compute_objsize_r was wrongly zeroing
deref in the POINTER_PLUS_EXPR handling; adding an offset to a pointer
doesn't change whether the pointer is itself a variable or a pointer to
one.  In fact, handling POINTER_PLUS_EXPR only really makes sense for deref
== -1, where we're adjusting a pointer to the variable.

PR c++/100370

gcc/cp/ChangeLog:

* init.cc (warn_placement_new_too_small): Check deref.

gcc/ChangeLog:

* pointer-query.cc (compute_objsize_r) [POINTER_PLUS_EXPR]: Require
deref == -1.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wplacement-new-size-11.C: New test.

[Bug libstdc++/104301] --enable-cstdio=stdio_pure not passed down to libstdc++-v3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed for 11.3

[Bug libstdc++/97841] [C++17] is_invocable handling of incomplete return type is wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|11.3|11.4

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #8)
> (In reply to rguent...@suse.de from comment #7)
> > On Mon, 11 Apr 2022, crazylht at gmail dot com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105216
> > > 
> > > --- Comment #5 from Hongtao.liu  ---
> > > My bisect shows it's caused by
> > > r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5
> > 
> > So it's a missed jump threading - care to investigate which?
> 
> The commit is about jump threading, but the regression is present without
> -fopenmp， so there's no jump threading?
> Somehow it affects PRE.
Please ignore this comment, obviously i had poor understanding of jump
threading.

[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|sanitizer   |target

--- Comment #4 from Richard Biener  ---
oh, no - misread the bisect

[Bug sanitizer/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

--- Comment #3 from Richard Biener  ---
possibly started earlier if you also add -fexceptions

[Bug sanitizer/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|target  |sanitizer

--- Comment #2 from Richard Biener  ---
I can take a look if you are not working on it.

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to rguent...@suse.de from comment #7)
> On Mon, 11 Apr 2022, crazylht at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105216
> > 
> > --- Comment #5 from Hongtao.liu  ---
> > My bisect shows it's caused by
> > r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5
> 
> So it's a missed jump threading - care to investigate which?

The commit is about jump threading, but the regression is present without
-fopenmp， so there's no jump threading?
Somehow it affects PRE.