[Bug rtl-optimization/115933] [15 Regression] wrong code at -O1 with "-fno-tree-loop-optimize -ftree-vrp -fno-tree-ch -fgcse" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #10 from Georg-Johann Lay  ---
...hmmm https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html reads: 

6.18 Arrays of Length Zero

Declaring zero-length arrays is allowed in GNU C as an extension. A zero-length
array can be useful as the last element of a structure that is really a header
for a variable-length object:

[...]

Declaring zero-length arrays in other contexts, including [...] as non-member
objects, is discouraged. Accessing elements of zero-length arrays declared in
such contexts is undefined and may be diagnosed. 



So the test case for PR64088 is already invalid?

[Bug rtl-optimization/115933] [15 Regression] wrong code at -O1 with "-fno-tree-loop-optimize -ftree-vrp -fno-tree-ch -fgcse" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Sam James  ---
Patch posted:
https://inbox.sourceware.org/gcc-patches/997895c567a0687937590da415fdc1871d1b6898.1729409627.git@gentoo.org/

[Bug rtl-optimization/115933] [15 Regression] wrong code at -O1 with "-fno-tree-loop-optimize -ftree-vrp -fno-tree-ch -fgcse" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

 CC||tsamismanolis at gmail dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116372,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116405

--- Comment #5 from Sam James  ---
(In reply to Sam James from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Sam James from comment #2)
> > > Looks like trunk works now?
> > 
> > Maybe r15-3138-ga9f5e23aba1a6f ?
> 
> Let me check.


Where 'bad' = fixed:
```
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
72c9b5f438f22cca493b4e2a8a2a31ff61bf1477
b219cbeda72d23b7ad6ff12cd159784b7ef00667
We cannot bisect more!
```

so let me add this testcase and we can call it closed?

[Bug tree-optimization/117237] New: wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu

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

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

Bug ID: 117237
   Summary: wrong code at -O{s,2,3} with "-fno-tree-fre
-fno-tree-pre -fno-code-hoisting -fno-inline" on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 11.* and affects 12.* and later.

Compiler Explorer: https://godbolt.org/z/ax1Y59rKM

[519] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241020 (experimental) (GCC) 
[520] % 
[520] % gcctk -O3 small.c; ./a.out
[521] % 
[521] % gcctk -O3 -fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline
small.c
[522] % ./a.out
Segmentation fault
[523] % 
[523] % cat small.c
struct a {
  int b;
};
int d, e;
const struct a c;
int f(struct a g) { return g.b; }
static void h(const struct a g) {
  d = f(g);
  e = g.b;
  1 ^ g.b;
}
int main() { h(c); }

[Bug ipa/117237] [12/13/14/15 regression] wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu

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

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

--- Comment #1 from Sam James  ---
-fno-ipa-cp works

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #9 from Georg-Johann Lay  ---
(In reply to Segher Boessenkool from comment #8)
> That is invalid C code, of course (an out of bounds access).
What about the other test case
https://gcc.gnu.org/bugzilla/attachment.cgi?id=59148 ?

That's from an already existing test case for PR64088, so why has an ICE been
fixed for that PR instead of closing it as invalid? -- Or ar least rejecting
that test case?

[Bug target/117159] kmovw storing to memory is assumed to zero-extend

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #7 from Hongtao Liu  ---
Fixed everywhere.

[Bug middle-end/117243] program crash under -O3 optimization or higher

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

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

--- Comment #8 from Sam James  ---
For the original testcase, it got fixed on trunk by r15-79-ge8ae56a7dc46e3.

[Bug tree-optimization/117244] New: [14/15 Regression] missed vectorization of (unsigned int)(-(bool_var))

[keowang at hotmail dot com via Gcc-bugs]

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

Bug ID: 117244
   Summary: [14/15 Regression] missed vectorization of (unsigned
int)(-(bool_var))
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keowang at hotmail dot com
  Target Milestone: ---

Starting with GCC-14, GCC seems to have missed the vectorization of the
following code.

https://godbolt.org/z/xfdW1dcM7

unsigned int a[19];

void f(bool b[19]) {
for (int i = 0; i < 19; i += 1) 
{
a[i] = -b[i];
}
}

f(bool*):
xor eax, eax
.L2:
movzx   edx, BYTE PTR [rdi+rax]
neg edx
mov DWORD PTR a[0+rax*4], edx
add rax, 1
cmp rax, 19
jne .L2
ret

If bisect is correct:
e6bcf83989478348428c732c11e6c0f1719e9214 is the first bad commit
https://github.com/gcc-mirror/gcc/commit/e6bcf83989478348428c732c11e6c0f1719e9214

[Bug tree-optimization/117244] [14/15 Regression] missed vectorization of (unsigned int)(-(int)(bool_var))

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-21
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.3
Summary|[14/15 Regression] missed   |[14/15 Regression] missed
   |vectorization of (unsigned  |vectorization of (unsigned
   |int)(-(bool_var))   |int)(-(int)(bool_var))
 Ever confirmed|0   |1
 Blocks||53947

--- Comment #1 from Andrew Pinski  ---
Yes it does bisect to that but it was a latent missed optimization.
In that this does not vectorize either:
```
unsigned int a[19];
void f2(bool b[19]) {
for (int i = 0; i < 19; i += 1) 
{
unsigned t = b[i];
a[i] = -t;
}
}
```

When it should.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/117244] [14/15 Regression] missed vectorization of (-(unsigned int)(bool_var))

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

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

--- Comment #2 from Andrew Pinski  ---
For my reduced testcase:
from vect dump with details
>/app/example.cpp:3:23: note:   _4 has no range info

Huh?
  # RANGE [irange] unsigned int [0, 0][+INF, +INF]
  _4 = -t_9;

It has a range of just 0/~0.

In the sign case we have:
```
/app/example.cpp:3:23: note:   _4 has range [0x, 0x0]
/app/example.cpp:3:23: note:   can narrow to signed:1 without loss of
precision: _4 = -t_9;
```

[Bug tree-optimization/117244] [14/15 Regression] missed vectorization of (-(unsigned int)(bool_var))

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

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

--- Comment #3 from Andrew Pinski  ---
vect_get_range_info/vect_determine_precisions_from_range definitely needs to be
improved here.

[Bug tree-optimization/117244] [14/15 Regression] missed vectorization of (-(unsigned int)(bool_var))

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> vect_get_range_info/vect_determine_precisions_from_range definitely needs to
> be improved here.

It does not support sign extended types into unsigned types at all since it
still uses the legacy range which only supports min/max and those expressions
need 2 ranges to express the sign extension into unsigned types.

[Bug rtl-optimization/117239] wrong code at -O{s,2} with "-fno-inline -fschedule-insns" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
I can't reproduce this right now to bisect or confirm. I think it's something
on my end but I tried negating the defaults we apply in our system compiler and
it didn't help...

[Bug rtl-optimization/117239] [12/13/14/15 Regression] wrong code at -O{s,2} with "-fno-inline -fschedule-insns" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-20
 Ever confirmed|0   |1
Summary|wrong code at -O{s,2} with  |[12/13/14/15 Regression]
   |"-fno-inline|wrong code at -O{s,2} with
   |-fschedule-insns" on|"-fno-inline
   |x86_64-linux-gnu|-fschedule-insns" on
   ||x86_64-linux-gnu

--- Comment #3 from Andrew Pinski  ---
movq%rdx, 16(%rsp)

is missing with -fschedule-insns .

[Bug rtl-optimization/117239] wrong code at -O{s,2} with "-fno-inline -fschedule-insns" on x86_64-linux-gnu

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

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

--- Comment #2 from Alexander Monakov  ---
Amazing bug. Note that it depends on high-order bits of return address
overwriting o.i, so may need -no-pie -fno-pie to reproduce. Alternatively,
changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduce with PIE as well.

postreload-cse incorrectly eliminates the store that prepares the second
argument of 'm' on the stack (the same store was previously done when preparing
the argument for 'r'), disregarding that the stack pointer moved back-and-forth
in between.

[Bug target/117240] New: ICE: in copy_to_mode_reg, at explow.cc:657 with -mvaes -mno-xsave and __builtin_ia32_vaesenc_v32qi()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117240
   Summary: ICE: in copy_to_mode_reg, at explow.cc:657 with -mvaes
-mno-xsave and __builtin_ia32_vaesenc_v32qi()
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mvaes -mno-xsave testcase.c -Wno-psabi
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:10: internal compiler error: in copy_to_mode_reg, at explow.cc:657
6 |   return __builtin_ia32_vaesenc_v32qi(v, v);
  |  ^~
0x2c8a8be internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xe83a43 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1533
0x78b75a copy_to_mode_reg(machine_mode, rtx_def*)
/repo/gcc-trunk/gcc/explow.cc:657
0x1ad0dfa ix86_expand_binop_builtin
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:10433
0x1175709 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:12401
0x1182355 store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.cc:6766
0x1184653 expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.cc:6487
0x1033d29 expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:2894
0x1033d29 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3963
0x1033d29 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4105
0x103a87e expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6161
0x103c567 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6900
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.

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

[Bug ipa/117237] [12/13/14/15 regression] wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu since r12-434-g93f8cb4965cebe

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/111873] [12/13/14/15 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

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

[Bug tree-optimization/114864] [12/13/14/15 regression] wrong code at -O1 with "-fno-tree-dce -fno-tree-fre" on x86_64-linux-gnu since r12-434-g93f8cb4965cebe

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/111873] [12/13/14/15 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe

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

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

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

[Bug rtl-optimization/117239] [12/13/14/15 Regression] wrong code at -O{s,2} with "-fno-inline -fschedule-insns" on x86_64-linux-gnu

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

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

--- Comment #4 from Alexander Monakov  ---
(In reply to Alexander Monakov from comment #2)
> Alternatively,
> changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduce with PIE as well.
  ^
I meant 'if (o.i == 1)'.

[Bug target/117159] kmovw storing to memory is assumed to zero-extend

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:5259d3927c1c8e3a15b4b844adef59b48c241233

commit r15-4510-g5259d3927c1c8e3a15b4b844adef59b48c241233
Author: liuhongt 
Date:   Wed Oct 16 13:43:48 2024 +0800

Refine splitters related to "combine vpcmpuw + zero_extend to vpcmpuw"

r12-6103-g1a7ce8570997eb combines vpcmpuw + zero_extend to vpcmpuw
with the pre_reload splitter, but the splitter transforms the
zero_extend into a subreg which make reload think the upper part is
garbage, it's not correct.

The patch adjusts the zero_extend define_insn_and_split to
define_insn to keep zero_extend.

gcc/ChangeLog:

PR target/117159
* config/i386/sse.md
(*_cmp3_zero_extend):
Change from define_insn_and_split to define_insn.
(*_cmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_cmp3_zero_extend_2):
Split to the zero_extend pattern.
(*_cmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr117159.c: New test.
* gcc.target/i386/avx512bw-pr103750-1.c: Remove xfail.
* gcc.target/i386/avx512bw-pr103750-2.c: Remove xfail.

[Bug target/117159] kmovw storing to memory is assumed to zero-extend

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:79e7e02b7cc578d03eab2b50c029f44409ef8e26

commit r14-10807-g79e7e02b7cc578d03eab2b50c029f44409ef8e26
Author: liuhongt 
Date:   Wed Oct 16 13:43:48 2024 +0800

Refine splitters related to "combine vpcmpuw + zero_extend to vpcmpuw"

r12-6103-g1a7ce8570997eb combines vpcmpuw + zero_extend to vpcmpuw
with the pre_reload splitter, but the splitter transforms the
zero_extend into a subreg which make reload think the upper part is
garbage, it's not correct.

The patch adjusts the zero_extend define_insn_and_split to
define_insn to keep zero_extend.

gcc/ChangeLog:

PR target/117159
* config/i386/sse.md
(*_cmp3_zero_extend):
Change from define_insn_and_split to define_insn.
(*_cmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_cmp3_zero_extend_2):
Split to the zero_extend pattern.
(*_cmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr117159.c: New test.
* gcc.target/i386/avx512bw-pr103750-1.c: Remove xfail.
* gcc.target/i386/avx512bw-pr103750-2.c: Remove xfail.

(cherry picked from commit 5259d3927c1c8e3a15b4b844adef59b48c241233)

[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Andrew Pinski from comment #10)
> > I am going to implement that first and then implement the phiopt change.
> 
> RTL Patch submitted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665954.html
> 
> Will handle the phiopt/factor patch next.

I just noticed that the rtl patch actually will fix it everywhere too due to
noce_try_ifelse_collapse (which was added with r7-1275-g36f9ad69336aee aka PR
37780).

[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/117235] [15 Regression] trapping fp statement can be moved across another trapping fp statement since r15-4503-g8d6d6d537fdc75

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-October
   ||/665940.html

--- Comment #3 from Andrew Pinski  ---
Submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665940.html

[Bug target/117232] EQ/NE comparison between avx512 kmask and -1 can be optimized with kxortest with checking CF when using cmov

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

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

Hongtao Liu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |liuhongt at gcc dot 
gnu.org
   Last reconfirmed||2024-10-21
 Ever confirmed|0   |1
 CC||liuhongt at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Hongtao Liu  ---
I'll take a look, thanks for report

[Bug tree-optimization/117237] [12/13/14/15 regression] wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu since r12-434-g93f8cb4965cebe

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #4 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/20210609191002.GX7746@tucnak/ leads us
to PR100994 and PR100453.

[Bug c/117241] New: Various pedwarns in c-decl.cc are behind !in_system_header_at

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

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

Bug ID: 117241
   Summary: Various pedwarns in c-decl.cc are behind
!in_system_header_at
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arsen at gcc dot gnu.org
  Target Milestone: ---

When trying to check a libc for >C90 features in headers by running compiling
with:

  -std=c89 -pedantic-errors -Wsystem-headers -x c /dev/null -isystem
sysroot/usr/include -include .h

... it was noted that flexible array members weren't being reported.  Take, for
instance, the following TU:

  # 1 "/tmp/hg/test.h" 3 4
  struct S { char x; char name[]; };

... this should emit a warning (and indeed swapping '3 4' with '1' makes the
warning appear), but does not due to this check:

if (flexible_array_member
&& !in_system_header_at (input_location))
  pedwarn_c90 (loc, OPT_Wpedantic, "ISO C90 does not "
   "support flexible array members");

in c-decl.cc:grokdeclarator.  When removing the in_system_header_at check,
-Wsystem-headers seemed to be understood correctly:

  ~/gcc/_b_coro-fixes/gcc 1 $ git -C ~/gcc/coro-fixes --no-pager diff
  diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
  index aa7f69d1b7bc..f7387b9b7711 100644
  --- a/gcc/c/c-decl.cc
  +++ b/gcc/c/c-decl.cc
  @@ -7490,7 +7490,7 @@ grokdeclarator (const struct c_declarator *declarator,
 flexible_array_member = (t->kind == cdk_id);
   }
  if (flexible_array_member
  -  && !in_system_header_at (input_location))
  +  && !0)//in_system_header_at (input_location))
   pedwarn_c90 (loc, OPT_Wpedantic, "ISO C90 does not "
"support flexible array members");

  ~/gcc/_b_coro-fixes/gcc$ ./cc1 -quiet -v - -quiet -dumpbase - -mtune=generic
-march=x86-64 -pedantic-errors -std=c90 -version -fpreprocessed -o /dev/null
-fcf-protection<<-EOF
  # 1 "/tmp/hg/test.h" 3
  struct S { char x; char name[]; };
  EOF
  GNU C89 (GCC) version 15.0.0 20240927 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 14.2.1 20240921, GMP version 6.3.0, MPFR
version 4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP

  GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
  ignoring nonexistent directory "/usr/local/include"
  ignoring nonexistent directory
"/home/arsen/gcc/_b_coro-fixes/_pfx/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../x86_64-pc-linux-gnu/include"
  #include "..." search starts here:
  #include <...> search starts here:
  
/home/arsen/gcc/_b_coro-fixes/_pfx/lib/gcc/x86_64-pc-linux-gnu/15.0.0/include
   /home/arsen/gcc/_b_coro-fixes/_pfx/include
  
/home/arsen/gcc/_b_coro-fixes/_pfx/lib/gcc/x86_64-pc-linux-gnu/15.0.0/include-fixed
   /usr/include
  End of search list.
  Compiler executable checksum: 175a97d69d759221b576ba224ecb364c
  ~/gcc/_b_coro-fixes/gcc$ ./cc1 -Wsystem-headers -quiet -v - -quiet -dumpbase
- -mtune=generic -march=x86-64 -pedantic-errors -std=c90 -ve
  rsion -fpreprocessed -o /dev/null -fcf-protection<<-EOF
  # 1 "/tmp/hg/test.h" 3
  struct S { char x; char name[]; };
  EOF
  GNU C89 (GCC) version 15.0.0 20240927 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 14.2.1 20240921, GMP version 6.3.0, MPFR
version 4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP

  GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
  ignoring nonexistent directory "/usr/local/include"
  ignoring nonexistent directory
"/home/arsen/gcc/_b_coro-fixes/_pfx/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../x86_64-pc-linux-gnu/include"
  #include "..." search starts here:
  #include <...> search starts here:
  
/home/arsen/gcc/_b_coro-fixes/_pfx/lib/gcc/x86_64-pc-linux-gnu/15.0.0/include
   /home/arsen/gcc/_b_coro-fixes/_pfx/include
  
/home/arsen/gcc/_b_coro-fixes/_pfx/lib/gcc/x86_64-pc-linux-gnu/15.0.0/include-fixed
   /usr/include
  End of search list.
  Compiler executable checksum: 175a97d69d759221b576ba224ecb364c
  /tmp/hg/test.h:1:25: error: ISO C90 does not support flexible array members
[-Wpedantic]
  1 | struct S { char x; char name[]; };
| ^~~~
  ~/gcc/_b_coro-fixes/gcc 1 $ 

... so, perhaps the checks are an artifact of a bygone time before
-Wsystem-headers :-)

[Bug middle-end/78463] pure/const functions are assumed not to trap

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-20

--- Comment #3 from Andrew Pinski  ---
.

[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Carlos Galvez  ---
Hi! I had another look at this an have some follow-up questions:

> it looks like GCC already implements the suggested resolution.

This does not seem to be the case? The related bug is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84884 and it's not closed. I can
confirm it on Compiler Explorer: 

https://godbolt.org/z/6EGbovPMq

So, if the solution to DR 2244 is not yet implemented, then it feels this is a
slightly different issue?

Also, DR 2244 talks about a case where we have a "friend" function performing
the construction. It seems therefore that having "friend" is important, why
else would they add such a constraint? In my example, I don't have "friend", so
I'm unsure if DR 2244 applies there.

[Bug testsuite/117183] gcc.dg/c23-constexpr-2a.c: comment mismatch with dg-do

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
Thanks.

[Bug tree-optimization/117237] [12/13/14/15 regression] wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu since r12-434-g93f8cb4965cebe

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

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

Sam James  changed:

   What|Removed |Added

Summary|[12/13/14/15 regression]|[12/13/14/15 regression]
   |wrong code at -O{s,2,3} |wrong code at -O{s,2,3}
   |with "-fno-tree-fre |with "-fno-tree-fre
   |-fno-tree-pre   |-fno-tree-pre
   |-fno-code-hoisting  |-fno-code-hoisting
   |-fno-inline" on |-fno-inline" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r12-434-g93f8cb4965cebe
 CC||ebotcazou at gcc dot gnu.org
  Component|ipa |tree-optimization

--- Comment #3 from Sam James  ---
Bisect says r12-434-g93f8cb4965cebe.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #11 from denisc at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to denisc from comment #2)
> > Comment on attachment 59393 [details]
> > Simplified testcase
> > 
> > void
> > f ()
> > {
> >   volatile char c[0];
> >   c[0] = 0;
> > }
> 
> That is invalid C code, of course (an out of bounds access).

I don't think that it's invalid.(maybe I'm wrong)

Segher, can you suggest how to obtain information (from internal GCC
structures) about such cases ?
ie rewrite TARGET_FRAME_POINTER_REQUIRED hook so that it takes into account
that we have an access to frame but frame-size is zero ?

The current hook:
static bool
avr_frame_pointer_required_p (void) 
{
  return (cfun->calls_alloca
  || cfun->calls_setjmp
  || cfun->has_nonlocal_label
  || crtl->args.info.has_stack_args
  || get_frame_size () > 0);
}

[Bug rtl-optimization/114960] [12/13/14/15 Regression] fails to clean up vector casts since r12-4379-g97c320016642a4

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

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

Sam James  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |fails to clean up vector|fails to clean up vector
   |casts   |casts since
   ||r12-4379-g97c320016642a4

--- Comment #3 from Sam James  ---
r12-4379-g97c320016642a4

[Bug tree-optimization/58195] Missed optimization opportunity when returning a conditional

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> I am going to implement that first and then implement the phiopt change.

RTL Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665954.html

Will handle the phiopt/factor patch next.

[Bug tree-optimization/106786] [12/13/14/15 Regression] SRA regression causes extra instructions sometimes since r12-1529-gd7deee423f993bee

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

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

--- Comment #8 from Sam James  ---
(In reply to Richard Biener from comment #3)
> (leaving the rest of the checks in place, but not sure how safe that is).

There's a bunch of wrong-code bugs with the check in-place for that condition
already, unfortunately.

[Bug ipa/117237] [12/13/14/15 regression] wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jamborm at gcc dot gnu.org,
   ||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
-fno-tree-sra works

[Bug c++/117046] -Wclass-memaccess provides misleading diagnostics on std::memcpy

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos Galvez  ---
Sorry, I commented on the wrong bug, could some admin please delete my last
comment? Thanks!

[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos Galvez  ---
Actually in the patch that would address this issue for Clang
(https://reviews.llvm.org/D53860), they mentioned 2277:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0968r0.html#2227

With emphasis:

> The destructor for each element of class type is potentially invoked (15.4 
> [class.dtor]) from the context where the aggregate initialization occurs. 


Some more comments from the patch:

> I've checked the minutes, and we did indeed discuss that when resolving C++ 
> DR 2227, and decided that the context for the access check should be the 
> context of the aggregate initialization, not the context of the class 
> definition.


This makes sense with my very limited knowledge, but I'd like to hear your
opinion on 2277. It does feel like a separate issue than 2244.

[Bug c++/117046] -Wclass-memaccess provides misleading diagnostics on std::memcpy

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Carlos Galvez  ---
Actually in the patch that would address this issue for Clang
(https://reviews.llvm.org/D53860), they mentioned 2277:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0968r0.html#2227

With emphasis:

> The destructor for each element of class type is potentially invoked (15.4 
> [class.dtor]) from the context where the aggregate initialization occurs. 

Some more comments from the patch:

> I've checked the minutes, and we did indeed discuss that when resolving C++ 
> DR 2227, and decided that the context for the access check should be the 
> context of the aggregate initialization, not the context of the class 
> definition.

This makes sense with my very limited knowledge, but I'd like to hear your
opinion on 2277. It does feel like a separate issue than 2244.

[Bug middle-end/117236] [13/14/15 regression] -Wnull-dereference false positive in GNU tar (regression from GCC 12) since r13-3596-ge7310e24b1c0ca

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-20
 CC||amacleod at redhat dot com
Summary|[13/14/15 regression]   |[13/14/15 regression]
   |-Wnull-dereference false|-Wnull-dereference false
   |positive in GNU tar |positive in GNU tar
   |(regression from GCC 12)|(regression from GCC 12)
   ||since
   ||r13-3596-ge7310e24b1c0ca

--- Comment #1 from Sam James  ---
Started with r13-3596-ge7310e24b1c0ca.

[Bug middle-end/117236] [13/14/15 regression] -Wnull-dereference false positive in GNU tar (regression from GCC 12) since r13-3596-ge7310e24b1c0ca

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |13.4

[Bug tree-optimization/117237] [12/13/14/15 regression] wrong code at -O{s,2,3} with "-fno-tree-fre -fno-tree-pre -fno-code-hoisting -fno-inline" on x86_64-linux-gnu since r12-434-g93f8cb4965cebe

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111873,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106786,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114864

--- Comment #5 from Sam James  ---
Gah, I see, there's a nest of these.

Martin?

[Bug target/117238] New: FAIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error: maximum number of generated reload insns per insn achieved (90))

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

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

Bug ID: 117238
   Summary: FAIL: gcc.c-torture/compile/pr92618.c   -O1  (internal
compiler error: maximum number of generated reload
insns per insn achieved (90))
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59398&action=edit
LRA pass dump

gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c(timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ -fdiagnostics-plain-output -O1 -w -c -o pr92618.o
/home/dave/gnu/gcc/gc
c/gcc/testsuite/gcc.c-torture/compile/pr92618.c
during RTL pass: reload
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c: In
functio
n 'foo':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c:38:1:
inter
nal compiler error: maximum number of generated reload insns per insn achieved
(
90)
0x16bda9b internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x739a47 lra_constraints(bool)
../../gcc/gcc/lra-constraints.cc:5405
0x7247cb lra(_IO_FILE*, int)
../../gcc/gcc/lra.cc:2445
0x6d406f do_reload
../../gcc/gcc/ira.cc:5977
0x6d406f execute
../../gcc/gcc/ira.cc:6165
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 exited with status 1
FAIL: gcc.c-torture/compile/pr92618.c   -O1  (internal compiler error: maximum
number of generated reload insns per insn achieved (90))

[Bug tree-optimization/112418] factor_out_conditional_operation could be done for more phis

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug rtl-optimization/117239] New: wrong code at -O{s,2} with "-fno-inline -fschedule-insns" on x86_64-linux-gnu

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

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

Bug ID: 117239
   Summary: wrong code at -O{s,2} with "-fno-inline
-fschedule-insns" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 11.*, and affects 12.* and later.


Compiler Explorer: https://godbolt.org/z/b86d6z9bf


[526] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241020 (experimental) (GCC) 
[527] % 
[527] % gcctk -O2 small.c; ./a.out
[528] % gcctk -O2 -fno-inline -fschedule-insns small.c
[529] % ./a.out
Aborted
[530] % cat small.c
int a, b, j = 1, k;
int l() { return a; }
struct c {
  int d;
  int e;
  int f;
  int g;
  short h;
  int i;
};
void m(int n, struct c o) {
  if (o.i)
j = 0;
}
int r(struct c n) { return b; }
int main() {
  struct c q = {0, 0, 0, 0, 0, 1};
  k = r(q);
  m(l(), q);
  if (j != 0)
__builtin_abort();
  return 0;
}

[Bug target/117242] New: FAIL: 20_util/variant/run.cc -std=gnu++17 (test for excess errors)

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

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

Bug ID: 117242
   Summary: FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for
excess errors)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59400&action=edit
LRA pass dump

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/home
/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux-gn
u/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.
libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/
home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-15
/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-15/hppa-linux-gnu/sys-include
-fchecking=
1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-
length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOUR
CE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd
c++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc
++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests
uite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/variant/run.cc
-
std=gnu++17 -include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a
-Wl
,--gc-sections
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/files
ystem/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/experime
ntal/.libs -lm -o ./run.exe
In file included from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/vector:67,
 from
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl
ude/functional:66,
 from
/home/dave/gnu/gcc/gcc/libstdc++-v3/include/precompiled/st
dc++.h:53:
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h: In destructor 'std::_UninitDestroyGuard<_ForwardIterator,
_Alloc>::~_Uni
nitDestroyGuard() [with _ForwardIterator = int*; _Alloc =
__gnu_cxx::throw_alloc
ator_limit]':
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h:95: error: unable to find a register to spill
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h:95: error: this is the insn:
(insn 95 950 96 6 (set (mem/f/c:SI (reg/f:SI 315) [152 MEM[(struct
_Rb_tree_head
er *)&_S_map + 4B]._M_header._M_right+0 S4 A32])
(reg/f:SI 316))
"/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/i
nclude/bits/stl_tree.h":208:26 42 {*pa.md:2195}
 (expr_list:REG_DEAD (reg/f:SI 316)
(expr_list:REG_DEAD (reg/f:SI 315)
(nil
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/stl_uninitial
ized.h:95: confused by earlier errors, bailing out
compiler exited with status 1
FAIL: 20_util/variant/run.cc  -std=gnu++17 (test for excess errors)

Similar fails:
FAIL: 23_containers/vector/requirements/exception/generation_prohibited.cc 
-std=gnu++17 (test for excess errors)
FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++23 (test for excess errors)
FAIL: std/ranges/cartesian_product/1.cc  -std=gnu++26 (test for excess errors)

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #12 from Segher Boessenkool  ---
(In reply to denisc from comment #11)
> (In reply to Segher Boessenkool from comment #8)
> > (In reply to denisc from comment #2)
> > > Comment on attachment 59393 [details]
> > > Simplified testcase
> > > 
> > > void
> > > f ()
> > > {
> > >   volatile char c[0];
> > >   c[0] = 0;
> > > }
> > 
> > That is invalid C code, of course (an out of bounds access).
> 
> I don't think that it's invalid.(maybe I'm wrong)

You access elt 0 of the array, but the array has *no* elements.

[Bug fortran/104827] [12/13/14/15 Regression] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.cc:8329 since r12-4409-g724ee5a0093da443

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
   Keywords||ice-on-invalid-code

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> This appears to be fixed in that the ICE no longer occurs.

Intel also rejects both variants as invalid code:

% ifx pr104827-z1.f90 -fopenmp
pr104827-z1.f90(2): error #5082: Syntax error, found IDENTIFIER 'F' when
expecting one of: VENDOR EXTENSION REQUIRES
   !$omp declare variant(a) match(implementation={f([1])})
--^
pr104827-z1.f90(2): error #9091: An OpenMP* trait-property-name must be an
identifier or a string-literal.
   !$omp declare variant(a) match(implementation={f([1])})
-^
pr104827-z1.f90(2): error #8952: The name is not found or is inaccessible.  
[A]
   !$omp declare variant(a) match(implementation={f([1])})
-^
compilation aborted for pr104827-z1.f90 (code 1)


%ifx pr104827-z2.f90 -fopenmp
pr104827-z2.f90(2): error #5082: Syntax error, found IDENTIFIER 'F' when
expecting one of: VENDOR EXTENSION REQUIRES
   !$omp declare variant(a) match(implementation={f(1)})
--^
pr104827-z2.f90(2): error #9091: An OpenMP* trait-property-name must be an
identifier or a string-literal.   [1]
   !$omp declare variant(a) match(implementation={f(1)})
^
pr104827-z2.f90(2): error #8952: The name is not found or is inaccessible.  
[A]
   !$omp declare variant(a) match(implementation={f(1)})
-^
compilation aborted for pr104827-z2.f90 (code 1)


Adding ice-on-invalid to keywords.

Likely fixed during 15-development.

[Bug rtl-optimization/116780] [lra][avr] internal compiler error: output_operand: address operand requires constraint for X, Y, or Z register

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

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

--- Comment #13 from Segher Boessenkool  ---
(In reply to Georg-Johann Lay from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > That is invalid C code, of course (an out of bounds access).
> What about the other test case
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59148 ?

Same problem there.  It is not valid C.

> That's from an already existing test case for PR64088, so why has an ICE
> been fixed for that PR instead of closing it as invalid? -- Or ar least
> rejecting that test case?

Many such problems cannot ever be diagnosed by the compiler.  Simple cases like
here could be of course, but in general it is the halting problem.

It is fine to have testcases that are invalid C, if there is no reasonable
other
way to get at the same problems otherwise, but it of course would be a lot
nicer
to have a testcase that is valid C :-)

> Segher, can you suggest how to obtain information (from internal GCC 
> structures) > about such cases ?

I would do something scan-assembler.  I have no idea what instructions
accessing
the frame look like on AVR, but I imagine it won't be too hard to see this?

But I know nothing that can be (or *could* be, even) done that is not
target-specific.  But this testcase is in gcc.target/ anyway, right?

[Bug middle-end/117243] New: program crash under -O3 optimization or higher

[bouncy12578 at gmail dot com via Gcc-bugs]

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

Bug ID: 117243
   Summary: program crash under -O3 optimization or higher
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bouncy12578 at gmail dot com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-14
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
14-20240412-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-14
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-14-OQFzmN/gcc-14-14-20240412/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-14-OQFzmN/gcc-14-14-20240412/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver
--enable-checking=yes,extra,rtl --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

$ cat a.c
void foo(int a, int b) {
int i, j;
j:
for (b=0; b<2; b++)
{
int c[1][1];
int i, j;
for (i = 0; i < 1; i++)
for (j = 0; j < 1; j++)
c[i][j] = 1;
if (b)
goto j;
}
}

int main() {
foo(1, 2);
}

$ gcc a.c -O3 && ./a.out
Segmentation fault (core dumped)
$ gcc a.c && ./a.out
(infinite loop, the program won't stop)

This bug can be reproduced on gcc 14 and trunk.
Any further modification would eliminate bug.

The program is a designed inifinite loop. It would crash under -O3(or higher)
optimization. -O0, -O1, -O2 won't cause segmentation fault.

Interestingly, if param b in func foo is unsigned, the bug can be reproduced on
gcc 13(12 or lower cannot reproduce it)

[Bug middle-end/117243] program crash under -O3 optimization or higher

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

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

--- Comment #2 from Andrew Pinski  ---
Estimating sizes for loop 2
 BB: 3, after_exit: 0
 BB: 4, after_exit: 0
size: 0-0, last_iteration: 0-0
  Loop size: 0
  Estimated size after unrolling: 1
;; Guessed iterations of loop 2 is 200.84. New upper bound 2.
;; Scaling loop 2 with scale 1.5% (guessed) to reach upper bound 2
;; Not updating exit probability of loop 2; it has no single exit
/app/example.cpp:17:5: optimized: loop with 2 iterations completely unrolled
(header execution count 1073741823)
Latch of last iteration was marked by __builtin_unreachable ().

[Bug middle-end/117243] program crash under -O3 optimization or higher

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

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

--- Comment #1 from Sam James  ---
Trunk works.

[Bug middle-end/117243] program crash under -O3 optimization or higher

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #4 from Sam James  ---
Thanks, I couldn't find the PR. I'll bisect it in both directions anyway.

[Bug middle-end/117243] program crash under -O3 optimization or higher

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Most likely the same issue as PR 114052 .

[Bug middle-end/117243] program crash under -O3 optimization or higher

[bouncy12578 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Ye Xiong  ---
(In reply to Sam James from comment #1)
> Trunk works.

When param b is unsigned, trunk will crash.

[Bug middle-end/117243] program crash under -O3 optimization or higher

[bouncy12578 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Ye Xiong  ---
(In reply to Sam James from comment #1)
> Trunk works.

[Bug middle-end/117243] program crash under -O3 optimization or higher

[bouncy12578 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Ye Xiong  ---
(In reply to Ye Xiong from comment #6)
> (In reply to Sam James from comment #1)
> > Trunk works.
> 
> When param b is unsigned, trunk will crash.

The original reduced file is:
#include 

void foo(uint32_t  a, uint8_t  b)
{
int i, j;
lbl:
for (b = 0; (b <= 7); b += 1)
{
uint8_t c[1][1];
int i, j, k;
for (i = 0; i < 1; i++)
{
for (j = 0; j < 1; j++)
{
c[i][j] = 1;
}
}
if (b)
goto lbl;
}
}

int main() {
foo(1, 2);
}

this version will crash on -O3 or higher on trunk version, we reduced a bit
more but seems the bug would eliminate on trunk version.

[Bug target/117159] kmovw storing to memory is assumed to zero-extend

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

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

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

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

commit r13-9139-gfca35b417c236e3448bc3666820fd1ba423fe6e9
Author: liuhongt 
Date:   Wed Oct 16 13:43:48 2024 +0800

Refine splitters related to "combine vpcmpuw + zero_extend to vpcmpuw"

r12-6103-g1a7ce8570997eb combines vpcmpuw + zero_extend to vpcmpuw
with the pre_reload splitter, but the splitter transforms the
zero_extend into a subreg which make reload think the upper part is
garbage, it's not correct.

The patch adjusts the zero_extend define_insn_and_split to
define_insn to keep zero_extend.

gcc/ChangeLog:

PR target/117159
* config/i386/sse.md
(*_cmp3_zero_extend):
Change from define_insn_and_split to define_insn.
(*_cmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_cmp3_zero_extend_2):
Split to the zero_extend pattern.
(*_cmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr117159.c: New test.
* gcc.target/i386/avx512bw-pr103750-1.c: Remove xfail.
* gcc.target/i386/avx512bw-pr103750-2.c: Remove xfail.

(cherry picked from commit 5259d3927c1c8e3a15b4b844adef59b48c241233)

[Bug target/117159] kmovw storing to memory is assumed to zero-extend

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:91800a70a2af1349eefc5f3380be2b254b1db395

commit r12-10778-g91800a70a2af1349eefc5f3380be2b254b1db395
Author: liuhongt 
Date:   Wed Oct 16 13:43:48 2024 +0800

Refine splitters related to "combine vpcmpuw + zero_extend to vpcmpuw"

r12-6103-g1a7ce8570997eb combines vpcmpuw + zero_extend to vpcmpuw
with the pre_reload splitter, but the splitter transforms the
zero_extend into a subreg which make reload think the upper part is
garbage, it's not correct.

The patch adjusts the zero_extend define_insn_and_split to
define_insn to keep zero_extend.

gcc/ChangeLog:

PR target/117159
* config/i386/sse.md
(*_cmp3_zero_extend):
Change from define_insn_and_split to define_insn.
(*_cmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_ucmp3_zero_extend):
Ditto.
(*_cmp3_zero_extend_2):
Split to the zero_extend pattern.
(*_cmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.
(*_ucmp3_zero_extend_2):
Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr117159.c: New test.
* gcc.target/i386/avx512bw-pr103750-1.c: Remove xfail.
* gcc.target/i386/avx512bw-pr103750-2.c: Remove xfail.

(cherry picked from commit 5259d3927c1c8e3a15b4b844adef59b48c241233)