[Bug c++/107938] [11/12/13 Regression] ICE directly returning `this` of `extern` variable in template

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rust/105914] gccrs setting warn_unused_variable breaks thousands of non-Rust tests

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/Rust-GCC
   ||/gccrs/pull/1570
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Thomas Schwinge  ---
The issue at hand has been resolved via
 "Apply #1560 master", and my
"patch series adding a 'LangInit(@var{language}, @var{value})' option property"
can then later be applied here, too, once I've got that completed...  ;-|

[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

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

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

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

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

commit r13-4435-g2c089640279614e34b8712bfb318a9d4fc8ac8fe
Author: Jakub Jelinek 
Date:   Thu Dec 1 09:29:23 2022 +0100

i386: Improve *concat3_{1,2,3,4} patterns [PR107627]

On the first testcase we've regressed since 12 at -O2:
-   movq8(%rsi), %rax
-   movq%rdi, %r8
-   movq(%rsi), %rdi
+   movq(%rsi), %rax
+   movq8(%rsi), %r8
movl%edx, %ecx
-   shrdq   %rdi, %rax
-   movq%rax, (%r8)
+   xorl%r9d, %r9d
+   movq%rax, %rdx
+   xorl%eax, %eax
+   orq %r8, %rax
+   orq %r9, %rdx
+   shrdq   %rdx, %rax
+   movq%rax, (%rdi)
On the second testcase we've emitted such terrible code
with the useless xors and ors for a long time.
For PR91681 the *concat3_{1,2,3,4} patterns have been added
but they allow just register inputs and register or memory offsettable
output.
The following patch fixes this by allowing also memory inputs on those
patterns, because the pattern is then split to 0-2 emit_move_insns or
one xchg and those can handle loads from memory too just fine.
So that we don't narrow memory loads (source has 128-bit (or for ia32
64-bit) load and we would make 64-bit (or for ia32 32-bit) load out of it),
register_operand -> nonmemory_operand change is done only for operands
in zero_extend arguments.  o <- m, m or o <- m, r or o <- r, m alternatives
aren't used, we'd lack registers to perform the moves.  But what is
in addition to the current ro <- r, r supported are r <- m, r and r <- r, m
(in that case we just need to be careful about corner cases, see what
emit_move_insn we'd call and if we wouldn't clobber registers used in m's
address before loading - split_double_concat handles that now) and
&r <- m, m (in that case I think the early clobber is the easiest
solution).

The first testcase then on 12 -> patched trunk at -O2 changes:
-   movq8(%rsi), %rax
-   movq%rdi, %r8
-   movq(%rsi), %rdi
+   movq8(%rsi), %r9
+   movq(%rsi), %r10
movl%edx, %ecx
-   shrdq   %rdi, %rax
-   movq%rax, (%r8)
+   movq%r9, %rax
+   shrdq   %r10, %rax
+   movq%rax, (%rdi)
so same amount of instructions and second testcase 12 -> patched trunk
at -O2 -m32:
-   pushl   %edi
-   xorl%edi, %edi
pushl   %esi
-   movl16(%esp), %esi
+   pushl   %ebx
+   movl16(%esp), %eax
movl20(%esp), %ecx
-   movl(%esi), %eax
-   movl4(%esi), %esi
-   movl%eax, %edx
-   movl$0, %eax
-   orl %edi, %edx
-   orl %esi, %eax
-   shrdl   %edx, %eax
movl12(%esp), %edx
+   movl4(%eax), %ebx
+   movl(%eax), %esi
+   movl%ebx, %eax
+   shrdl   %esi, %eax
movl%eax, (%edx)
+   popl%ebx
popl%esi
-   popl%edi

BTW, I wonder if we couldn't add additional patterns which would catch
the case where one of the operands is constant and how does this interact
with the stv pass in 32-bit mode where I think stv is right after combine,
so if we match these patterns, perhaps it would be nice to handle them
in stv (unless they are handled there already).

2022-12-01  Jakub Jelinek  

PR target/107627
* config/i386/i386.md (*concat3_1,
*concat3_2):
For operands which are zero_extend arguments allow memory if
output operand is a register.
(*concat3_3, *concat3_4): Likewise.  If
both input operands are memory, use early clobber on output
operand.
* config/i386/i386-expand.cc (split_double_concat): Deal with
corner
cases where one input is memory and the other is not and the
address
of the memory input uses a register we'd overwrite before loading
the memory into a register.

* gcc.target/i386/pr107627-1.c: New test.
* gcc.target/i386/pr107627-2.c: New test.

[Bug target/107812] [11/12/13 Regression] RTL SSA forwprop introduced regression since r11-6188

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

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

Bug 107627 Summary: [13 Regression] int128_t shift generates extra xor/or.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627

   What|Removed |Added

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

[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/107937] [13 Regression] ICE in find_var_cmp_const, at gimple-predicate-analysis.cc:257 since r13-4408-gb628cad9e093f7a3

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

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

Zhendong Su  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #8 from Zhendong Su  ---
Another test:

[546] % gcctk -O3 -Wall -w small.c
during GIMPLE pass: uninit
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in find_var_cmp_const, at
gimple-predicate-analysis.cc:257
3 | int main() {
  | ^~~~
0x818725 find_var_cmp_const
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:257
0x1c9bfbf uninit_analysis::overlap(gphi*, unsigned int, hash_set >*, predicate const&)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:648
0x1c9bafa uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:2215
0x1c9c0ec uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
../../gcc-trunk/gcc/gimple-predicate-analysis.cc:2249
0x110d500 find_uninit_use
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1234
0x110de96 warn_uninitialized_phi
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1304
0x110de96 execute_late_warn_uninitialized
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1425
0x110de96 execute
../../gcc-trunk/gcc/tree-ssa-uninit.cc:1442
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.
[547] % cat small.c
int printf(const char *, ...);
int a, b;
int main() {
  int c, d;
  while (b) {
if (a) {
  &d;
  c = ~c;
}
printf("0");
while (b && d && c)
  ;
  }
  return 0;
}

[Bug c++/772] Statement expressions issues

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

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

--- Comment #24 from Eric Gallager  ---
(In reply to Eric Gallager from comment #22)
> oops wait I thought this was a meta-bug for a moment... although, maybe it's
> time to start using it as one?

Never mind about this; looks like there's a keyword (stmt-expr) now to use
instead...

[Bug ipa/107944] New: ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7

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

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

Bug ID: 107944
   Summary: ICE in cgraph_node::get_untransformed_body since
r13-48-g27ee75dbe81bb7
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53994&action=edit
Reproducer

I noticed that while building libbackend.a with -flto and partial linking and I
tried to reduce it to something smaller. However, the result is still pretty
big.

$ g++ -w -O2 -flto -c *.ii -fno-exceptions -Wfatal-errors && g++ -Wfatal-errors
-flinker-output=nolto-rel -r -o libbackend.a -flto=1 [123456].o -w
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 3.o
(symbol from plugin): in function `global_trees_6':
(.text+0x0): multiple definition of `integer_types_0'; 1.o (symbol from
plugin):(.text+0x0): first defined here
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 3.o
(symbol from plugin): in function `global_trees_6':
(.text+0x0): multiple definition of `__trans_tmp_2'; 2.o (symbol from
plugin):(.text+0x0): first defined here
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 3.o
(symbol from plugin): in function `global_trees_6':
(.text+0x0): multiple definition of `__trans_tmp_3'; 2.o (symbol from
plugin):(.text+0x0): first defined here
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 6.o
(symbol from plugin): in function `__trans_tmp_1':
(.text+0x0): multiple definition of `__trans_tmp_1'; 2.o (symbol from
plugin):(.text+0x0): first defined here
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 6.o
(symbol from plugin): in function `__trans_tmp_1':
(.text+0x0): multiple definition of `space_nelems'; 4.o (symbol from
plugin):(.text+0x0): first defined here
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: 6.o
(symbol from plugin): in function `__trans_tmp_1':
(.text+0x0): multiple definition of `reserve_reserve'; 4.o (symbol from
plugin):(.text+0x0): first defined here
1.ii:67:8: note: type ‘struct tree_base’ itself violates the C++ One Definition
Rule
   67 | struct tree_base {
  |^
2.ii:452:8: note: the incompatible type is defined here
  452 | struct tree_base {
  |^
2.ii:456:12: note: type ‘struct ’ itself violates the C++ One Definition
Rule
  456 | struct {
  |^
3.ii:340:18: note: the incompatible type is defined here
  340 |   struct {
  |  ^
2.ii:143:7: note: type name ‘hash_table, tree_node*>
>::hash_entry, false, xcallocator>’ should match type name ‘hash_table’
  143 | class hash_table {
  |   ^
3.ii:237:131: note: the incompatible type is defined here
  237 | template  class Allocator = xcallocator> class hash_table {
  |
  ^
2.ii:143:7: note: type ‘struct hash_table’ itself violates the C++ One
Definition Rule
  143 | class hash_table {
  |   ^
3.ii:237:131: note: the incompatible type is defined here
  237 | template  class Allocator = xcallocator> class hash_table {
  |
  ^
lto-wrapper: warning: using serial compilation of 3 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
during IPA pass: inline
In function ‘reserve’,
inlined from ‘reserve’ at 4.ii:210:19,
inlined from ‘reserve’ at 4.ii:199:35,
inlined from ‘safe_push’ at 4.ii:220:10,
inlined from ‘optimize_stmt’ at 4.ii:2254:36:
4.ii:142:52: internal compiler error: Segmentation fault
  142 |   unsigned alloc = vec_prefix::calculate_allocation(v ? &v->m_vecpfx :
0,
  |^
0x102f987 internal_error(char const*, ...)
???:0
0x117935b cgraph_node::get_untransformed_body()
???:0
0x123f6e9 optimize_inline_calls(tree_node*)
???:0
0x123e4d2 inline_transform(cgraph_node*)
???:0
0x123da5f execute_all_ipa_transforms(bool)
???:0
0x15ebe1b cgraph_node::expand()
???:0
0x15e2f6d symbol_table::compile()
???:0
0x15d0368 lto_main()
???:0
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.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated

[Bug ipa/107944] ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100413
   Last reconfirmed||2022-12-01
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
I've got a patch candidate that I'm testing right now. Note the mentioned patch
was backported, that's why I see it with GCC 12 as well.

[Bug tree-optimization/107935] [13 Regression] ICE on valid code at -O3: in set_ssa_val_to, at tree-ssa-sccvn.cc:5011

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

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

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

https://gcc.gnu.org/g:8629f212af0acb113879d0bc45291c54743790f1

commit r13-4436-g8629f212af0acb113879d0bc45291c54743790f1
Author: Richard Biener 
Date:   Thu Dec 1 09:01:20 2022 +0100

tree-optimization/107935 - fixup equivalence handling in PHI VN

The following makes sure to honor the backedge processing logic
that forces VARYING there.

PR tree-optimization/107935
* tree-ssa-sccvn.cc (visit_phi): Honor forced VARYING on
backedges.

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

[Bug tree-optimization/107935] [13 Regression] ICE on valid code at -O3: in set_ssa_val_to, at tree-ssa-sccvn.cc:5011

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

--- Comment #54 from Martin Liška  ---
> Try LTOing libbackend.a?

So this option is not feasible as well, we're paying a too high price for
parallel WPA of the LTO and the resulting time on 32 cores is even slower :/

[Bug ipa/107944] [12/13 Regression] ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in  |[12/13 Regression] ICE in
   |cgraph_node::get_untransfor |cgraph_node::get_untransfor
   |med_body since  |med_body since
   |r13-48-g27ee75dbe81bb7  |r13-48-g27ee75dbe81bb7
   Target Milestone|--- |12.3

[Bug tree-optimization/107937] [13 Regression] ICE in find_var_cmp_const, at gimple-predicate-analysis.cc:257 since r13-4408-gb628cad9e093f7a3

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

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

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

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

commit r13-4437-gabf05583dbc86a6667b63f5bda6ba57fe55a1b25
Author: Richard Biener 
Date:   Thu Dec 1 10:12:28 2022 +0100

tree-optimization/107937 - uninit predicate simplification fixup

The following changes the predicate representation to record the
value of a predicate with an empty set of AND predicates.  That's
necessary to properly represent the conservative fallback for the
def vs use predicates.  Since simplification now can result in
such an empty set this distinction becomes important and we need
to check for this as we otherwise ICE.

PR tree-optimization/107937
* gimple-predicate-analysis.h (predicate::is_true): New.
(predicate::is_false): Likewise.
(predicate::empty_val): Likewise.
(uninit_analysis::uninit_analysis): Properly initialize
def_preds.
* gimple-predicate-analysis.cc (simplify_1b): Indicate
whether the chain became empty.
(predicate::simplify): Release emptied chain before removing it.
(predicate::normalize): Replace temporary object with assertion.
(uninit_analysis::is_use_guarded): Deal with predicates
that simplify to true/false.

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

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

--- Comment #55 from Martin Liška  ---
Created attachment 53995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53995&action=edit
make all-host on Ryzen 9

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

--- Comment #56 from Martin Liška  ---
Created attachment 53996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53996&action=edit
make all-host on Ryzen 9 with LTO partial linking

Using partial linking for the following 4 objects (gimple-match.o
generic-match.o insn-recog.o insn-emit.o), I can speed up build of all-host by
almost 30s from 145 to 115 seconds).

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

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

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

--- Comment #57 from Martin Liška  ---
Created attachment 53997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53997&action=edit
Partial linking path

[Bug libstdc++/107929] std::experimental::simd needs to be reimplemented with GCC's vector extension

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

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

--- Comment #4 from Matthias Kretz (Vir)  ---
I agree that compilation speed is a problem. However,

1. GCC's vector extensions are not sufficient (especially for use of AVX-512
masks)

2. I see 0.6s difference between calling `g++ -O2 -march=skylake` on an empty
file vs. a file that #includes . Whereas #include
 takes about 2.7s.

[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-01
 Ever confirmed|0   |1

--- Comment #10 from Martin Liška  ---
@Honza ?

[Bug analyzer/107943] gcc -fanalyzer hangs in openssl curve25519.c

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can you please provide a pre-processed source file so that I can quickly bisect
it and reduce it? Thanks.

[Bug tree-optimization/107499] [13 Regression] 433.milc regressed by 6-8% on zen3 at -O2 -flto

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
> it to 19295e8607d (tree-optimization/100756 - niter analysis and

g:19295e8607d

[Bug analyzer/107943] gcc -fanalyzer hangs in openssl curve25519.c

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
Created attachment 53998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53998&action=edit
preprocessed source file

[Bug analyzer/107943] gcc -fanalyzer hangs in openssl curve25519.c

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #3 from Bernd Edlinger  ---
this is how far I got with bisecting:

$ git bisect log 
git bisect start
# good: [885f5c3d5763d46e02bd2f192765cb589b4c4fe4] Daily bump.
git bisect good 885f5c3d5763d46e02bd2f192765cb589b4c4fe4
# bad: [24b8b44ea3bc232f4fe8daf24900ccaca98e8280] Daily bump.
git bisect bad 24b8b44ea3bc232f4fe8daf24900ccaca98e8280
# good: [250f234988b6231669a720c52101d3686d645072] testsuite: Fix up
gcc.target/s390/zero-scratch-regs-1.c
git bisect good 250f234988b6231669a720c52101d3686d645072

[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|gcc -fanalyzer hangs in |[11/12/13 Regression] gcc
   |openssl curve25519.c|-fanalyzer hangs in openssl
   ||curve25519.c since
   ||r11-3840-gaf66094d03779377
 Status|WAITING |NEW
   Keywords||needs-reduction

--- Comment #4 from Martin Liška  ---
Started with r11-3840-gaf66094d03779377.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
I doubt the trigger is exactly CONCAT/CONCATN, I don't see those mentioned
anywhere in
the scheduler nor in i386 backend code related to scheduling.
But the DEBUG_INSN with CONCATN in this case contains 16 MEMs, perhaps
something defers some insns for later if that DEBUG_INSN is scheduled.
Not very familiar with the scheduling dumps though.
With:
./xgcc -B ./ -S -O2 -fsched2-use-superblocks -fcompare-debug pr106746.c
-Wno-psabi --param min-nondebug-insn-uid=1 -fdump-tree-all -da
-fsched-verbose=8
I see that it is tick 24 in which insn 10148 is scheduled with -g0 and not
otherwise,
already in tick 21 it is:
 ;;  21-->   10090 xmm7=[dx*0x4+sp+0x8]   
:hsw_decodern,hsw_p23
+;; dependencies resolved: insn   10148
+;; tick updated: insn   10148 into ready
 ;; dependencies resolved: insn   10203
 ;; tick updated: insn   10203 into ready
 ;; dependencies resolved: insn   10202
 ;; tick updated: insn   10202 into ready
 ;; dependencies resolved: insn   10201
 ;; tick updated: insn   10201 into ready
But why, I'm not sure.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #12 from Jakub Jelinek  ---
Alex, please correct me if I'm wrong, but I think the scheduling DEBUG_INSN
decision was that DEBUG_INSNs are somehow taken into account during scheduling,
not completely ignored, so that they actually move together with scheduling
changes.
I know H.J. has posted a patch to ignore for scheduling purposes everything
inside of CONCAT{,N}, but the scheduler itself doesn't specifically check for
those 2 rtxes anywhere, so I don't find anything special on them.  And as has
been tried, ignoring DEBUG_INSNs for all scheduler decisions regresses a lot
(not unsuprisingly), they should be scheduled after insns which produce/store
what they depend on and before later insns that modify the registers/memroy
used in them if possible (or reset if that would affect
how non-DEBUG_INSNs are scheduled relative to each other).  Though, I think
DEBUG_INSNs should be treated as needing no computing resources, with 0
latencies.

[Bug target/107920] [13 Regression] ICE in execute_todo, at passes.cc:2140

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
The update_ssa call is very wrong, you just can't do that for every gimple
backend builtin call you fold, you could have millions of them and update_ssa
is a global whole function expensive function.
Either one doesn't ensure vops are properly updated and queues a
TODO_update_ssa_only_virtuals or so at the end of a pass, or one makes sure to
update it properly.  For the gimple folder, I think only the second option is
reasonable...

[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2022-October
   ||/604743.html

--- Comment #7 from Jakub Jelinek  ---
Have you pinged your patch (and CCed Uros)?

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Assuming fixed.

[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with r8-7132-gb5b33e113434be

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

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #17 from Wilco  ---
(In reply to Rama Malladi from comment #16)
> (In reply to Wilco from comment #15)
> > (In reply to Rama Malladi from comment #14)
> > > This fix also improved performance of 538.imagick_r by 15%. Did you have a
> > > similar observation? Thank you.
> > 
> > No, but I was using -mcpu=neoverse-n1 as my baseline. It's possible
> > -mcpu=neoverse-v1 shows larger speedups, what gain do you get on the overall
> > FP score?
> 
> I was using -mcpu=native and run on a Neoverse V1 arch (Graviton3). Here are
> the scores I got (relative gains of latest mainline vs. an earlier mainline).
> 
> Latest mainline: 0976b012d89e3d819d83cdaf0dab05925b3eb3a0
> Earlier mainline: f896c13489d22b30d01257bc8316ab97b3359d1c

Right that's about 3 weeks of changes, I think
1b9a5cc9ec08e9f239dd2096edcc447b7a72f64a has improved imagick_r.

> geomean   1.03

That's a nice gain in 3 weeks!

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 107413 Summary: Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with 
r8-7132-gb5b33e113434be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413

   What|Removed |Added

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

[Bug c++/107945] New: GCC accepts invalid program involving constexpr static data member of class template

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 107945
   Summary: GCC accepts invalid program involving constexpr static
data member of class template
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following invalid program is accepted by gcc but rejected by clang and
msvc. https://godbolt.org/z/WGz3f75da

```
struct incomplete;
template struct C
{
static constexpr T t{};
};

template
struct myClass {
C new_t() { return {}; }
};

int main() {
myClass d;
d.new_t();
}
```

[Bug tree-optimization/107946] New: [13 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0

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

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

Bug ID: 107946
   Summary: [13 Regression] 507.cactuBSSN_r regresses by ~9% on
znver3 with PGO since r13-3875-g9e11ceef165bc0
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

The revision r13-3875-g9e11ceef165bc0 was supposed to speed up the benchmark,
but it makes it slower w/ -O2 -flto and PGO:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=694.437.0

Similar regression can be seen w/o LTO as well:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=463.437.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c/107947] New: __has_c_attribute incorrectly identifies attribute as supported

[xen0n at gentoo dot org via Gcc-bugs]

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

Bug ID: 107947
   Summary: __has_c_attribute incorrectly identifies attribute as
supported
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xen0n at gentoo dot org
  Target Milestone: ---

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

The gcc trunk incorrectly indicates that the [[noreturn]] spelling of the
noreturn attribute works on -std=gnu99 with the attached source:

> $ ./gcc/xgcc -B./gcc -E -P -std=gnu99 ../x.h
> C standard version is 199901L, has "__has_c_attribute"
> "__has_c_attribute(noreturn)" = 202202

This is commit abf05583dbc86a6667b63f5bda6ba57fe55a1b25, while:

> $ gcc-12.1.1 -E -P -std=gnu99 x.h
> C standard version is 199901L, has "__has_c_attribute"
> "__has_c_attribute(noreturn)" = 0

and:

> $ clang-15 -E -P -std=gnu99 x.h
> 
> C standard version is 199901L, has "__has_c_attribute"
> "__has_c_attribute(noreturn)" = 0

I haven't bisected yet but can help doing so if necessary. One of the affected
code in the wild is the fresh tzdb-2022g from https://www.iana.org/time-zones.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[xen0n at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from WANG Xuerui  ---
The corresponding Gentoo bug is at https://bugs.gentoo.org/883719.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Yes it is supported with -std=gnu99.
The bug is in tzdata where it does:
static [[noreturn]] void f();
That is invalid, the attribute cannot be in the middle of a declaration
specification rather it should be before or after.

[Bug tree-optimization/107937] [13 Regression] ICE in find_var_cmp_const, at gimple-predicate-analysis.cc:257 since r13-4408-gb628cad9e093f7a3

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
So we have

((getk_intersect_line_with_ycylinder_r.0_19 < 0.0) AND
(getk_intersect_line_with_ycylinder_r.0_19 u>= 0.0) AND (NOT (_180 != 0)))

from

 [local count: 711980952]:
# k2_184 = PHI 
# prephitmp_96 = PHI <_182(74), getk_intersect_line_with_ycylinder_i.4_30(81)>
getk_intersect_line_with_ycylinder_r.0_19 =
getk_intersect_line_with_ycylinder_r;
if (getk_intersect_line_with_ycylinder_r.0_19 < 0.0)
  goto ; [14.99%]
else
  goto ; [85.01%]

 [local count: 106727384]:
if (getk_intersect_line_with_ycylinder_r.0_19 u>= 0.0)
  goto ; [99.95%]
else
  goto ; [0.05%]

and we simplify that to true which is bogus.  It's correct to remove
this false sub-predicate from the (a || b || c ...) chain but when
it's the last the result is false, not true.

Fixed.

[Bug analyzer/107948] New: GCC Static Analyzer doesn't realize `0 - width <= 0` is always true when `width > 0` and `width is int` type，

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Bug ID: 107948
   Summary: GCC Static Analyzer doesn't realize `0 - width <= 0`
is always true when `width > 0` and `width is int`
type，
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

I got a false negative error when compiling the following program with
gcc(trunk) -fanalyzer -O0. https://godbolt.org/z/vneenabc5

```
extern void __analyzer_eval (int);

void foo(int width) {
int i = 0;
int base;
if (width > 0){
__analyzer_eval(i == 0);
__analyzer_eval(width > 0);
__analyzer_eval(width - i > 0);
__analyzer_eval(i - width <= 0);
if (i - width <= 0) {
base = 512;
}
}
base+=1;
}
```

Output:
```
: In function 'foo':
:7:9: warning: TRUE
7 | __analyzer_eval(i == 0);
  | ^~~
:8:9: warning: TRUE
8 | __analyzer_eval(width > 0);
  | ^~
:9:9: warning: TRUE
9 | __analyzer_eval(width - i > 0);
  | ^~
:10:9: warning: UNKNOWN
   10 | __analyzer_eval(i - width <= 0);
  | ^~~
:15:9: warning: use of uninitialized value 'base' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   15 | base+=1;
  | ^~~
  'foo': events 1-3
|
|5 | int base;
|  | ^~~~
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 4 bytes
|..
|   15 | base+=1;
|  | ~~~
|  | |
|  | (3) use of uninitialized value 'base' here

```

GCC Static Analyzer doesn't realize `0 - width <= 0` is always true when `width
> 0` and `width is int type`，hence it reports a wrong
use-of-uninitialized-value warning.

The analysis result shows that analyzer knows `width - i > 0` is true but does
not know the equivalence formula ` i - width <= 0` is also true.

[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377

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

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

--- Comment #5 from Martin Liška  ---
Created attachment 54000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54000&action=edit
Partially reduced test-case

[Bug tree-optimization/107927] vector::push_back gives array bounds warning with optimization and undefined sanitizer

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

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

--- Comment #4 from Jonathan Wakely  ---
It might be fixed by r13-4393-gcca06f0d6d76b0

[Bug libstdc++/107940] temp_directory_path testcase broken

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

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

--- Comment #5 from Jonathan Wakely  ---
Something seems very broken, and I don't think it's libstdc++.

[Bug middle-end/107941] json diagnostics format does not include header stack info

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||dmalcolm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #13 from Segher Boessenkool  ---
DEBUG_INSNs should never influence any scheduling decisions, or any other
decisions that influence what machine code we generate.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #13)
> DEBUG_INSNs should never influence any scheduling decisions, or any other
> decisions that influence what machine code we generate.

Well, with the exception of scheduling decisions for the DEBUG_INSNs themselves
(where exactly to place them).
haifa-sched.cc is full of various DEBUG_INSN related checks, in some cases
DEBUG_INSNs are ignored, in other places they are taken into account, ...
And in the end, most of the time it works fine for -fcompare-debug checks; it
doesn't for this testcase, so that needs to be understood why and fixed.

[Bug target/107678] [13 Regression] Segfault in aarch64_fallback_frame_state when running SVE code

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #5 from Wilco  ---
It's not related to SVE unwinding since adding +nosve still fails. The crash
happens after reading the correct return address from the stack. However the
top bits of this value get corrupted, resulting in an illegal access in
aarch64_fallback_frame_state (it seems doing an unconditional read is a bad
idea since at this point the RA may be corrupted).

[Bug middle-end/105204] -Wuse-after-free=1 inconsistency with conditional free

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #3 from Avi Kivity  ---
Does one have to declare all preconditions? I happen to know that shared_ptr
with a reference count of zero is impossible, and I can understand the compiler
not being able to infer it, but just because it's unable to infer it doesn't
mean my code is wrong.

Maybe the warning should be renamed -Wmaybe-use-after-free to indicate the
compiler just thinks there may be a bug, but also acknowledges it doesn't know
everything.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to WANG Xuerui from comment #0)
> I haven't bisected yet but can help doing so if necessary.

Bisection shows that it changed with r13-2976 which is the commit that added
support for the [[noreturn]] attribute. So it's totally correct that
__has_c_attribute starts to be non-zero then, because it started to be
supported then.

c: C2x noreturn attribute

C2x adds a standard [[noreturn]] attribute (which can also be spelt
[[_Noreturn]] for use with ), so allowing non-returning
functions to be declared in a manner compatible with C++; the
_Noreturn function specifier remains available but is marked
obsolescent.

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

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

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

--- Comment #15 from Segher Boessenkool  ---
Yup.  I don't consider DEBUG_INSNs to be scheduled at all, only real things
are, but that is just vague terminology :-)

[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)

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

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

--- Comment #5 from Martin Liška  ---
@Honza: ?

[Bug c++/107539] [13 Regression] ICE, same canonical type node for different types with decltype inside an generic lambda inside a templated method of a templated class using a templated class argumen

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/107946] [13 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #1 from Richard Biener  ---
Nope, it wasn't supposed to speedup the benchmark but it indeed (with -Ofast)
causes the hot loop kernels to be unswitched.

Btw, do we know if train and ref data align up in these loops?

Btw, with -Ofast on znver2 I didn't observe any change when benchmarking this.

I'm trying to reproduce.

OK, so with -O2 -flto -march=znver2 and FDO I get a runtime of 173s while
adding -fno-unswitch-loops gets me 188s.  There's currently no knob to
specifically disable outer loop unswitching so I have to instead patch
that up.  With -O2 -flto -funswitch-loops (w/o FDO) I get 178s.  I'm going
to add a --param to allow easier reproduction.

[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)

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

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

--- Comment #6 from Jakub Jelinek  ---
And yet another option would be to change the IFN_TRAP to a normal builtin with
space in name so users couldn't access it, which would somewhat simplify the
IPA code; for replacing a normal call stmt with internal call we don't have any
helper functions right now and we'd need to throw away the edge, while if it is
a normal builtin, we could just return that builtin from
builtin_decl_unreachable instead of __builtin_trap.

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

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

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

--- Comment #4 from Andrew Pinski  ---
To expand on the invalid placement of the attribute, the C++ front-end also
rejects it and also see PR 101682 which is also asking about it, gnulib was
broken at one point.

I did find that clang accepts the invalid placement of the attribute for its C
front-end in non-pedantic mode which might be the reason why some folks think
it should work.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, I think this is just a user error.  Define always_inline functions before
their uses if you want them inlined.

[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[13 Regression] mangling|[13 Regression] mangling
   |conflicts with a previous   |conflicts with a previous
   |mangle  |mangle since r13-3601
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r13-3601-g2b0e81d5cc2f7e1d773f6c502bd65b097f392675

[Bug middle-end/107941] json diagnostics format does not include header stack info

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

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

--- Comment #2 from David Malcolm  ---
Does the SARIF output format contain the information you need?

[Bug target/107863] [10/11/12/13 Regression] ICE with unrecognizable insn when using -funsigned-char with some SSE/AVX builtins

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
.

[Bug tree-optimization/107946] [13 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0

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

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

--- Comment #2 from Richard Biener  ---
So with --param max-unswitch-depth=1 and -O2 -flto -march=znver2 + FDO I get
176s which is slower than with unswitching outer loops.

Means I cannot reproduce (at least with this specific feature, aka this
revision).

[Bug middle-end/107941] json diagnostics format does not include header stack info

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to David Malcolm from comment #2)
> Does the SARIF output format contain the information you need?

No it does not:
{"$schema":
"https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json";,
"runs": [{"results": [{"level": "error", "ruleId": "error", "locations":
[{"physicalLocation": {"contextRegion": {"startLine": 1, "snippet": {"text":
"int asdfg dsfg;\n"}}, "artifactLocation": {"uri": "t.h", "uriBaseId": "PWD"},
"region": {"startLine": 1, "endColumn": 15, "startColumn": 11}}}], "message":
{"text": "expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘dsfg’"}}],
"artifacts": [{"location": {"uri": "t.h", "uriBaseId": "PWD"},
"sourceLanguage": "c", "contents": {"text": "int asdfg dsfg;\n"}}], "tool":
{"driver": {"fullName": "GNU C17 (GCC) version 13.0.0 20221130 (experimental)
[master c382832afd5] (x86_64-pc-linux-gnu)", "name": "GNU C17", "rules": [],
"informationUri": "https://gcc.gnu.org/gcc-13/";, "version": "13.0.0 20221130
(experimental) [master c382832afd5]"}}, "originalUriBaseIds": {"PWD": {"uri":
"file:///home/apinski/src/upstream-gcc/"}}}], "version": "2.1.0"}

[Bug middle-end/107941] json diagnostics format does not include header stack info

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

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

--- Comment #4 from Andrew Pinski  ---
diagnostic_report_current_module in diagnostic.cc is what outputs the include
stack for the text output case.

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

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

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

--- Comment #4 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc/2014-January/211652.html

[Bug bootstrap/80677] LIMITS_H_TEST is wrong

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

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

--- Comment #5 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2017-April/472727.html

[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
printf isn't needed, -O2:
int a, b[1] = { 0 }, c, *d = b, e, *f, g;

__attribute__((noipa)) int
foo (const char *x)
{
  (void) x;
  return 0;
}

int
main ()
{
  for (int h = 0; a < 2; a++)
{
  int i;
  for (g = 0; g < 2; g++)
if (a < h)
  {
e = i % 2;
c = *f;
  }
  for (h = 0; h < 3; h++)
{
  if (d)
break;
  i--;
  foo ("0");
}
}
  return 0;
}

is miscompiled as well.

[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with r8-7132-gb5b33e113434be

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #18 from Rama Malladi  ---
(In reply to Wilco from comment #17)
> (In reply to Rama Malladi from comment #16)
> > (In reply to Wilco from comment #15)
> > > (In reply to Rama Malladi from comment #14)
> > > > This fix also improved performance of 538.imagick_r by 15%. Did you 
> > > > have a
> > > > similar observation? Thank you.
> > > 
> > > No, but I was using -mcpu=neoverse-n1 as my baseline. It's possible
> > > -mcpu=neoverse-v1 shows larger speedups, what gain do you get on the 
> > > overall
> > > FP score?
> > 
> > I was using -mcpu=native and run on a Neoverse V1 arch (Graviton3). Here are
> > the scores I got (relative gains of latest mainline vs. an earlier 
> > mainline).
> > 
> > Latest mainline: 0976b012d89e3d819d83cdaf0dab05925b3eb3a0
> > Earlier mainline: f896c13489d22b30d01257bc8316ab97b3359d1c
> 
> Right that's about 3 weeks of changes, I think
> 1b9a5cc9ec08e9f239dd2096edcc447b7a72f64a has improved imagick_r.
> 
> > geomean 1.03
> 
> That's a nice gain in 3 weeks!

Yes, indeed :-) ... Thank you.

[Bug libstdc++/107940] temp_directory_path testcase broken

[laurent.alfonsi at linaro dot org via Gcc-bugs]

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

--- Comment #6 from laurent.alfonsi at linaro dot org  ---
testing with other versions.

[Bug target/107678] [13 Regression] Segfault in aarch64_fallback_frame_state when running SVE code

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

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

Wilco  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org

--- Comment #6 from Wilco  ---
So the issue is that AArch64 return address signing was using the loc.offset
field which is now uninitialized. The fix is to check for REG_UNSAVED first and
use that to initialize the offset. I'm testing a patch.

[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

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

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

--- Comment #8 from Jakub Jelinek  ---
I think this is CCP's fault rather than VRP.
Everything I've looked at in the vrp2 dump looks right to me.
In the outer loop, h/i is
  # RANGE [irange] int [0, 3] NONZERO 0x3
  # h_41 = PHI 
  # i_44 = PHI 
and the second inner loop has
  _13 = (unsigned int) i_44; // This is before the second inner loop
...
   [local count: 304150043]:
  # i_42 = PHI 
  _50 = (unsigned int) i_42;
  _17 = -_50;
  _34 = _13 - _50;
  # RANGE [irange] int [0, 2] NONZERO 0x3
  h_40 = (int) _34;
where
  i_23 = i_42 + -1;
and
  # h_21 = PHI 
Now, sure, i is uninitialized (the i_19(D) in PHI of the outer loop),
but as has been discussed in the first loop a < h isn't true and so we don't
use
i there, and in the second loop d isn't NULL and so we don't i-- there either,
but
due to the function call we must reread the d value after each iteration.
Which is the reason for the h_40 = (int) ((unsigned) i_44 - i_42) computation
to get h
when d is non-NULL in some iteration - if d is always NULL, it would be 3 in
the PHI.
But ccp4 goes wild on this,
Visiting PHI node: i_44 = PHI 
Argument #0 (8 -> 3 not executable)
Argument #1 (2 -> 3 executable)
i_19(D) Value: UNDEFINED

PHI node value: UNDEFINED

Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
...
Visiting statement:
_13 = (unsigned int) i_44;
which is likely UNDEFINED
Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
...
Visiting statement:
_50 = (unsigned int) i_42;
which is likely UNDEFINED
Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
...
Visiting statement:
# RANGE [irange] int [0, 2] NONZERO 0x3
h_40 = (int) _34;
which is likely UNDEFINED
Lattice value changed to UNDEFINED.  Adding SSA edges to worklist.
etc., everything based on i is UNDEFINED.  So, either our UNDEFINED handlingin
CCP
is incorrect, or we need to avoid creating that h_40 = (int) ((unsigned) i_44 -
i_42)
stuff in IVOPTS if it is based on uninitialized (but then, can't we get an
uninitialized value propagated to it only after IVOPTS?).

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #8 from David Faust  ---
(In reply to James Hilliard from comment #5)
> (In reply to David Faust from comment #4)
> > Created attachment 53993 [details]
> > proposed patch
> > 
> > Should fix the remaining issues with 'extern' linkage and the missing
> > 'const' modifier (and includes the earlier partial fixes in this bug)
> 
> Fixes the reported test failure but some others(unclear if related to this
> bug) are still failing such as tailcall_bpf2bpf3.c:

Thanks for testing and confirming.

> $ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
> --debug gen object
> /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/
> tailcall_bpf2bpf3.bpf.linked1.o
> /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/
> tailcall_bpf2bpf3.bpf.o
> libbpf: linker: adding object file
> '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/
> tailcall_bpf2bpf3.bpf.o'...
> libbpf: failed to find BTF info for global/extern symbol 'llvm.bpf.load.word'
> Error: failed to link

> https://github.com/torvalds/linux/blob/v6.1-rc7/tools/testing/selftests/bpf/bpf_legacy.h
unsigned long long load_word(void *skb,
 unsigned long long off) asm("llvm.bpf.load.word");

Looks like LLVM-specific inline asm to use their llvm.bpf.load.word intrinsic.

GCC has equivalent __builtin_load_{byte,half,word} target builtins.

> There's also this error during skeleton generation for kfunc_call_test.c:
> ...
> libbpf: failed to find BTF for extern 'bpf_kfunc_call_test2': -22

Hm, looks like we are OK for extern variables but are mis-generating something
(or missing something) for extern funcs still. Will look into this.

[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

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

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

--- Comment #9 from Jakub Jelinek  ---
Wasn't this discussed in the past in other PRs?  Whether uninitialized vars
mean anything or anything but same value each time a SSA_NAME initialized to it
is used?
Because as this testcase shows, not all uses of uninitialized SSA_NAMEs are
actually UB, at least their use in PHIs must be ok, and if IVOPTS or other
optimizations can construct some expressions computing a difference between
uninitialized loop iterator's PHI header between several iterations (e.g. to
compute final value), it better would be the second definition rather than the
first.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[me at xenu dot pl via Gcc-bugs]

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

--- Comment #5 from Tomasz Konojacki  ---
To sum this thread up, there are undocumented rules that can cause a
semantically identical program to be rejected by the compiler under certain
optimisation levels (with an uninformative error message) and users are
expected to know them.

Thank you.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

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

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

--- Comment #6 from Jakub Jelinek  ---
If you use always_inline attribute and therefore want an error if some function
isn't inlined, to be precise.  Otherwise it just wouldn't be inlined...

[Bug target/107920] [13 Regression] ICE in execute_todo, at passes.cc:2140

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

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #53992|0   |1
is obsolete||

--- Comment #13 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 54001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54001&action=edit
untested fix 2

Hi Jakub, thanks for the suggestions. The issue with previous patch was it used
gimple_seq_add_stmt, and passed resulting seq to gsi_replace_with_seq_vops. The
attached patch uses gimple_seq_add_stmt_without_update instead, which works to
resolve the issue without calling update_ssa(). Does it look OK ?

Thanks,
Prathamesh

[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars

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

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

--- Comment #9 from Stam Markianos-Wright  ---
> Clearly Helium+Linux on Godbolt is a bit confused 

Yea, I agree -- it still shouldn't be an unintuitive front-end type clash
error, though!

I've posted another patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607675.html (see there
for what the error was --- interestingly it was coming from `__ARM_mve_coerce3`
and it didn't directly have anything to do with the float types)

[Bug c/107947] __has_c_attribute incorrectly identifies attribute as supported

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #5 from eggert at cs dot ucla.edu ---
Thanks for reporting the conformance bug in TZDB. I fixed it in the TZDB
development repository here:

https://github.com/eggert/tz/commit/9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f

and the fix should appear in the next TZDB release.

[Bug libstdc++/107929] std::experimental::simd needs to be reimplemented with GCC's vector extension

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
1. the real gap is much larger due to larger preprocessor space.
2. that is just an excuse. the mm_ intrinsic is implemented with builtin
functions on gcc and clang. You can always avoid include that header by using
builtin functions. There is no reason to include headers.
3. You really need that to support none x86 none arm platforms

Get Outlook for Android

From: mkretz at gcc dot gnu.org 
Sent: Thursday, December 1, 2022 5:07:42 AM
To: unlv...@live.com 
Subject: [Bug libstdc++/107929] std::experimental::simd needs to be
reimplemented with GCC's vector extension

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

--- Comment #4 from Matthias Kretz (Vir)  ---
I agree that compilation speed is a problem. However,

1. GCC's vector extensions are not sufficient (especially for use of AVX-512
masks)

2. I see 0.6s difference between calling `g++ -O2 -march=skylake` on an empty
file vs. a file that #includes . Whereas #include
 takes about 2.7s.

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100810

--- Comment #10 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #9)
> Wasn't this discussed in the past in other PRs?  Whether uninitialized vars
> mean anything or anything but same value each time a SSA_NAME initialized to
> it is used?

I think you are talking about PR 100810 and the discussions around the patch
that fixed that.

[Bug libstdc++/107940] temp_directory_path testcase broken

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to laurent.alfo...@linaro.org from comment #0)
> sanitizer=address reports an issue while stack unwinding :
> 
> ==13419==ERROR: AddressSanitizer: SEGV on unknown address 0x
> (pc 0x0055012adf14 bp 0x0055007ff090 sp 0x0055007ff090 T0)
> ==13419==The signal is caused by a UNKNOWN memory access.
> ==13419==Hint: address points to the zero page.

The uninitialized memory dealing with the stack unwinding is recorded as PR
107678 and a patch was sent here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607668.html (maybe that
will fix the issue recorded here too).

[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Gallager  ---
I guess I can take this

[Bug c++/107945] GCC accepts invalid program involving constexpr static data member of class template

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

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

--- Comment #1 from Andrew Pinski  ---
Reduced:
```
struct incomplete;
template struct C
{
static constexpr T t{};
};


int main() {
C t;
   // t.t;
}
```
If we uncomment t.t, then GCC will reject it.

[Bug c++/107945] GCC accepts invalid program involving constexpr static data member of class template

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

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

--- Comment #2 from Andrew Pinski  ---
ICC has the same behavior as GCC, though I don't know if it was EDG marking
this as an extension or not.

[Bug c++/107945] static constexpr incomplete (depedent) data member of a class template and in-member initialized accepted

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|static incomplete   |static constexpr incomplete
   |(depedent) data member of a |(depedent) data member of a
   |class template accepted |class template and
   ||in-member initialized
   ||accepted
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-01

--- Comment #3 from Andrew Pinski  ---
If we make the field not depedent then GCC rejects it:
```
struct incomplete;
template
struct C
{
static constexpr incomplete t{};
};
```

Confirmed.

[Bug c++/104160] Wrongly allowed: Function argumentin constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Dup of bug 79083.

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

[Bug c++/79083] GCC incorrectly compiles calls to constexpr static methods via a non-constexpr variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||stephan.oostveen@nextlevel-
   ||electronics.com

--- Comment #2 from Andrew Pinski  ---
*** Bug 104160 has been marked as a duplicate of this bug. ***

[Bug fortran/107922] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8473

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058563.html

[Bug fortran/107874] merge not using all its arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/107874] merge not using all its arguments

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Jerry DeLisle  ---
I am seeing timeout failures with merge_1.f90. Can you look into this?

Thanks,

Jerry

On Thu, Dec 1, 2022, 12:28 PM anlauf at gcc dot gnu.org via Gcc-bugs <
gcc-bugs@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> 
>Target Milestone|--- |13.0
>  Resolution|--- |FIXED
>  Status|ASSIGNED|RESOLVED
>
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> Fixed on mainline for gcc-13.  Closing.
>
> Thanks for the report!

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[david.faust at oracle dot com via Gcc-bugs]

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

David Faust  changed:

   What|Removed |Added

  Attachment #53993|0   |1
is obsolete||

--- Comment #9 from David Faust  ---
Created attachment 54002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54002&action=edit
updated patch

Update the 'extern' variable marking, and also mark 'extern' funcs.

[Bug fortran/107874] merge not using all its arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from anlauf at gcc dot gnu.org ---
Hmmm, I do not see the failures here, but gcc-testresults also shows them.

Can you please attach a tree-dump?

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

--- Comment #10 from James Hilliard  ---
(In reply to David Faust from comment #9)
> Created attachment 54002 [details]
> updated patch
> 
> Update the 'extern' variable marking, and also mark 'extern' funcs.

That fixes the issue in kfunc_call_test.c but I'm still hitting a few like this
in cb_refs.c:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen skeleton
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/cb_refs.bpf.linked3.o
name cb_refs
libbpf: loading object 'cb_refs' from buffer
libbpf: elf: section(2) .symtab, size 504, link 1, flags 0, type=2
libbpf: elf: section(3) .text, size 240, link 0, flags 6, type=1
libbpf: sec '.text': found program 'cb1' at insn offset 0 (0 bytes), code size
4 insns (32 bytes)
libbpf: sec '.text': found program 'cb2' at insn offset 4 (32 bytes), code size
9 insns (72 bytes)
libbpf: sec '.text': found program 'cb' at insn offset 13 (104 bytes), code
size 2 insns (16 bytes)
libbpf: sec '.text': found program 'cb3' at insn offset 15 (120 bytes), code
size 15 insns (120 bytes)
libbpf: elf: section(4) .data, size 0, link 0, flags 3, type=1
libbpf: elf: skipping section(4) .data (size 0)
libbpf: elf: section(5) .bss, size 0, link 0, flags 3, type=8
libbpf: elf: section(6) ?tc, size 648, link 0, flags 6, type=1
libbpf: sec '?tc': found program 'underflow_prog' at insn offset 0 (0 bytes),
code size 17 insns (136 bytes)
libbpf: sec '?tc': found program 'leak_prog' at insn offset 17 (136 bytes),
code size 26 insns (208 bytes)
libbpf: sec '?tc': found program 'nested_cb' at insn offset 43 (344 bytes),
code size 20 insns (160 bytes)
libbpf: sec '?tc': found program 'non_cb_transfer_ref' at insn offset 63 (504
bytes), code size 18 insns (144 bytes)
libbpf: elf: section(7) license, size 4, link 0, flags 3, type=1
libbpf: license of cb_refs is GPL
libbpf: elf: section(8) .maps, size 32, link 0, flags 3, type=1
libbpf: elf: section(9) .comment, size 43, link 0, flags 30, type=1
libbpf: elf: skipping unrecognized data section(9) .comment
libbpf: elf: section(10) .rel.text, size 80, link 2, flags 40, type=9
libbpf: elf: section(11) .rel?tc, size 224, link 2, flags 40, type=9
libbpf: elf: section(12) .BTF, size 468228, link 0, flags 0, type=1
libbpf: looking for externs among 21 symbols...
libbpf: failed to find BTF for extern 'bpf_kfunc_call_test_release' [8112]
section: -2
Error: failed to open BPF object file: No such file or directory

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

--- Comment #11 from James Hilliard  ---
Also hitting this one in cgroup_hierarchical_stats.c:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen skeleton
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/cgroup_hierarchical_stats.bpf.linked3.o
name cgroup_hierarchical_stat
libbpf: loading object 'cgroup_hierarchical_stat' from buffer
libbpf: elf: section(2) .symtab, size 504, link 1, flags 0, type=2
libbpf: elf: section(3) .data, size 0, link 0, flags 3, type=1
libbpf: elf: skipping section(3) .data (size 0)
libbpf: elf: section(4) .bss, size 0, link 0, flags 3, type=8
libbpf: elf: section(5) fentry/cgroup_attach_task, size 264, link 0, flags 6,
type=1
libbpf: sec 'fentry/cgroup_attach_task': found program 'counter' at insn offset
0 (0 bytes), code size 33 insns (264 bytes)
libbpf: elf: section(6) fentry/bpf_rstat_flush, size 656, link 0, flags 6,
type=1
libbpf: sec 'fentry/bpf_rstat_flush': found program 'flusher' at insn offset 0
(0 bytes), code size 82 insns (656 bytes)
libbpf: elf: section(7) iter.s/cgroup, size 352, link 0, flags 6, type=1
libbpf: sec 'iter.s/cgroup': found program 'dumper' at insn offset 0 (0 bytes),
code size 44 insns (352 bytes)
libbpf: elf: section(8) .rodata, size 67, link 0, flags 2, type=1
libbpf: elf: section(9) .maps, size 64, link 0, flags 3, type=1
libbpf: elf: section(10) license, size 4, link 0, flags 3, type=1
libbpf: license of cgroup_hierarchical_stat is GPL
libbpf: elf: section(11) .comment, size 43, link 0, flags 30, type=1
libbpf: elf: skipping unrecognized data section(11) .comment
libbpf: elf: section(12) .relfentry/cgroup_attach_task, size 48, link 2, flags
40, type=9
libbpf: elf: section(13) .relfentry/bpf_rstat_flush, size 96, link 2, flags 40,
type=9
libbpf: elf: section(14) .reliter.s/cgroup, size 64, link 2, flags 40, type=9
libbpf: elf: section(15) .BTF, size 468873, link 0, flags 0, type=1
libbpf: looking for externs among 21 symbols...
libbpf: failed to find BTF for extern 'cgroup_rstat_updated' [8134] section: -2
Error: failed to open BPF object file: No such file or directory

[Bug fortran/107874] merge not using all its arguments

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
And this is the output I'm getting on stdout:

 tstuff
 fstuff
 T
 tstuff
 fstuff
 F
 tstuff
 fstuff
 T
 tstuff
 fstuff
 F
 tstuff
 T
 tstuff
 F
 fstuff
 T
 fstuff
 F

Can you compare your output with the above to narrow down what might be wrong?

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from James Hilliard  ---
(In reply to James Hilliard from comment #10)
> (In reply to David Faust from comment #9)
> > Created attachment 54002 [details]
> > updated patch
> > 
> > Update the 'extern' variable marking, and also mark 'extern' funcs.
> 
> That fixes the issue in kfunc_call_test.c

Actually I think there's still an issue here, did a full
clean test build and am now hitting this error:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen skeleton
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/kfunc_call_test.bpf.linked3.o
name kfunc_call_test
libbpf: loading object 'kfunc_call_test' from buffer
libbpf: elf: section(2) .symtab, size 648, link 1, flags 0, type=2
libbpf: elf: section(3) .data, size 0, link 0, flags 3, type=1
libbpf: elf: skipping section(3) .data (size 0)
libbpf: elf: section(4) .bss, size 0, link 0, flags 3, type=8
libbpf: elf: section(5) tc, size 1120, link 0, flags 6, type=1
libbpf: sec 'tc': found program 'kfunc_call_test2' at insn offset 0 (0 bytes),
code size 13 insns (104 bytes)
libbpf: sec 'tc': found program 'kfunc_call_test1' at insn offset 13 (104
bytes), code size 21 insns (168 bytes)
libbpf: sec 'tc': found program 'kfunc_call_test_ref_btf_id' at insn offset 34
(272 bytes), code size 22 insns (176 bytes)
libbpf: sec 'tc': found program 'kfunc_call_test_pass' at insn offset 56 (448
bytes), code size 52 insns (416 bytes)
libbpf: sec 'tc': found program 'kfunc_call_test_get_mem' at insn offset 108
(864 bytes), code size 32 insns (256 bytes)
libbpf: elf: section(6) syscall, size 152, link 0, flags 6, type=1
libbpf: sec 'syscall': found program 'kfunc_syscall_test' at insn offset 0 (0
bytes), code size 15 insns (120 bytes)
libbpf: sec 'syscall': found program 'kfunc_syscall_test_null' at insn offset
15 (120 bytes), code size 4 insns (32 bytes)
libbpf: elf: section(7) license, size 4, link 0, flags 3, type=1
libbpf: license of kfunc_call_test is GPL
libbpf: elf: section(8) .comment, size 43, link 0, flags 30, type=1
libbpf: elf: skipping unrecognized data section(8) .comment
libbpf: elf: section(9) .reltc, size 272, link 2, flags 40, type=9
libbpf: elf: section(10) .relsyscall, size 64, link 2, flags 40, type=9
libbpf: elf: section(11) .BTF, size 469068, link 0, flags 0, type=1
libbpf: looking for externs among 27 symbols...
libbpf: failed to find BTF for extern 'bpf_kfunc_call_test2' [8134] section: -2
Error: failed to open BPF object file: No such file or directory

[Bug fortran/107874] merge not using all its arguments

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #12 from Jerry DeLisle  ---
Created attachment 54003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54003&action=edit
-fdump-tree-original output

I get no output at runtime. The program simply hangs and does nothing.

This is on:

$ uname -a
Linux r7laptop 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26
16:55:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

[Bug fortran/107874] merge not using all its arguments

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

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

--- Comment #13 from Jerry DeLisle  ---
A debug session gives:

(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
futex_wait (private=0, expected=2, futex_word=0x405950) at
../sysdeps/nptl/futex-internal.h:146
146   int err = lll_futex_timed_wait (futex_word, expected, NULL, private);

(gdb) bt
#0  futex_wait (private=0, expected=2, futex_word=0x405950)
at ../sysdeps/nptl/futex-internal.h:146
#1  __GI___lll_lock_wait (futex=futex@entry=0x405950, private=0)
at lowlevellock.c:49
#2  0x779d1432 in lll_mutex_lock_optimized (mutex=0x405950)
at pthread_mutex_lock.c:48
#3  ___pthread_mutex_lock (mutex=0x405950) at pthread_mutex_lock.c:93
#4  0x77e73503 in __gthread_mutex_lock (__mutex=0x405950)
at ../libgcc/gthr-default.h:749
#5  get_gfc_unit (n=6, do_create=1) at ../../../trunk/libgfortran/io/unit.c:395
#6  0x77e71b85 in data_transfer_init (dtp=0x7fffd9d0, read_flag=0)
at ../../../trunk/libgfortran/io/transfer.c:3007
#7  0x004017dd in testmerge9::tstuff () at merge_1.f90:39
#8  0x0040128c in testmerge9 () at merge_1.f90:14
#9  0x0040184f in main (argc=1, argv=0x7fffe2c4) at merge_1.f90:36
#10 0x7796a510 in __libc_start_call_main (
main=main@entry=0x40181b , argc=argc@entry=1, 
argv=argv@entry=0x7fffdfa8)
at ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x7796a5c9 in __libc_start_main_impl (main=0x40181b , 
argc=1, argv=0x7fffdfa8, init=, fini=, 
rtld_fini=, stack_end=0x7fffdf98)
at ../csu/libc-start.c:381

I would speculate we are trashing some memory since there is no reason to hang
in there.

[Bug fortran/107874] merge not using all its arguments

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

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

--- Comment #14 from Jerry DeLisle  ---
Now this is interesting.

Compling with -static I get:

$ gfc -static merge_1.f90 
[jerry@r7laptop merge]$ ./a.out 
 tstuff
 fstuff
 T
 tstuff
 fstuff
 F
 tstuff
 fstuff
 T
 tstuff
 fstuff
 F
 tstuff
 T
 tstuff
 F
 fstuff
 T
 fstuff
 F


So there is something wrong with the linking as it hangs without -static

$ echo $LD_LIBRARY_PATH
/home/jerry/dev/usr/lib64/:/home/jerry/dev/usr/lib/

$ gfc -v
Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/home/jerry/dev/usr/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
--enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221201 (experimental) (GCC) 

[jerry@r7laptop bin]$ ls -l gfc
lrwxrwxrwx. 1 jerry jerry 32 Nov 20 15:50 gfc ->
/home/jerry/dev/usr/bin/gfortran

Am I doing something wrong?

Also Valgrind does show some issues, but one can not be sure.:

$ gfc -static merge_1.f90 
[jerry@r7laptop merge]$ valgrind --leak-check=full --show-leak-kinds=all
./a.out
==17321== Memcheck, a memory error detector
==17321== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==17321== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==17321== Command: ./a.out
==17321== 
==17321== Syscall param set_robust_list(head) points to uninitialised byte(s)
==17321==at 0x48848A: __tls_init_tp (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x439361: __libc_setup_tls (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x438630: (below main) (in /home/jerry/dev/test/merge/a.out)
==17321==  Address 0x40006b0 is in the brk data segment 0x400-0x4000d3f
==17321== 
==17321== Conditional jump or move depends on uninitialised value(s)
==17321==at 0x460387: malloc (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4B3B9A: _dl_get_origin (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x489416: _dl_non_dynamic_init (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x48ABE8: __libc_init_first (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out)
==17321== 
==17321== Conditional jump or move depends on uninitialised value(s)
==17321==at 0x460459: malloc (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4B3B9A: _dl_get_origin (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x489416: _dl_non_dynamic_init (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x48ABE8: __libc_init_first (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out)
==17321== 
==17321== Conditional jump or move depends on uninitialised value(s)
==17321==at 0x45EFBB: _int_malloc (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x45FC34: tcache_init.part.0 (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x460463: malloc (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4B3B9A: _dl_get_origin (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x489416: _dl_non_dynamic_init (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x48ABE8: __libc_init_first (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out)
==17321== 
==17321== Conditional jump or move depends on uninitialised value(s)
==17321==at 0x4757D4: __strcspn_sse42 (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4B8CFC: strsep (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4AEE1E: fillin_rpath.isra.0 (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4AF52C: _dl_init_paths (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x489A3B: _dl_non_dynamic_init (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x48ABE8: __libc_init_first (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out)
==17321== 
==17321== Conditional jump or move depends on uninitialised value(s)
==17321==at 0x4757B2: __strcspn_sse42 (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4B8CFC: strsep (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x4AEE1E: fillin_rpath.isra.0 (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4AF52C: _dl_init_paths (in /home/jerry/dev/test/merge/a.out)
==17321==by 0x489A3B: _dl_non_dynamic_init (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x48ABE8: __libc_init_first (in
/home/jerry/dev/test/merge/a.out)
==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out)
==17321== 
 tstuff
 fstuff
 T
 tstuff
 fstuff
 F
 tstuff
 fstuff
 T
 tstuff
 fstuff
 F
 tstuff
 T
 tstuff
 F
 fstuff
 T
 fstuff
 F
==17321== Conditional jump or move depends on uninitialised value(s)
==17321==at 0x45B3D9: __libc_cleanup_push_defer (in
/home/jerry/dev/test/merge/a.out)
==17321

[Bug c++/107539] [13 Regression] ICE, same canonical type node for different types with decltype inside an generic lambda inside a templated method of a templated class using a templated class argumen

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r13-4453-ga4e577b044d69977f93b2cb7769dc991eadf2cf0
Author: Patrick Palka 
Date:   Thu Dec 1 20:11:53 2022 -0500

c++: comptypes ICE with BOUND_TEMPLATE_TEMPLATE_PARMs [PR107539]

Here we end up giving the two BOUND_TEMPLATE_TEMPLATE_PARMs
C and C the same TYPE_CANONICAL because
the hash table that interns TYPE_CANONICAL for template type parameters
doesn't set the comparing_specializations flag which controls how
PARM_DECLs from different contexts compare equal.

Later, from spec_hasher::equal for the corresponding two specializations
A> and A>, we compare the two bound
ttps with comparing_specializations set hence they now (structurally)
compare different despite having the same TYPE_CANONICAL, and so we get
the error:

  internal compiler error: same canonical type node for different types
'C' and 'C'

This suggests that we should be setting comparing_specializations from
ctp_hasher::equal to match spec_hasher::equal.  But doing so introduces
a separate ICE in cpp2a/concepts-placeholder3.C:

  internal compiler error: canonical types differ for identical types
'auto [requires ::same_as<, decltype(f::x)>]' and
'auto [requires ::same_as<, decltype(g::x)>]'

because norm_hasher::equal doesn't set comparing_specializations either.

I'm not sure when exactly we need to set comparing_specializations given
what it controls (TYPENAME_TYPE equality/hashing and PARM_DECL equality)
but it seems to be the conservative choice to set the flag wherever we
have a global hash table that relies on type equality.  To that end this
patch sets comparing_specializations in ctp_hasher and norm_hasher, as
well as in atom_hasher and sat_hasher for good measure.  This turns out
to be a compile time win of about 2% in some concepts tests, probably
because of the improved TYPENAME_TYPE hashing enabled by the flag.

PR c++/107539

gcc/cp/ChangeLog:

* constraint.cc (norm_hasher::hash, norm_hasher::equal): Set
comparing_specializations.
(sat_hasher::hash, sat_hasher::equal): Likewise.
* cp-tree.h (atom_hasher::hash, atom_hasher::equal): Likewise.
* pt.cc (ctp_hasher::hash, ctp_hasher::equal): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/template/canon-type-19.C: New test.

[Bug c++/107539] [13 Regression] ICE, same canonical type node for different types with decltype inside an generic lambda inside a templated method of a templated class using a templated class argumen

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Should be fixed, thanks for the bug report.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #53 from LIU Hao  ---
Why not implement `call_once` with `__cxa_guard_{acquire,release,abort}`?

It's basically

  ```
  template
  void
  call_once(once_flag& __once, _Callable&& __callable, _Args&&... __args)
{
  int __r = ::__cxa_guard_acquire(&__once);
  if(__r == 0)
return;  // passive

  __try {
_INVOKE(forward<_Callable>(__callable), forward<_Args>(__args)...);
  }
  __catch(...) {
::__cxa_guard_abort(&__once);  // exceptional
__throw_exception_again;
  }
  ::__cxa_guard_release(&__once);  // returning
}
  ```

[Bug target/107934] ICE: SIGSEGV in immediate_operand (recog.cc:1618) with -O2 -mtune=knl -ffinite-math-only and __bf16 since r13-4314-ga1ecc5600464f6a6

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r13-4454-ge055e6db974d8b8950b30859a853e0aee74e20c2
Author: liuhongt 
Date:   Thu Dec 1 11:41:49 2022 +0800

Fix ICE due to incorrect insn type.

;; if reg/mem op
(define_insn_reservation  "slm_sseishft_3" 2
  (and (eq_attr "cpu" "slm")
   (and (eq_attr "type" "sseishft")
(not (match_operand 2 "immediate_operand"
  "slm-complex, slm-all-eu")

in slm.md it will check operands[2] for type sseishft, but for
extendbfsf2_1 there's no second operand which caused ICE.
The patch set type from sseishft to sseishft1 to fix the issue.

gcc/ChangeLog:

PR target/107934
* config/i386/i386.md (extendbfsf2_1): Change type from
sseishft to sseishft1.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107934.c: New test.