[Bug target/116308] New: ICE while compiling _Atomic _Float16 for riscv64

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

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

Bug ID: 116308
   Summary: ICE while compiling _Atomic _Float16 for riscv64
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: riscv64

Compiling this code

testcase.c
```
_Float16 test__Float16_post_inc()
{
_Atomic _Float16 n;
return n++;
}
```

with a riscv64 crosscompiler using -Ofast

riscv64-linux-gnu-gcc testcase.c -Ofast

results in an ICE

during RTL pass: expand
testcase.c: In function ‘test__Float16_post_inc’:
testcase.c:4:12: internal compiler error: Segmentation fault
4 | return ++n;
  |^~
0x27d09ae internal_error(char const*, ...)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/diagnostic-global-context.cc:491
0x1091bdf crash_signal
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/toplev.cc:321
0xcf668d emit_move_insn(rtx_def*, rtx_def*)
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/expr.cc:4632
0x140c4c3 riscv_lshift_subword(machine_mode, rtx_def*, rtx_def*, rtx_def**)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/config/riscv/riscv.cc:10966
0x1aac447 gen_zalrsc_atomic_cas_value_stronghi(rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/config/riscv/sync.md:743
0x1aac5ba gen_atomic_compare_and_swaphi(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/config/riscv/sync.md:673
0xf4dea2 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/recog.h:441
0xf4dea2 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/optabs.cc:8230
0xf5072b maybe_expand_insn(insn_code, unsigned int, expand_operand*)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/optabs.cc:8258
0xf5072b expand_atomic_compare_and_swap(rtx_def**, rtx_def**, rtx_def*,
rtx_def*, rtx_def*, bool, memmodel, memmodel)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/optabs.cc:7182
0xbbbaf6 expand_builtin_atomic_compare_exchange
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/builtins.cc:6708
0xbc73d9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/builtins.cc:8636
0xcf2931 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/expr.cc:12376
0xcffca2 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/expr.cc:9466
0xcffca2 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/expr.h:323
0xcffca2 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/expr.cc:6649
0xd013dc expand_assignment(tree_node*, tree_node*, bool)
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/expr.cc:6487
0xbe76aa expand_call_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/cfgexpand.cc:2893
0xbe76aa expand_gimple_stmt_1
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/cfgexpand.cc:3962
0xbe76aa expand_gimple_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/gcc/cfgexpand.cc:4104
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.


Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/riscv64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/riscv64-linux-gnu/15.0.0/lto-wrapper
Target: riscv64-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-riscv64/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release --prefix=/home/worker/cross
--target=riscv64-linux-gnu --with-as=/usr/bin/riscv64-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240808 (experimental)
7223c64745530db102a160d5a1db4c2c8d2b9fe1 (GCC)

[Bug target/111236] ICE in in extract_insn, at recog.cc:2791 on s390x with -Og -march=z13

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

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

Filip Kastl  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Filip Kastl  ---
I've just checked that this no longer occurs. Closing the PR.

[Bug fortran/116254] new test case gfortran.dg/class_transformational_2.f90 from r15-2739-g4cb07a38233aad fails

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

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

--- Comment #8 from Paul Thomas  ---
Linaro flagged up this failure, when I submitted the patch for approval.
Following some correspondence with Thiago Bauermann, this conclusion was
arrived at:

"I ran your patch through a different CI loop that we have, where instead
of using the distro's toolchain (binutils, gcc, glibc) to build and test
the patch, it builds every component from scratch and from their
respective tips of trunk.

This time it didn't detect any problem. All
gfortran.dg/class_transformational_2.f90 tests passed:

https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-arm-precommit/2/artifact/artifacts/artifacts.precommit/sumfiles/gfortran.sum.xz

I think this means that with Ubuntu 22.04 glibc we see the problem, but
when using the latest upstream glibc we don't."

What should I do? I don't see the failure at all. Unlike
class_transformational_.f90, valgrind gives this test a clean bill of health.

Regards

Paul

[Bug target/116309] New: ICE unrecognizable insn while compiling pr111821.c for s390

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

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

Bug ID: 116309
   Summary: ICE unrecognizable insn while compiling pr111821.c for
s390
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: s390x-linux-gnu

Compiling the GCC testsuite file gcc.dg/torture/pr111821.c with -O3 or -Oz
results in an ICE

s390x-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/torture/pr111821.c
-O3
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/torture/pr111821.c:
In function ‘f’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/torture/pr111821.c:9:1:
error: unrecognizable insn:
9 | }
  | ^
(insn 7 6 8 2 (parallel [
(set (strict_low_part (subreg:HI (reg:DI 61) 6))
(subreg:HI (reg:DI 64) 6))
(clobber (reg:CC 33 %cc))
])
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/torture/pr111821.c":7:22
-1
 (nil))
during RTL pass: vregs
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/torture/pr111821.c:9:1:
internal compiler error: in extract_insn, at recog.cc:2869
0x17ce5de internal_error(char const*, ...)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/diagnostic-global-context.cc:491
0x66daad fancy_abort(char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/diagnostic.cc:1772
0x64d5b2 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:108
0x64d5ce _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:116
0x64c9f0 extract_insn(rtx_insn*)
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/recog.cc:2869
0x925320 instantiate_virtual_regs_in_insn
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1612
0x925320 instantiate_virtual_regs
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1995
0x925320 execute
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:2042
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.
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/diagnostic.cc:1772
0x64d5b2 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:108
0x64d5ce _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:116
0x64c9f0 extract_insn(rtx_insn*)
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/recog.cc:2869
0x925320 instantiate_virtual_regs_in_insn
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1612
0x925320 instantiate_virtual_regs
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1995
0x925320 execute
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:2042
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.


Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/s390x-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/s390x-linux-gnu/15.0.0/lto-wrapper
Target: s390x-linux-gnu
Configured with: /home/worker/buildworker/tiber-gcc-trunk-s390x/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release --prefix=/home/worker/cross
--target=s390x-linux-gnu --with-as=/usr/bin/s390x-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240808 (experimental)
7223c64745530db102a160d5a1db4c2c8d2b9fe1 (GCC)

[Bug target/116309] ICE unrecognizable insn while compiling pr111821.c for s390

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

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

Filip Kastl  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/116310] New: default equality operator== selects not-const conversion operator

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 116310
   Summary: default equality operator== selects not-const
conversion operator
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program
```
struct A {
int i = 0;
constexpr operator int() const { return i; }
constexpr operator int&() { return ++i; }
};

struct B {
A a;
bool operator==(const B &) const = default;
};

constexpr bool f() {
B x;
return x == x;
}

static_assert( f() ); // fails in GCC
```
is accepted by Clang and MSVC, but fails static assertion in GCC. Online demo:
https://gcc.godbolt.org/z/4xjTnM54M

GCC looks wrong here, because not-const `operator int&` should not be called
from within `B::operator==(const B &) const`.

Original discussion: https://stackoverflow.com/q/78850335/7325599

[Bug c++/116311] New: GCC accepts invalid program with conversion function

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 116311
   Summary: GCC accepts invalid program with conversion function
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following program is accepted by gcc and prints 1 while clang and msvc
rejects it. https://godbolt.org/z/MG3os6h7v

```
#include 
struct A {
int i = 0;
constexpr operator int&() { return i; } 

};

struct B {
A a; 
constexpr bool operator==(const B &) const = default;
};

constexpr bool f() {
constexpr B x; 
return x == x;
} 

int main()
{
std::cout << f();
}
```

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #152 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #140)
> Created attachment 58860 [details]
> testcase for attachment  58831 [details],  58832,  58833,  58836
> 
> The attached test case, when compiled with 'sh-elf-gcc -O2 -m4-single -mlra'
> on current development branch (GCC 15) fails with the following ICE:

I have yet to reproduce the failure.

/home/kkojima/Take3/shelf-gcc/gcc/g++-cross -B/home/kkojima/Take3/shelf-gcc/gcc
-c -O2 -mlra -m4-single  genmenu.ii

genmenu.cpp:57660:2: error: expected '}' at end of input
genmenu.cpp:40566:1: note: to match this '{'

Maybe something is wrong with my sh-elf gcc build or some file truncation
problem.
FYI, it compiles successfully when adding '}' at the end of genmenu.ii.

[Bug c++/116310] default equality operator== selects not-const conversion operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug c++/116311] GCC accepts invalid program with conversion function

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup.

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

[Bug target/116312] New: Use LDP instead of LD2 on for Advanced SIMD when possible

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

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

Bug ID: 116312
   Summary: Use LDP instead of LD2 on for Advanced SIMD when
possible
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

The testcase:
#define N 32000
float a[N],b[N],c[N];

void foo(struct args_t * func_args)
{
for (int i = 0; i < N; i+=2) {
c[i] = a[i] + b[i];
}
}

Compiled, for example with -O3 -mcpu=neoverse-v2 will generate the loop:
.L2:
ld2 {v29.4s - v30.4s}, [x4], 32
mov x3, x0
add x2, x0, 16
add x1, x0, 24
add x0, x0, 32
ld2 {v30.4s - v31.4s}, [x5], 32
faddv30.4s, v30.4s, v29.4s
str s30, [x3], 8
st1 {v30.s}[1], [x3]
st1 {v30.s}[2], [x2]
st1 {v30.s}[3], [x1]
cmp x4, x6
bne .L2

LLVM generates:
.LBB0_1:
ldp q0, q1, [x9], #32
ldp q2, q3, [x11], #32
sub x12, x8, #8
add x13, x8, #8
subsx10, x10, #4
faddv1.4s, v1.4s, v3.4s
faddv0.4s, v0.4s, v2.4s
st1 { v1.s }[2], [x13]
sturs0, [x8, #-16]
str s1, [x8], #32
st1 { v0.s }[2], [x12]
b.ne.LBB0_1

LDP is known to be more efficient than LD2. For example from the Neoverse V2
SWOG the throughput/latency of thhe LD2 here is 8 and 3/2.
For the equivalent LDP it's 6 and 3/2.
It's not a huge improvement to be honest, but we could implement it as a simple
final assembly output template change for minimal invasion.
Though if we wanted to take advantage of wider post-index immediates available
to LDP we could make it more elaborate

[Bug c++/116310] default equality operator== const selects not-const conversion operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|default equality operator== |default equality operator==
   |selects not-const   |const selects not-const
   |conversion operator |conversion operator
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-09
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed. Looks like the const on the default operator== is being ignored
incorrectly.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #153 from Kazumoto Kojima  ---
Created attachment 58886
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58886&action=edit
a revised patch for c#135 and c#139

(In reply to Oleg Endo from comment #139)

If we try to keep the old behavior with -mno-lra as possible, it means that
when we define new patterns with R0-clobber, they should be guarded with
sh_lra_p() rigidly and the old patterns should be kept.
The patch adds these guards to the new patterns in c#135 and fixes the testcase
58859.

[Bug target/116312] Use LDP instead of LD2 on for Advanced SIMD when possible

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

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

--- Comment #1 from Andrew Pinski  ---
>but we could implement it as a simple final assembly output template change 
>for minimal invasion.

No you can't since ldp and ld2 mean 2 different things.

ld2 is basically a perm to unmix the two registers. that is load lanes.

Note in the GCC case there is only one fadd while in LLVM there are 2 though
indepedent.

so the question becomes is the ldp better than ld2 here? overall or just
looking at the ldp vs ld2?

[Bug target/116312] Use LDP instead of LD2 on for Advanced SIMD when possible

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> >but we could implement it as a simple final assembly output template change 
> >for minimal invasion.
> 
> No you can't since ldp and ld2 mean 2 different things.
> 
> ld2 is basically a perm to unmix the two registers. that is load lanes.
> 
> Note in the GCC case there is only one fadd while in LLVM there are 2 though
> indepedent.
> 
> so the question becomes is the ldp better than ld2 here? overall or just
> looking at the ldp vs ld2?

Yeah you're right, it's too early in the morning for me...
It could be that LLVM's vectorisation approach here is better, but that's a
separate discussion

[Bug target/116072] [15 Regression] 4.5% slowdown of 447.dealII on aarch64

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

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

Filip Kastl  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Filip Kastl  ---
Marking as WORKSFORME.

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

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

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

Bug 116072 Summary: [15 Regression] 4.5% slowdown of 447.dealII on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116072

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #7 from Arnd Bergmann  ---
I confirmed that the patch from comment #6 addresses the build warnings I see
in the kernel.

[Bug c/116313] New: -Wsequence-point false positive with auto and/or __auto_type

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 116313
   Summary: -Wsequence-point false positive with auto and/or
__auto_type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

Originally found in
.
Originally reported in
.


$ cat auto.c
#include 

int
main(void)
{
int  i = 3;
int  a[2 * i];
int  (*p)[2 * i];

i = 1;
p = &a;
auto q = p + i++;
}
$ gcc -Wsequence-point -std=c23 auto.c
auto.c: In function ‘main’:
auto.c:12:23: warning: operation on ‘i’ may be undefined [-Wsequence-point]
   12 | auto q = p + i++;
  |  ~^~


I suspect the warning is confusing auto with typeof().  If typeof()
was used, this would indeed cause double evaluation, once before the =
and once after the =, causing UB.

Maybe it's due to how auto is implemented?  I suspect it's doing
internally:

typeof(p + i++) q = p + i++;

and that would be problematic.  I can reproduce it with both gcc-13 and
gcc-14.

[Bug c++/99599] [12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern

[corentinjabot at gmail dot com via Gcc-bugs]

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

corentinjabot at gmail dot com changed:

   What|Removed |Added

 CC||corentinjabot at gmail dot com

--- Comment #28 from corentinjabot at gmail dot com ---
(In reply to Jason Merrill from comment #2)
> This is as specified by http://wg21.link/cwg2369
> 
> I think it would be reasonable to allow a compiler to accept the testcase
> under a generalization of 13.9.1/9: "If the function selected by overload
> resolution (12.4) can be determined without instantiating a class template
> definition, it is unspecified whether that instantiation actually takes
> place."
> 
> But that does not require a compiler to accept it.
> 
> It might make sense to check non-dependent conversions that don't require
> template instantiation, then constraints, then non-dependent conversions
> that do require template instantiation.  But that's a matter for the
> committee; G++ is conforming to the current working paper.

Was a CWG issue ever created for that?

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #4 from Georg-Johann Lay  ---
Would someone please explain what has to be done?

It's likely more than just

#define TARGET_LRA_P hook_bool_void_true

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #5 from Sam James  ---
I _thought_ https://gcc.gnu.org/wiki/reload had more instructions but it only
talks about the target hook to start with.

Segher?

[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486

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

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

--- Comment #8 from Sam James  ---
Should I upload the real testcase I hit it on in this bug (from
'fortran-stdlib' https://bugs.gentoo.org/937358), or file another bug instead?
I have no idea if it's the same issue, other than it ICEing in the same place.

[Bug target/115464] [14 Backport] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)

[ncopa at alpinelinux dot org via Gcc-bugs]

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

Natanael Copa  changed:

   What|Removed |Added

 CC||ncopa at alpinelinux dot org

--- Comment #14 from Natanael Copa  ---
I have backported the following commits to Alpine Linux:

- 0970ff46ba63 aarch64: Fix invalid nested subregs [PR115464]
- 1474a8eead4a aarch64: Use force_subreg in more places
- 6bd4fbae45d1 aarch64: Add some uses of force_lowpart_subreg
- 5f40d1c0cc6c Add force_lowpart_subreg

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

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

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

--- Comment #1 from Florian Weimer  ---
The warning for typeof in this context seems bogus as well because it follows
the evaluation rules for sizeof:

“
The operand of ‘typeof’ is evaluated for its side effects if and only
if it is an expression of variably modified type or the name of such a
type.
”

[Bug target/113035] RISC-V: regression testsuite errors -mtune=sifive-7-series

[Dusan.Stojkovic--- via Gcc-bugs]

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

Dusan Stojkovic  changed:

   What|Removed |Added

 CC||dusan.stojko...@rt-rk.com

--- Comment #2 from Dusan Stojkovic  ---
Hello,

During our investigation into this bug, we discovered that it is triggered by
the -O2 optimization flag, specifically by the -fschedule-insns and
`-fschedule-insns2` options in most test cases we analyzed. These scheduler
optimizations rearrange the instructions in a way that causes the tests to
fail. For the rocket mtune option, however, this rearrangement does not occur
in a manner that causes test failures.

To be more specific, we have confirmed this issue with some of the
`vlmax_bb_prop-*.c` test cases. For instance, in the case of
`vlmax_bb_prop-24.c`, the assembly output differs between rocket and SiFive as
follows:

- Rocket assembly output - (https://godbolt.org/z/z4c1enbx5)
- SiFive assembly output - (https://godbolt.org/z/s8ch6Tn7W)

Let's consider the first failing pattern from the test:
{vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]\s+\.L[0-9]\:} 1

For the mtune=rocket, with `-O2` optimization, the output is:
...
vsetvli a5,zero,e8,mf8,ta,ma
.L5:
...

For the mtune=sifive-7-series, with `-O2` optimization, the assembly output is:
...
vsetvli a5,zero,e8,mf8,ta,ma
add a4,a0,a2
.L5:
...

The extra `add` instruction in the SiFive output prevents the pattern from
matching, causing the test to fail.

Possible mitigations for this issue, similar to those mentioned in the bug
report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249), include:
- Disabling the scheduler with the following options:
  /* { dg-additional-options "-fno-schedule-insns -fno-schedule-insns2" } */
- Removing the `-O2` optimization flag by adding the option -no-opts "-O2" to
the failing tests.

Configuration:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcmodel=medlow

[Bug middle-end/116299] GCC optimizes away code when long double is represented by the IBM double-double method.

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

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

--- Comment #6 from Sam James  ---
Please provide preprocessed sources for the bad TU and then try to extract the
issue into a standalone file we can compile & execute.

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #2 from Alejandro Colomar  ---
p has a variably modified type, isn't it?.  Its type is 'int (*)[2 * i]'.

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

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

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

--- Comment #3 from Florian Weimer  ---
Right, missed that, sorry.

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #6 from Georg-Johann Lay  ---
...to be more specific:

TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P explains the function of the hook from the
perspective of someone who is implementing a register allocator, but there is
no explanation whether it is a good idea (or even required) to implement it for
some specific target.  What form can "subst" take?  When it's purpose it to
avoid spills, then why not always true? (Nobody wants stills when they can be
avoided).

TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: How would I describe addressing
capabilities for different named address-spaces?  What kind of target code can
I use to investigate the effect of the hook? Or can it inferred simply from the
device's register layout?

TARGET_SPILL_CLASS:  Can't we just return GENERAL_REGS as a spill class?

TARGET_COMPUTE_PRESSURE_CLASSES:  Requests that we should compute pressure
classes.  Now I know everything about it ...kidding.  Again it's from the
perspective of someone who is writing a register allocator, but of no use for
someone who has to provide an implementation.

TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Similar issue.

TARGET_REGISTER_PRIORITY: When some registers are preferred over others and
hence we give them a higher priority, might that lead to more MOVs or spills?

Finally: Who will fix fallout like ICEs (spill fails), performance issues, etc?
Just reporting them here as PR will likely not help much, because AVR is
ternary and hence any PR has priority P4 or less.  For example, Newlib dropped
AVR support because nobody did fix all the spill fail ICEs when building Newlib
for AVR.  lra just perform 2 rounds, and when it doesn't find an allocation it
just bails out with spill fail ICE.

[Bug tree-optimization/116314] New: ICE after fixing PR116142 and implementing vec_widen_smult_{odd,even}_M for LoongArch

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

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

Bug ID: 116314
   Summary: ICE after fixing PR116142 and implementing
vec_widen_smult_{odd,even}_M for LoongArch
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

After PR116142 is fixed I attempted again to add vec_widen_smult_{odd,even}_M
for LoongArch:

diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index 00ff2823a4e..7b2d006e261 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/simd.md
@@ -475,6 +475,26 @@ (define_insn "neg2"
   [(set_attr "type" "simd_logic")
(set_attr "mode" "")])

+(define_expand "vec_widen_smult_even_v8hi"
+  [(match_operand:V4SI 0 "register_operand" "=f")
+   (match_operand:V8HI 1 "register_operand" " f")
+   (match_operand:V8HI 2 "register_operand" " f")]
+  "ISA_HAS_LSX"
+{
+  emit_insn (gen_lsx_vmulwev_w_h (operands[0], operands[1], operands[2]));
+  DONE;
+})
+
+(define_expand "vec_widen_smult_odd_v8hi"
+  [(match_operand:V4SI 0 "register_operand" "=f")
+   (match_operand:V8HI 1 "register_operand" " f")
+   (match_operand:V8HI 2 "register_operand" " f")]
+  "ISA_HAS_LSX"
+{
+  emit_insn (gen_lsx_vmulwod_w_h (operands[0], operands[1], operands[2]));
+  DONE;
+})
+
 ; The LoongArch SX Instructions.
 (include "lsx.md")

It works for the test case in PR116142.  But for a test case where the input
vector cannot be hold in one register:

short x[16], y[16];

int test() {
int ret = 0;
for (int i = 0; i < 16; i++)
ret += x[i] * y[i];
return ret;
}

$ ./gcc/cc1 t.c -nostdinc -O2 -fdump-tree-vect-details -o-
t.c: In function ‘test’:
t.c:3:5: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.cc:13396
3 | int test() {
  | ^~~~
0x296cde4 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:491
0x29498c0 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1772
0x1a1911f vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../../gcc/gcc/tree-vect-stmts.cc:13396
0x1a8f9e1 vect_schedule_slp_node
../../gcc/gcc/tree-vect-slp.cc:9970
0x1a909c9 vect_schedule_scc
../../gcc/gcc/tree-vect-slp.cc:10208
0x1a90860 vect_schedule_scc
../../gcc/gcc/tree-vect-slp.cc:10189
0x1a912d3 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
../../gcc/gcc/tree-vect-slp.cc:10353
0x1a5166e vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/gcc/tree-vect-loop.cc:12404
0x1ab04f3 vect_transform_loops
../../gcc/gcc/tree-vectorizer.cc:1007
0x1ab0c95 try_vectorize_loop_1
../../gcc/gcc/tree-vectorizer.cc:1153
0x1ab0dee try_vectorize_loop
../../gcc/gcc/tree-vectorizer.cc:1183
0x1ab10d8 execute
../../gcc/gcc/tree-vectorizer.cc:1299
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.

Similar to PR116142, the problem is a missing vect_reduction_def.  In the call
trace:

(gdb) bt
#0  supportable_widening_operation (vinfo=0x33a5b60, code=..., 
stmt_info=0x3487ee0, vectype_out=0x7595a1f8, 
vectype_in=0x7595a000, code1=0x7fffcb70, code2=0x7fffcb74, 
multi_step_cvt=0x7fffcb80, interm_types=0x7fffcc28)
at ../../gcc/gcc/tree-vect-stmts.cc:14197
#1  0x019f95ef in vectorizable_conversion (vinfo=0x33a5b60, 
stmt_info=0x3487ee0, gsi=0x7fffcf60, vec_stmt=0x7fffce50, 
slp_node=0x3440c30, cost_vec=0x0) at ../../gcc/gcc/tree-vect-stmts.cc:5438
#2  0x01a190fa in vect_transform_stmt (vinfo=0x33a5b60, 
stmt_info=0x3487ee0, gsi=0x7fffcf60, slp_node=0x3440c30, 
slp_node_instance=0x3300660) at ../../gcc/gcc/tree-vect-stmts.cc:13394
... ...
(gdb) call debug_gimple_stmt(use_stmt_info->stmt)
ret_9 = _5 + ret_13;
(gdb) p STMT_VINFO_DEF_TYPE (use_stmt_info)
$2 = vect_internal_def

But in a previous supportable_widening_operation call, the same stmt is
vect_reduction_def:

(gdb) bt
#0  supportable_widening_operation (vinfo=0x33a5b60, code=..., 
stmt_info=0x3487620, vectype_out=0x7595a1f8, 
vectype_in=0x7595a000, code1=0x7fffd000, code2=0x7fffd000, 
multi_step_cvt=0x7fffd004, interm_types=0x7fffd010)
at ../../gcc/gcc/tree-vect-stmts.cc:14197
#1  0x0284387e in vect_recog_widen_op_pattern (vinfo=0x33a5b60, 
last_stmt_info=0x3487620, type_out=0x7fffd170, orig_code=MULT_EXPR, 
wide_code=..., shift_p=false, 
name=0x2d4dfb4 "vect_recog_widen_mult_pattern")
at ../../gcc/gcc/tree-vect-patterns.cc:1658
#2  0x02843a5e in

[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work

[j.reuter--- via Gcc-bugs]

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

--- Comment #12 from Jan André Reuter  ---
> Hi,
> Yes, those two errors are expected.
> I posted RFC discussion about AArch64/nvptx offloading issues here:
> https://gcc.gnu.org/pipermail/gcc/2024-July/244466.html
> 
> For the unrecognized command line -m64 option, I have a WIP patch posted 
> upstream:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659866.html
> 
> Thanks,
> Prathamesh

Thanks a lot for the update and your work towards resolving these issues. It's
really appreciated.

I was not aware of the ongoing discussion and the WIP patch. I'll keep an eye
on those two and continue to test new patches when they're pushed to master.
There's not much more I can do unfortunately, as I'm not familiar with GCC
internals at all.

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #7 from Georg-Johann Lay  ---
...more questions:

What's the connexion between TARGET_REGISTER_PRIORITY and
ADJUST_REG_ALLOC_ORDER  / reg_alloc_order[].

What about reload_completed?  Does semantics stay the same? What about
reg_renumber[].  And reload_in_progress becomes lra_in_progress or what?

[Bug rtl-optimization/111673] assign_hard_reg() routine should scale save/restore costs of callee save registers with basic block frequency

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

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

Surya Kumari Jangala  changed:

   What|Removed |Added

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

--- Comment #2 from Surya Kumari Jangala  ---
Fixed in r15-1619-g3b9b8d6cfdf593

[Bug target/116287] __builtin_ia32_bzhi_si() ignores side effects of its arguments

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:6e7088dbe3bf87108a89558ffb7df36df3469206

commit r15-2847-g6e7088dbe3bf87108a89558ffb7df36df3469206
Author: Jakub Jelinek 
Date:   Fri Aug 9 14:32:51 2024 +0200

i386: Fix up __builtin_ia32_b{extr{,i}_u{32,64},zhi_{s,d}i} folding
[PR116287]

The GENERIC folding of these builtins have cases where it folds to a
constant regardless of the value of the first operand.  If so, we need
to use omit_one_operand to avoid throwing away side-effects in the first
operand if any.  The cases which verify the first argument is INTEGER_CST
don't need that, INTEGER_CST doesn't have side-effects.

2024-08-09  Jakub Jelinek  

PR target/116287
* config/i386/i386.cc (ix86_fold_builtin) :
When folding into zero without checking whether first argument is
constant, use omit_one_operand.
(ix86_fold_builtin) : Likewise.

* gcc.target/i386/bmi-pr116287.c: New test.
* gcc.target/i386/bmi2-pr116287.c: New test.
* gcc.target/i386/tbm-pr116287.c: New test.

[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

[Bug target/96017] Powerpc suboptimal register spill in likely path

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

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

Surya Kumari Jangala  changed:

   What|Removed |Added

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

--- Comment #15 from Surya Kumari Jangala  ---
With r15-1619-g3b9b8d6cfdf593 , this testcase gets shrink wrapped. Hence
closing the bug.

[Bug tree-optimization/116307] off by one when loop unrolling and bogus -Wstringop-overflow

[kasper93 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Kacper Michajłow  ---
(In reply to Andrew Pinski from comment #1)
> Note I don't think the warning is not incorrect. Nor I don't think unrolling
> by 3 is wrong either. 

Could you explain why unrolling by 3 is not wrong in this case? Technically it
is not wrong, but why unrolling by 2 is not enough?

> Note num can change after the call to get_val() too. The loop bound is
> unknown due to the function call really and num being a global variable.

This doesn't change anything, num is unknown before, during and after loop
execution. The unroll count is based on the `a` array size, which is known at
compile time.

> Anyways I think this is really a dup of bug 104789 .

Looks like the similar root cause indeed. Though I would argue in this (116307)
case we know the exact unroll count, so it could be avoided by not doing one
more iteration that triggers the warning and produces the code, that if there
is no UB invoked would be dead.

[Bug c++/113348] ice when calling xobj member function without an object in an xobj member function

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Patrick Palka  ---
Fixed for GCC 14.2/15 by the PR115783 fix

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

[Bug c++/115783] GCC accepts invalid program involving calling explicit object member function from static member function

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||waffl3x at protonmail dot com

--- Comment #6 from Patrick Palka  ---
*** Bug 113348 has been marked as a duplicate of this bug. ***

[Bug target/116287] __builtin_ia32_bzhi_si() ignores side effects of its arguments

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-10575-gb0dd13efca673355dd2a0c5646452c2f23f86029
Author: Jakub Jelinek 
Date:   Fri Aug 9 14:32:51 2024 +0200

i386: Fix up __builtin_ia32_b{extr{,i}_u{32,64},zhi_{s,d}i} folding
[PR116287]

The GENERIC folding of these builtins have cases where it folds to a
constant regardless of the value of the first operand.  If so, we need
to use omit_one_operand to avoid throwing away side-effects in the first
operand if any.  The cases which verify the first argument is INTEGER_CST
don't need that, INTEGER_CST doesn't have side-effects.

2024-08-09  Jakub Jelinek  

PR target/116287
* config/i386/i386.cc (ix86_fold_builtin) :
When folding into zero without checking whether first argument is
constant, use omit_one_operand.
(ix86_fold_builtin) : Likewise.

* gcc.target/i386/bmi-pr116287.c: New test.
* gcc.target/i386/bmi2-pr116287.c: New test.
* gcc.target/i386/tbm-pr116287.c: New test.

(cherry picked from commit 6e7088dbe3bf87108a89558ffb7df36df3469206)

[Bug target/116287] __builtin_ia32_bzhi_si() ignores side effects of its arguments

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to fail|14.2.1, 15.0|14.2.0
  Known to work||14.2.1, 15.0

--- Comment #4 from Jakub Jelinek  ---
Fixed for 14.3+/15.1+ so far.

[Bug rtl-optimization/110254] improve_allocation() routine does not update allocated_hardreg_p[] array

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

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

Surya Kumari Jangala  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Surya Kumari Jangala  ---
Fixed in r14-3251-g02ecc9a26324d1

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:12ba140ee93adc56a3426f0c6c05f4d6c6a3d08e

commit r13-8967-g12ba140ee93adc56a3426f0c6c05f4d6c6a3d08e
Author: Patrick Palka 
Date:   Fri Aug 9 09:03:14 2024 -0400

c++: local class memfn synth from uneval context [PR113063]

This is essentially a narrow backport of r14-6724-gfced59166f95e9 that
instead uses cp_evaluated instead of maybe_push_to_top_level to clear
cp_unevaluated_operand within synthesize_method, which turns out is
sufficient to also fix the 13.3 regression PR116289 (whose immediate
trigger is a  change backport r13-7739-gd919309679334a).

PR c++/113063
PR c++/116289

gcc/cp/ChangeLog:

* method.cc (synthesize_method): Use cp_evaluated.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth16.C: New test.
* g++.dg/cpp2a/spaceship-synth16a.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

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

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

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

https://gcc.gnu.org/g:12ba140ee93adc56a3426f0c6c05f4d6c6a3d08e

commit r13-8967-g12ba140ee93adc56a3426f0c6c05f4d6c6a3d08e
Author: Patrick Palka 
Date:   Fri Aug 9 09:03:14 2024 -0400

c++: local class memfn synth from uneval context [PR113063]

This is essentially a narrow backport of r14-6724-gfced59166f95e9 that
instead uses cp_evaluated instead of maybe_push_to_top_level to clear
cp_unevaluated_operand within synthesize_method, which turns out is
sufficient to also fix the 13.3 regression PR116289 (whose immediate
trigger is a  change backport r13-7739-gd919309679334a).

PR c++/113063
PR c++/116289

gcc/cp/ChangeLog:

* method.cc (synthesize_method): Use cp_evaluated.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth16.C: New test.
* g++.dg/cpp2a/spaceship-synth16a.C: New test.

Reviewed-by: Jason Merrill 

[Bug c/116313] -Wsequence-point false positive with auto and/or __auto_type

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

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

--- Comment #4 from Andrew Pinski  ---
Most likely what happens is that the sequence point warning looks through a
SAVE_EXPR which contains `i` but does not realize that is stabilized long time
before that expression.

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-2848-g4aa89badc8c16637e0d9a39a08da7d18e209631b
Author: Patrick Palka 
Date:   Fri Aug 9 09:16:45 2024 -0400

c++: add fixed testcase [PR116289]

Fully fixed since r14-6724-gfced59166f95e9.

PR c++/116289
PR c++/113063

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth16a.C: New test.

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

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

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

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

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

commit r15-2848-g4aa89badc8c16637e0d9a39a08da7d18e209631b
Author: Patrick Palka 
Date:   Fri Aug 9 09:16:45 2024 -0400

c++: add fixed testcase [PR116289]

Fully fixed since r14-6724-gfced59166f95e9.

PR c++/116289
PR c++/113063

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-synth16a.C: New test.

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #7 from Patrick Palka  ---
Fixed.

[Bug tree-optimization/116307] off by one when loop unrolling and bogus -Wstringop-overflow

[kasper93 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Kacper Michajłow  ---
(In reply to Kacper Michajłow from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Note I don't think the warning is not incorrect. Nor I don't think unrolling
> > by 3 is wrong either. 
> 
> Could you explain why unrolling by 3 is not wrong in this case? Technically
> it is not wrong, but why unrolling by 2 is not enough?

Just to expand. Strictly speaking UB of writing past the end of `a` is invoked
after get_val() function call, so unrolling by 3 makes this call happen. I
guess it is not always obvious how to prune the "last" iteration. But gcc seems
to know it is unnecessary, so maybe the store could be removed after the call.
But I'm guessing, without looking into the actual code.

The following example is unrolled by 2, because the store is before the call
and the one-past iteration is completely removed, compared to previous example.
---

struct A {
char a[2];
char b[2];
};

int num;
int get_val(void);

void foo(struct A *a)
{
for (int p = 0; p < num; p++) {
a->a[p] = 0;
a->a[p] = get_val();
}
}

---

foo(A*):
mov eax, DWORD PTR num[rip]
testeax, eax
jle .L4
pushrbx
mov rbx, rdi
mov BYTE PTR [rdi], 0
callget_val()
mov BYTE PTR [rbx], al
cmp DWORD PTR num[rip], 1
jle .L1
mov BYTE PTR [rbx+1], 0
callget_val()
mov BYTE PTR [rbx+1], al
.L1:
pop rbx
ret
.L4:
ret
num:
.zero   4

[Bug target/115464] [14 Backport] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Natanael Copa from comment #14)
> I have backported the following commits to Alpine Linux:
> 
> - 0970ff46ba63 aarch64: Fix invalid nested subregs [PR115464]
> - 1474a8eead4a aarch64: Use force_subreg in more places
> - 6bd4fbae45d1 aarch64: Add some uses of force_lowpart_subreg
> - 5f40d1c0cc6c Add force_lowpart_subreg

There are few more that should be backported:
r15-1397-gd4047da6a07017
r15-1606-gb694bf417cdd7d (fixes r15-1397)

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|14.0|13.4

--- Comment #9 from Patrick Palka  ---
Fixed for 13.4 now as well.
> Thanks for fixing it. Should it be back-ported to earlier GCC versions? From 
> my point of view, as far back as GCC 11 would be nice.
We usually only backport regression fixes (or occasionally if the fix is
clearly confined to experimental language support, currently C++20 or later,
which isn't the case for this fix).

[Bug c++/115090] ICE in gimplify_expr, at gimplify.cc:18907 (deduced this)

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 14.2/15 by the PR115783 fix

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

[Bug c++/115783] GCC accepts invalid program involving calling explicit object member function from static member function

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jose at serrall dot es

--- Comment #7 from Patrick Palka  ---
*** Bug 115090 has been marked as a duplicate of this bug. ***

[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #17 from Sam James  ---
I've started hitting this recently on trunk like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005#c8.

In my case, the tests are running on a tmpfs (with zram) but nothing else
special.

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #32 from Sergey Fedorov  ---
(In reply to Iain Sandoe from comment #30)
> blocks have support from 10.6 [Apple gcc-4.2] (although there is/was 'after
> market' support for 10.5).

So blocks presumably should work in Rosetta then? Or the support is still
Intel-only?

[Bug fortran/88624] [Coarray] Rejects allocatable coarray passed as a dummy argument

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #9 from kargls at comcast dot net ---
On 8/9/24 03:30, sjames at gcc dot gnu.org wrote:
> Should I upload the real testcase I hit it on in this bug (from
> 'fortran-stdlib' https://bugs.gentoo.org/937358), or file another bug instead?
> I have no idea if it's the same issue, other than it ICEing in the same place.
It appears that Harald has produced a simplified testcase, so
an upload is unnecessary.

[Bug other/116260] testsuite-management/validate_failures.py: split multilib ABIs in results

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

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

--- Comment #2 from Sam James  ---
(In reply to Thiago Jung Bauermann from comment #1)
> Hello Sam,
> 
> I mostly work with the GDB testsuite, so I'm not very familiar with
> GCC-specific details of DejaGNU and the sum files, so advance warning:
> naive questions ahead.

No problem -- I'm really not an expert on DejaGNU yet :)

> 
> I added Christophe Lyon to the Cc list. He's much more familiar with the
> GCC testsuite and how we use it.
> 
> (In reply to Sam James from comment #0)
> > We've started using validate_failures.py in our packaging (and I'm using it
> > in my own workflow too) and it's great, thanks for it.
> 
> Nice!
> 
> > I tried wiring up multilib tests next in our packaging and noticed that the
> > manifest ended up mixing results between ABIs, like:
> 
> I'm not sure I understand the scenario. Are you doing two testsuite runs,
> one for each ABI, and then using the one's manifest to compare with the
> other?
> 

So, the scenario right now is, say, on x86_64-pc-linux-gnu:
$ ./configure --enable-multilib --with-multilib-list=m32,m64
$ make
$ make check RUNTESTFLAGS="--target_board=unix\{,-m32\}"

dejagnu will then run the whole testsuite parametrised into "" and "-m32".

This is AFAIK the primary way to test GCC w/ multilib, but people also use
this method to do stuff like an extra testrun with -O3 or whatever.

I think what makes sense there is to accept a parameter indicating which
target (in the dejagnu sense, see below)/variation we're wanting to produce
or compare a manifest for.

That way, we can run validate_failures.py repeatedly per-variant to both
generate and then compare the manifests? I think it makes more sense that
way around than it trying to do it for us (and spitting out a suffix to the
file
we chose), but not sure.

> > dejagnu emits lines indicating which ABI tests were run for,
> 
> Do you mean these lines?
> 
> ```
> Native configuration is armv8l-unknown-linux-gnueabihf
> 
>   === gcc tests ===
> 
> Schedule of variations:
> tcwg-local
> 
> Running target tcwg-local
> ```

The lines I'm thinking of are these:
```
=== libgomp tests ===

Schedule of variations:
unix
unix/-m32
```

It'll execute these in-order, looking like...

```
=== libgomp tests ===

Schedule of variations:
unix
unix/-m32

Running target unix
[...]
Executing on host: ...
[...]

=== libgomp Summary for unix ===

# of expected passes15407
# of unexpected failures1281
# of unexpected successes   190
# of expected failures  75
# of unresolved testcases   50
# of unsupported tests  619
Running target unix/-m32
[...]
Executing on host: ...
[...]
```

[Bug c++/115806] [12/13/14/15 Regression] No error for member enum redefinition in class template (even after instantiation)

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Simon Martin :

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

commit r15-2855-g786ebbd6058540b2110da16a693f0c582c11413c
Author: Simon Martin 
Date:   Thu Aug 8 14:59:49 2024 +0200

c++: Don't accept multiple enum definitions within template class
[PR115806]

We have been accepting the following invalid code since revision
557831a91df

=== cut here ===
template  struct S {
  enum E { a };
  enum E { b };
};
S s;
=== cut here ===

The problem is that start_enum will set OPAQUE_ENUM_P to true even if it
retrieves an existing definition for the enum, which causes the
redefinition
check in cp_parser_enum_specifier to be bypassed.

This patch only sets OPAQUE_ENUM_P and ENUM_FIXED_UNDERLYING_TYPE_P when
actually pushing a new tag for the enum.

PR c++/115806

gcc/cp/ChangeLog:

* decl.cc (start_enum): Only set OPAQUE_ENUM_P and
ENUM_FIXED_UNDERLYING_TYPE_P when pushing a new tag.

gcc/testsuite/ChangeLog:

* g++.dg/parse/enum15.C: New test.

[Bug c++/115806] [12/13/14/15 Regression] No error for member enum redefinition in class template (even after instantiation)

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

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

Simon Martin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|12.5|15.0

--- Comment #6 from Simon Martin  ---
Fixed in trunk.

[Bug tree-optimization/114952] False positive -Wmaybe-uninitialized starting at -O3 in libbpf

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

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

--- Comment #5 from Sam James  ---
I sent
https://lore.kernel.org/bpf/3ebbe7a4e93a5ddc3a26e2e11d329801d7c8de6b.1723217044.git@gentoo.org/T/#u.

[Bug tree-optimization/106931] [12 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize with loop unrolling since r12-3300-gece28da924ddda8b

[kasper93 at gmail dot com via Gcc-bugs]

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

Kacper Michajłow  changed:

   What|Removed |Added

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

--- Comment #6 from Kacper Michajłow  ---
> False positive is fixed w/ gcc-13 and the trunk.

Can confirm that.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[kasper93 at gmail dot com via Gcc-bugs]

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

Bug 106931 Summary: [12 Regression] -Wstringop-overflow false positive  -O3 
-fno-tree-vectorize with loop unrolling since r12-3300-gece28da924ddda8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931

   What|Removed |Added

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

[Bug middle-end/116299] GCC optimizes away code when long double is represented by the IBM double-double method.

[rmaguire314 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Ryan  ---
Created attachment 58887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58887&action=edit
Error in splitting trick when optimizing.

[Bug tree-optimization/116315] New: [14/15 regression] False-positive -Wmaybe-uninitialized at -O3

[drfiemost at yahoo dot com via Gcc-bugs]

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

Bug ID: 116315
   Summary: [14/15 regression] False-positive
-Wmaybe-uninitialized at -O3
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drfiemost at yahoo dot com
  Target Milestone: ---

Created attachment 5
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5&action=edit
Preprocessed source

Compiling the attached code at -O3 produces the following warning:

../../../vice-git/src/resid/filter8580new.cc: In constructor
‘reSID::Filter::Filter()’:
../../../vice-git/src/resid/filter8580new.cc:326:54: warning: ‘scaled_voltage’
may be used uninitialized [-Wmaybe-uninitialized]
../../../vice-git/src/resid/filter8580new.cc:301:20: note: ‘scaled_voltage’
declared here


Command to reproduce:

g++ -O3 -Wmaybe-uninitialized filter8580new.i

It has been reported in 14.1 and I get the same with 14.2 and 15.0-20240804
The warning does not show up at -O2, I haven't been able to isolate a single
optimization flag that triggers the issue though.

[Bug middle-end/116299] GCC optimizes away code when long double is represented by the IBM double-double method.

[rmaguire314 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Ryan  ---
The assembly generated on godbolt for ppc64el is indeed different with the
"volatile" included. It may be the default that -O3 is supposed to aggressively
optimize this away, but the spltting trick works for architectures.

-Ryan

[Bug tree-optimization/116315] [14/15 regression] False-positive -Wmaybe-uninitialized at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I think this is not exactly a false positive.

If fi.opamp_voltage_size is zero or negative, then undefine behavior happens.
There is no way for GCC to know it was neither.

Adding an assert that `fi.opamp_voltage_size > 0` is true right after the
definition of scaled_voltage before the initialization loop fixes the issue.
Note you might want to also assert it is less than or equal to 50 too.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 116315 Summary: [14/15 regression] False-positive -Wmaybe-uninitialized at 
-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116315

   What|Removed |Added

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

[Bug target/93192] [m68k] incorrect conversion of inf and nan in __truncxfdf2

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Mikael Pettersson  ---
Probably fixed for gcc-14.1.0 by e0c1476d5d7c450b1b16a40364cea4e91237ea93. The
original proposed patch no longer applies.

[Bug middle-end/116299] GCC optimizes away code when long double is represented by the IBM double-double method.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
It is not optimized away.
There is contraction happening and producing an 2 FMAs (or in this case FMS:
fused multiply subtract).

Use -ffp-contract=standard or =off if you don't want that.


  x_double_14 = (const double) x_13(D);
  _1 = .FMS (x_double_14, 3.4359738369e+10, x_double_14);
  xhi_double_16 = .FMS (x_double_14, 3.4359738369e+10, _1);

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #8 from Georg-Johann Lay  ---
...more questions:

TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Same issue: This hook can change a
reload class.  The purpose is clear for regalloc guys, but when and d why and
how would I do it for a specific backend?  The hook has two "reg_class_t"
parameters as inputs, and no parameter does even have a name. "default hook
always returns given class" ... Which one? There are two indestinguishible
ones.

[Bug tree-optimization/116315] [14/15 regression] False-positive -Wmaybe-uninitialized at -O3

[drfiemost at yahoo dot com via Gcc-bugs]

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

--- Comment #2 from Leandro Nini  ---
Ah I see, thanks!
I suppose the compiler is unable to figure out that we're using fixed values
for fi.opamp_voltage_size. Just surprised it pops up only at -O3.
Sorry for the noise.

[Bug ipa/116296] [13/14/15 Regression] internal compiler error: in merge, at ipa-modref-tree.cc:176 at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||13.1.0, 14.1.0
Summary|[15 Regression] internal|[13/14/15 Regression]
   |compiler error: in merge,   |internal compiler error: in
   |at ipa-modref-tree.cc:176   |merge, at
   |at -O3  |ipa-modref-tree.cc:176 at
   ||-O3
 CC||hubicka at gcc dot gnu.org
   Last reconfirmed||2024-08-09
 Ever confirmed|0   |1
  Known to work|14.1.0  |
   Target Milestone|15.0|13.4
   Keywords||ice-checking,
   ||needs-bisection

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Cleaned up testcase:
```
short g(unsigned long h, int i[11][11], short c) {
  for (unsigned long j = 0; j < h; j -= 0x105full)
c = c > i[j][j];
  return c;
}

```

The assert:
  gcc_checking_assert (!contains (a) && !a.contains (*this));

So ICE checking and confirmed, it ICEd in GCC 13 and 14 with checking enabled.

Maybe even GCC 12 but I don't have any compiler that is compiled with checking
enabled from that branch.

The assert was added in r12-5233-ga246d7230b8f8b (which most likely introduced
the ICE too).

I can't figure out why the number needs to be some large number here either. 
This is the smalled number I could get to the ICE as far as I can tell.

[Bug target/116266] rs6000: P10 vector insn ICE with -mno-vsx

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

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

--- Comment #3 from Segher Boessenkool  ---
No, we do not want that.

There is a huge difference between MSR[VEC] and MSR[VSX].  People can just
write
out what they actually mean.  TARGET_ALTIVEC and TARGET_VSX.

The insns here are mostly Vector insns, not Vector Scalar.

It helps to be more explicit about this.  But even if not, we need to be
explicit
about what it is we actually do.

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Georg-Johann Lay from comment #4)
> Would someone please explain what has to be done?
> 
> It's likely more than just
> 
> #define TARGET_LRA_P hook_bool_void_true

That is what you start with, though.  Or more likely, you have a -mlra flag to
enable/disable it during development.  You can do that *right now*, and that
enables other people to help you out with this, etc. :-)

Possibly some things will not work.  Either you need to do a bit of target
work, or maybe some of the general LRA code is not up to snuff yet.  No one
will know until someone tries out!

[Bug target/116170] [15 regression] ICE unrecognizable insn since r15-2084-g33dca0a4c1c421

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

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

--- Comment #4 from Segher Boessenkool  ---
Is that strong enough?  A const_vector (or a const_anything) as lhs of a set
does not make sense at all.  How did we even try this, is some more generic
thing broken?

[Bug tree-optimization/103660] Sub-optimal code with relational operators

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

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

--- Comment #5 from Andrew Pinski  ---
Two more cases, this time with XOR (^):
```
int min7(int a, int b) {
const int c = a < b;
return (c * a) ^ ((1 - c) * b);
}

int min8(int a, int b) {
const bool c = a < b;
return (c * a) ^ (!c * b);
}
```

Because `0 ^ a` is `a`. Should be easy to change the pattern to accept all 3
(XOR, IOR and PLUS) instead of just IOR.

[Bug tree-optimization/116316] New: incorrect code with -O2

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

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

Bug ID: 116316
   Summary: incorrect code with -O2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

the following testing case failed on both x86 and aarch64 with -O2, but passed
with -O1:

#include 
struct annotated {
  int b;
  int c[];
} *array_annotated;

int main(int argc, char *argv[])
{
  size_t __size = sizeof(struct annotated) + sizeof(*array_annotated->c) * 10;
  array_annotated = (struct annotated *) __builtin_malloc(__size);
  __builtin_memset(array_annotated, 0, __size);
  if (&(array_annotated->b))
*(size_t *)(&(array_annotated->b)) = 10;
  if (array_annotated->b != 10)
__builtin_abort ();

  printf("pass\n");
  return 0;
}


adding -fno-tree-fre -fno-tree-pre -fno-code-hoisting cures the issue

[opc@qinzhao-aarch64-ol8 ~]$ ./Install/latest-d/bin/gcc t.c -O2
[opc@qinzhao-aarch64-ol8 ~]$ ./a.out
Aborted (core dumped)
[opc@qinzhao-aarch64-ol8 ~]$ ./Install/latest-d/bin/gcc t.c -O2 -fno-tree-fre
-fno-tree-pre -fno-code-hoisting
[opc@qinzhao-aarch64-ol8 ~]$ ./a.out
pass

[Bug tree-optimization/116316] incorrect code with -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---

:13:6: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
   13 | *(size_t *)(&(array_annotated->b)) = 10;
  |  ^

-fno-strict-aliasing  fixes it.

You access `array_annotated->b` via size_t (which is most likely `unsigned
long`) and via int. Since long and int are distant types (and not signed
versions of each other) they don't alias.

[Bug c++/116317] New: [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

Bug ID: 116317
   Summary: [modules] checking ICE in type_node, at
cp/module.cc:8693 on stream out
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

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

Seen while building https://github.com/tcbrindle/flux as a module:

$ g++ -std=c++20 -fmodules-ts flux.ii
flux.ii:1:8: internal compiler error: in type_node, at cp/module.cc:9088
1 | export module flux;
  |^~

gcc trunk, 14, 13 ICE (with --enable-checking=release), gcc 12 doesn't. 
Bisection points to r13-1210 but that likely just triggered a latent modules
streaming issue.

The testcase could use more reduction.

[Bug other/116260] testsuite-management/validate_failures.py: split multilib ABIs in results

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

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

--- Comment #3 from Christophe Lyon  ---
Thanks for the additional information, indeed in our CI we do not run
validations for several "variations", so it's not surprising this case is not
handled very well.

So you suggest having one manifest per variation, and calling
validate_failures.py --manifest manifest.var1 --build_dir xxx --variation var1
etc ?

[Bug tree-optimization/116316] incorrect code with -O2

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> :13:6: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
>13 | *(size_t *)(&(array_annotated->b)) = 10;
>   |  ^
> 
> -fno-strict-aliasing  fixes it.
> 
> You access `array_annotated->b` via size_t (which is most likely `unsigned
> long`) and via int. Since long and int are distant types (and not signed
> versions of each other) they don't alias.

Okay, I see. thanks a lot.
I did suspect that this is a source code issue, now confirmed. -:)

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 58890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58890&action=edit
Slightly more reduced

I removed most of the concepts except for one (sequence_concept) which seems
needed for the ICE.

[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:5ce3874b3c2fdd76f506005cb1171a732af7c807

commit r15-2857-g5ce3874b3c2fdd76f506005cb1171a732af7c807
Author: Andrew MacLeod 
Date:   Thu Aug 8 16:34:15 2024 -0400

Limit equivalency processing in rangers cache.

When the number of block exceed VRP's sparse threshold, do not query all
equivalencies during cache filling.   This can be expensive for unknown
benefit.

PR tree-optimization/114855
* gimple-range-cache.cc (ranger_cache::fill_block_cache): Do not
process equivalencies if the number of blocks is too high.

[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:9e4da946c4263a4c89d5fc365b3c97ae244c5018

commit r15-2858-g9e4da946c4263a4c89d5fc365b3c97ae244c5018
Author: Andrew MacLeod 
Date:   Thu Aug 8 16:37:28 2024 -0400

Adjust rangers recomputation depth based on the number of BBs.

As the number of block increase, recomputations can become more
expensive.  Adjust the depth limit to avoid excessive compile time.

PR tree-optimization/114855
* gimple-range-gori.cc (gori_compute::gori_compute): Adjust
ranger_recompute_depth limit based on the number of BBs.
(gori_compute::may_recompute_p): Use previosuly calculated value.
* gimple-range-gori.h (gori_compute::m_recompute_depth): New.

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58890|0   |1
is obsolete||

--- Comment #2 from Andrew Pinski  ---
Created attachment 58891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58891&action=edit
Slightly more, (inlining some things)

[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://github.com/GaloisIn
   ||c/cryptol-compiler/issues/4
   ||2

--- Comment #18 from Sam James  ---
(In reply to Richard Biener from comment #15)
> The testcase is a bit unwieldly for developing a fix - I wonder if it's
> possible to auto-generate smaller testcases with the same structure?

Jeremy, could you give us some recipe for it?

That said I tried to look a bit, the file has "Automatically generated by SBV".

It looks like an SMT solver:
https://hackage.haskell.org/package/sbv-10.11/docs/Documentation-SBV-Examples-CodeGeneration-AddSub.html
(the example looks kind of similar to the original testcase too, just way
smaller).

That led me to
https://github.com/GaloisInc/cryptol-compiler/issues/42#issuecomment-2076405286.
I don't know enough about Haskell stuff to try extract a generator from that
though.

[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #19 from Andrew Macleod  ---
(In reply to GCC Commits from comment #17)
> The master branch has been updated by Andrew Macleod :
> 
> https://gcc.gnu.org/g:9e4da946c4263a4c89d5fc365b3c97ae244c5018
> 
> commit r15-2858-g9e4da946c4263a4c89d5fc365b3c97ae244c5018
> Author: Andrew MacLeod 
> Date:   Thu Aug 8 16:37:28 2024 -0400
> 
> Adjust rangers recomputation depth based on the number of BBs.
> 
> As the number of block increase, recomputations can become more
> expensive.  Adjust the depth limit to avoid excessive compile time.
> 
> PR tree-optimization/114855
> * gimple-range-gori.cc (gori_compute::gori_compute): Adjust
> ranger_recompute_depth limit based on the number of BBs.
> (gori_compute::may_recompute_p): Use previosuly calculated value.
> * gimple-range-gori.h (gori_compute::m_recompute_depth): New.

With the second change, on my machine at -O1 we're down to:
 callgraph ipa passes   :  47.83 ( 11%)   1.64 ( 25%)  49.65 ( 12%)
  338M ( 17%)
 df live regs   :  12.19 (  3%)   0.19 (  3%)  12.41 (  3%)
0  (  0%)
 dominator optimization : 214.20 ( 51%)   0.58 (  9%) 215.56 ( 51%)
  113M (  6%)
 backwards jump threading   :  27.58 (  7%)   0.20 (  3%)  27.95 (  7%)
   68M (  3%)
 tree CCP   :   5.46 (  1%)   0.15 (  2%)   5.72 (  1%)
   14M (  1%)
 tree FRE   :   5.48 (  1%)   0.20 (  3%)   5.69 (  1%)
 2063k (  0%)
 dominance computation  :   8.54 (  2%)   0.18 (  3%)   8.79 (  2%)
0  (  0%)
 integrated RA  :  28.48 (  7%)   0.03 (  0%)  28.61 (  7%)
   29M (  1%)
 LRA non-specific   :  12.43 (  3%)   0.01 (  0%)  12.48 (  3%)
 8977k (  0%)
 TOTAL  : 416.00  6.52424.24   
 2041M

So better.  Still have some DOM work to do.  That is mostly edge range
recalculations in the path ranger and GORI.

-O2 is a different beast :-P

[Bug rtl-optimization/116028] [15 regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Reopening as presumably this is now relevant again after the revert from
g:4734c1bfe837b3e70bc783dafc442de3bca43d88

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58889|0   |1
is obsolete||
  Attachment #58891|0   |1
is obsolete||

--- Comment #3 from Andrew Pinski  ---
Created attachment 58892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58892&action=edit
Reduced further

Note if you comment out the line defining sequence_traits class, we get a
segfault instead of this ICE.

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 58893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58893&action=edit
Cleaned up and removed the `namespace detail`

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 58894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58894&action=edit
Reduced slightly more removing the inner class from reverse_adaptor

[Bug c++/116317] [modules] checking ICE in type_node, at cp/module.cc:8693 on stream out

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58894|0   |1
is obsolete||

--- Comment #7 from Andrew Pinski  ---
Created attachment 58895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58895&action=edit
Reduced even further

Removes the last concept which is no longer needed since first is now in the
reverse_adaptor class.

The important part is `element_t` trailing return type. If I
change it to being `element_t`, there is no ICE. Note I changed first to be
an explict template to make easier to show that rather than taking an auto
argument.

[Bug c++/90960] declaring a member function with a computed typedef is confused as a data member definition

[alisdairm at me dot com via Gcc-bugs]

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

--- Comment #4 from Alisdair Meredith  ---
I now believe my original bug report is invalid, due to a rarely consulted
paragraph of the standard, [temp.spec.general]p8.

If a function declaration acquired its function type through a dependent type
(13.8.3.2) without using the syntactic form of a function declarator, the
program is ill-formed.

As Jonathan notes, the diagnostic could be better.  In this case, we should
expect a diagnostic on the line declaring `heck` as a class member, before we
get to trying to form the external definition --- which is also an error that
is correctly diagnosed in the first case.

[Bug target/116283] [15 Regression] RISC-V rv64id_zbs ICE: unrecognizable insn

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r15-2860-gd4e1290e5d603984e9b410c7d4cf21a9ffbd68fd
Author: Jeff Law 
Date:   Fri Aug 9 17:46:01 2024 -0600

[RISC-V][PR target/116283] Fix split code for recent Zbs improvements with
masked bit positions

So Patrick's fuzzer found an interesting little buglet in the Zbs
improvements
I added a couple months back.

Specifically when we have masked bit position for a Zbs instruction.  If
the
mask has extraneous bits set we'll generate an unrecognizable insn due to
an
invalid constant.

More concretely, let's take this pattern:

> (define_insn_and_split ""
>   [(set (match_operand:DI 0 "register_operand" "=r")
> (any_extend:DI
>  (ashift:SI (const_int 1)
> (subreg:QI(and:DI
(match_operand:DI 1 "register_operand" "r")
>   (match_operand 2 "const_int_operand"))
0]
What we need to know to transform this into bset for rv64.

After masking the shift count we want to know the low 5 bits aren't 0x1f. 
If
they were 0x1f, then the constant generated would be 0x8000 which would
then need sign extension out to 64bits, which the bset instruction will not
do
for us.

We can ignore anything outside the low 5 bits.  The mode of the shift is
SI, so
shifting by 32+ bits is undefined behavior.

It's also worth explicitly mentioning that the hardware is going to mask
the
count against 0x3f.

The net is if (operands[2] & 0x1f) != 0x1f, then this transformation is
safe.
So onto the generated split code...

>   [(set (match_dup 0) (and:DI (match_dup 1) (match_dup 2)))
>(set (match_dup 0) (zero_extend:DI (ashift:SI
>  (const_int 1)
>  (subreg:QI (match_dup 0) 0]

Which would seemingly do exactly what we want.   The problem is the first
split
insn.  If the constant does not fit into a simm12, that insn won't be
recognized resulting in the ICE.

The fix is simple, we just need to mask the constant before generating RTL.
 We
can just mask it against 0x1f since we only care about the low 5 bits.

This affects multiple patterns.  I've added the appropriate fix to all of
them.

Tested in my tester.  Waiting for the pre-commit bits to run before
pushing.

PR target/116283
gcc/
* config/riscv/bitmanip.md (Zbs combiner patterns/splitters): Mask
the
bit position in the split code appropriately.

gcc/testsuite/

* gcc.target/riscv/pr116283.c: New test

[Bug target/116283] [15 Regression] RISC-V rv64id_zbs ICE: unrecognizable insn

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/116318] New: RISC-V: Miscompile at -O1 with -fwhole-program

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 116318
   Summary: RISC-V: Miscompile at -O1 with -fwhole-program
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a, c, d;
short b[][8] = {};
int main() {
  for (; d < 7; d++) {
a = b[d][c];
__builtin_printf("%lX\n", a ^ 4095UL);
  }
}

Commands:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -fwhole-program -O1 preprocessed.c -o test.o
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 test.o
14FE
FC3
F97
75FC
FE7
FEB
FFF

> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -fwhole-program -O0 preprocessed.c -o test.o
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/qemu-riscv64 test.o
FFF
FFF
FFF
FFF
FFF
FFF
FFF

Found via fuzzer.

[Bug target/116318] RISC-V: Miscompile at -O1 with -fwhole-program

[andrew at sifive dot com via Gcc-bugs]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #1 from Andrew Waterman  ---
Isn't this UB since the accesses to b are out of bounds?