[Bug rtl-optimization/116915] [15 Regression] wrong code at -O{s,2,3} on x86_64-linux-gnu

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Jeffrey A. Law  ---
Somehow missed this one when it got reported.  It's gone latent on the trunk
due to some unrelated changes.  But ultimately it's the same root cause as
116488.

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

[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu

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

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

--- Comment #6 from Jeffrey A. Law  ---
*** Bug 116915 has been marked as a duplicate of this bug. ***

[Bug target/116425] RISC-V missed optimization: vector lowering along lmul boundaries

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

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

Dusan Stojkovic  changed:

   What|Removed |Added

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

--- Comment #2 from Dusan Stojkovic  ---
I found that adding the extra flag: -mrvv-vector-bits=zvl vectorizes the 
testcase function like so (regardless of whether -mrvv-max-lmul=m1 is included
in the compile flags):

permute_vnx8si:
vl1re32.v   v2,0(a0)
vsetivlizero,8,e32,m1,ta,ma
vrgather.vi v1,v2,1
vs1r.v  v1,0(a2)
ret
permute_vnx16si:
vl2re32.v   v4,0(a0)
vsetivlizero,16,e32,m2,ta,ma
vrgather.vi v2,v4,1
vs2r.v  v2,0(a2)
ret

Gobolt: https://godbolt.org/z/5qEfGj9nP

Ordering of these instructions seems off (vector load before vsetvl?). Also it
seems as though rvv-max-lmul doesn't bind lmul if rvv-vector-bits=zvl is
specified.

[Bug tree-optimization/117176] [15 regression] ICE when building netpbm-11.8.0

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from David Binderman  ---
I see this one also.

[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 #14 from Georg-Johann Lay  ---
(In reply to Segher Boessenkool from comment #13)
> But this testcase is in gcc.target/ anyway, right?
That's just a copy of  gcc.dg/torture/pr64088.c :

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/torture/pr64088.c;h=0ea5fabcc2fc30833d9ab80ce30090f23e46594b;hb=HEAD

This test case works with avr+reload but it fails with avr+lra, so it appeared
to be lra related.

As gcc.dg/torture/pr64088.c is not target-specific, it's supposed to make sense
on all targets? And with lra too, of course.  No?

[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 #9 from Sam James  ---
(In reply to Sam James from comment #8)
> For the original testcase, it got fixed on trunk by r15-79-ge8ae56a7dc46e3.

And started with r14-1163-gd8b058d3ca4ebb, so as pinskia predicted, not super
useful and it's really the same as the other bug.

[Bug sanitizer/117209] [13/14/15 Regression] ICE: verify_gimple failed with asan.

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/117245] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE: verify_ssa failed  |ICE: verify_ssa failed
   |(error: definition in block |(error: definition in block
   |2 follows the use) with VLA |2 follows the use) with VLA
   |types and nested functions  |types in struct with a
   ||vector type rebuild and
   ||nested functions

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

The bug deals with `__attribute__((vector_size(4))) char c[b];` inside the
struct.

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
   Keywords||needs-bisection
  Known to work||12.4.0
Summary|ICE: verify_ssa failed  |[13/14/15 Regression] ICE:
   |(error: definition in block |verify_ssa failed (error:
   |2 follows the use) with VLA |definition in block 2
   |types in struct with a  |follows the use) with VLA
   |vector type rebuild and |types in struct with a
   |nested functions|vector type rebuild and
   ||nested functions
  Known to fail||13.1.0

[Bug tree-optimization/107467] [12/13/14 Regression] Miscompilation involving -Os, flto, and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |rguenth at gcc dot 
gnu.org

--- Comment #14 from Richard Biener  ---
Mine for backporting then (I've verified this fixes the attached single-file
testcase).

[Bug tree-optimization/117245] New: ICE: verify_ssa failed (error: definition in block 2 follows the use)

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 117245
   Summary: ICE: verify_ssa failed (error: definition in block 2
follows the use)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC) 

***
Program:
$ cat mutant.c
void a() {
  int b;
  struct {
char c[b];
  } bar() {
  }
  struct bar {
__attribute__((vector_size(4))) char c[b];
  } (*d)();
  struct bar e() { struct bar f; }
  d = e;
  sizeof(d());
}

***
Command Lines:
$ gcc mutant.c
mutant.c: In function 'e':
mutant.c:13:1: error: definition in block 2 follows the use
   13 | }
  | ^
for SSA_NAME: _16 in statement:
_4 = _16 * 4;
during GIMPLE pass: ssa
mutant.c:13:1: internal compiler error: verify_ssa failed
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x24866d5 verify_ssa(bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Also ICE on trunk.
Compiler Explorer: https://godbolt.org/z/jbhKdxsPd

[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug target/116953] [avr] error: operands to %T/%t must be reg + const_int

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-21
 Ever confirmed|0   |1
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from Georg-Johann Lay  ---
Reopened: The applied fix is incomplete because avr_out_sbxx_branch() is
returning insn output template code that refers to recod_data by means of
%-operands:

  if (long_jump)
return ("rjmp .+4" CR_TAB
"jmp %x3");

  if (!reverse)
return "rjmp %x3";

  return "";
}

Unfortunately I don't have a test case; I stumbled upon this when working on
some feature patch.

One possible fix would be to re-extract insn by means of calling extract_insn()
prior to the sequence from above.

A different approach is to output_asm_insn() instead of returning template
code.

[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2

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

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

--- Comment #6 from Andrew Pinski  ---
Note I suspect PR 117245 and this one has the same underlying issue where
C_TYPE_VARIABLY_MODIFIED gets lost after the vector_size recreates the types. 
That is using a typedef for the vector type fixes the issue because we don't
need to recreate the type.

That is doing:
typedef  __attribute__((vector_size(4))) char v4c;

and then using v4c instead of `__attribute__((vector_size(4))) char` works.

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

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

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

--- Comment #4 from Andrew Pinski  ---
There most likely should be a C front-end specific version of
reconstruct_complex_type which does the copy of C_TYPE_VARIABLY_MODIFIED  too.
Which means this originally was caused by r13-6128.

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

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

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

--- Comment #3 from Andrew Pinski  ---
I am suspecting r13-6128 where C_TYPE_VARIABLY_MODIFIED is getting lost after
applying the vector_size attribute ...

[Bug c++/117246] New: g++ O1 finline bug

[wso4133560 at gmail dot com via Gcc-bugs]

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

Bug ID: 117246
   Summary: g++ O1 finline bug
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wso4133560 at gmail dot com
  Target Milestone: ---

This is my example code:
#include 

class Test
{
public:
static void* operator new(std::size_t count, int value)
{
std::cout << __LINE__ << " " << value << std::endl;
Test *test = static_cast(malloc(count));
//Test * volatile test = static_cast(malloc(count));
test->value = value;
return test;
}

Test()
{
std::cout << __LINE__ << " " << value << std::endl;
}

public:
int value;
};

int main(int argc, char *argv[])
{
Test *test = new(1) Test{};
std::cout << __LINE__ << " " << test->value << std::endl;
delete test;
return 0;
}

I used command "g++ error.cpp -O0 -o error", get result:
8 1
17 1
27 1

I used command "g++ error.cpp -O1 -fno-inline -o error", get result:
8 1
17 1
27 1

I used command "g++ error.cpp -O1 -o error", get result:
8 1
17 0
27 0

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #5 from Martin Uecker  ---
There are a couple of cases where we still forget to set this bit. The
DECL_EXPR were probably never set correctly, but we had some middle end code
before (which was also not correct)  that would catch some of these cases,
hence the regressions. I have a patch in preparation.

[Bug c++/117246] g++ O1 finline bug

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html#index-flifetime-dse

`To preserve stores before the constructor starts (e.g. because your operator
new clears the object storage) but still treat the object as dead after the
destructor, you can use -flifetime-dse=1.`

[no subject]

[Tzxstiy via Gcc-bugs]

🙏ขออนุญาตแนะนำสำหรับเจ้าของธุรกิจ
ที่จดทะเบียนการค้า/พาณิชย์/ หจก. อุตสาหกรรมทั่วไป
ทุนหมุนเวียนระยะสั้น อนุมัติง่าย
☑️เริ่มต้น 1.5% - 0.5%
☑️อนุมัติสูงสุด 3,000,000 บาท
☑️ทราบผล ภายใน 30 นาที (หลังส่งเอกสารครบถ้วน)
☑️พร้อมลงพื้นที่ประเมินหน้างานและทำสัญญา
❌ไม่มีนโยบายเรียกชำระก่อนทำสัญญาทุกกรณี❌
✔️สนใจบริการของเราโทรด่วนหาเรา
ติดต่อ : 082-5928-519 คุณเอก
LINE : ID esc.credit
ต้องขออภัยอีกครั้งหากข้อความนี้เป็นเหตุรบกวนคะ🙏

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

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

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

--- Comment #2 from Andrew Pinski  ---
Looks to be some missing DECL_EXPR which was there for GCC 12 but gone for GCC
13.

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #6 from Martin Uecker  ---

The commit causing this was like this where the middle end code was removed,
which then exposed the cases where the FE did not emit DECL_EXPR correctly.

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42d1612eb5c3b2

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/117246] g++ O1 finline bug

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
amonakov's patches would provide runtime detection, just pending review:
https://inbox.sourceware.org/gcc-patches/20231208134950.14883-1-amona...@ispras.ru/.

[Bug libgcc/115242] libgcc unwinder does not handle vector registers, even if the target machine supports them.

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

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

--- Comment #6 from Florian Weimer  ---
(In reply to Alisa Sireneva from comment #4)
> I think this is a wider issue. The root of the problem is that
> __builtin_unwind_init() affects what it _thinks_ are _callee-saved_
> registers.

I think this should be fine. The functions use the platform calling convention.
If they are called from a function that preserves additional registers, the
compiler needs to emit code to spill those registers before calling those
functions. As far as I understand it, the unwinder code tracks a larger
register set than just the callee-saved registers, so this should work.

> In this bug, the compiler thinks a register doesn't exist when it does. But
> it's also possible that the compiler thinks a register is caller-saved while
> it's actually callee-saved, due to differences in ABI between libgcc_s and
> user code (as reproduced e.g. on x64 by throwing from
> __attribute__((ms_abi)), but should be possible with plain forced unwinding
> too).

According to a quick test, GCC handles this correctly and spills the additional
registers when calling a non-ms_abi function from an ms_abi function. I expect
that it's also possible to compensate for the lack of vector register tracking
in the GNU/Linux x86-64 unwinder through appropriate code generation, but I
haven't got a good test case for that.

The issue on POWER is different because the ABI was enhanced retroactively,
supposedly in a transparent way.

[Bug tree-optimization/117217] [12/13/14/15 Regression] ICE in sra when copying struct with a union of structs with bool bitfields

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/117226] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu with ext-dce since r15-1901-g98914f9eba5f19

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P1

[Bug c/117230] [14/15 Regression] ICE: in sizeof_pointer_memaccess_warning, at c-family/c-warn.cc:987 with -Wsizeof-pointer-memaccess

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

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

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

--- Comment #4 from Richard Biener  ---
Hmm, but re-ordering should be OK as long as no intermediate FP state is
examined (which of course we do not track via dependences in the IL).  I think
we have many more passes where such re-ordering can happen and this is one
of the general issues with properly implementing #pragma FENV_ACCESS - we
need to represent dependences on FP state appropriately.

So I don't think this is worth fixing.

[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

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P2
Version|unknown |15.0

[Bug ada/116438] GNAT should print backtraces on ICEs with bug box

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug ada/116438] GNAT should print backtraces on ICEs with bug box

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

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

--- Comment #8 from Eric Botcazou  ---
Created attachment 59401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59401&action=edit
WIP patch

This adds support for libbacktrace with the big limitations I mentioned.

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org

[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 since r12-7472-g609e8c492d62d9

[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

Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |wrong code at -O{s,2} with  |wrong code at -O{s,2} with
   |"-fno-inline|"-fno-inline
   |-fschedule-insns" on|-fschedule-insns" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r12-7472-g609e8c492d62d9
 CC||ebotcazou at gcc dot gnu.org,
   ||hjl.tools at gmail dot com

--- Comment #5 from Sam James  ---
r12-7472-g609e8c492d62d9 but I suppose it was latent.

[Bug middle-end/117243] [14/15 regression] 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

   Last reconfirmed||2024-10-21
  Known to fail||14.2.1, 15.0
  Known to work||13.3.1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|program crash under -O3 |[14/15 regression] program
   |optimization or higher  |crash under -O3
   ||optimization or higher
   Target Milestone|--- |14.3

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions since r13-6128-g4782

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

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

Sam James  changed:

   What|Removed |Added

Summary|[13/14/15 Regression] ICE:  |[13/14/15 Regression] ICE:
   |verify_ssa failed (error:   |verify_ssa failed (error:
   |definition in block 2   |definition in block 2
   |follows the use) with VLA   |follows the use) with VLA
   |types in struct with a  |types in struct with a
   |vector type rebuild and |vector type rebuild and
   |nested functions|nested functions since
   ||r13-6128-g47821ba07a19b6

--- Comment #7 from Sam James  ---
(In reply to Andrew Pinski from comment #4)
> There most likely should be a C front-end specific version of
> reconstruct_complex_type which does the copy of C_TYPE_VARIABLY_MODIFIED 
> too. Which means this originally was caused by r13-6128.

Confirmed to be r13-6128-g47821ba07a19b6.

[Bug target/117247] [OpenMP][nvptx] cuCtxSynchronize with 'omp target loop' + PRIVATE clause and -O1 (OpenMP_VV's teams_loop/test_target_teams_loop_private.c)

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

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

--- Comment #1 from Tobias Burnus  ---
Follow up note: the following all fails (on nvptx with -Og, -Os, -O1 or
higher); the first two are nearly identical on dump level:
  - omp loop
  - omp simd
  - omp for simd

while the following works:
  - omp for

With -O0, the original code is used:
  a[i] = 2*i + 1;
  b[i] = a[i];
which works.

With -Og, there is initially in the nvptx:

  int D.1717[1024];

  _20 = .GOMP_SIMT_ENTER (simduid.1_18(D), &D.1717);
  _22 = .GOMP_SIMT_ENTER_ALLOC (_20);
  _23 = .GOMP_SIMT_LANE ();

* * *

My suspicion is that this causes an out-of-stack memory:

.func compute$_omp_fn$0$impl (.param.u64 %in_ar0)
{
.local.align 8 .b8 %simtstack_ar[4096];


Indication for this is also that it works with N=100.

[Bug target/117247] New: [OpenMP][nvptx] cuCtxSynchronize with 'omp target loop' + PRIVATE clause and -O1 (OpenMP_VV's teams_loop/test_target_teams_loop_private.c)

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

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

Bug ID: 117247
   Summary: [OpenMP][nvptx] cuCtxSynchronize with 'omp target
loop' + PRIVATE clause and -O1 (OpenMP_VV's
teams_loop/test_target_teams_loop_private.c)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
  Target Milestone: ---

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

Shows up with OpenMP_VV's 

https://github.com/OpenMP-Validation-and-Verification/OpenMP_VV/blob/master/tests/5.0/teams_loop/test_target_teams_loop_private.c

It works with AMD GCN or -O0 but with -O1 and higher, it fails with:

  libgomp: cuCtxSynchronize error: an illegal memory access was encountered
  libgomp: cuMemFree_v2 error: an illegal memory access was encountered
  libgomp: device finalization failed

The problem is 'omp target' + 'omp loop' + 'private'; using 'for' instead of
'loop' works.

Simplified test case attached ('target loop' not 'target teams loop').

[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085

[frank.scheiner at web dot de via Gcc-bugs]

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

Frank Scheiner  changed:

   What|Removed |Added

 CC||frank.scheiner at web dot de

--- Comment #5 from Frank Scheiner  ---
This issue also affects cross-compilation for ia64 on x86_64 using the latest
GCC snapshot (gcc-15-20241020), though for a different file in the Linux
v6.12-rc4 (w/ia64) ([1]) sources, namely: lib/fonts/font_8x8.c.

```
[...]
  CC  lib/fonts/font_8x8.o
  CC  net/sched/sch_mq.o
lib/fonts/font_8x8.c:2584:1: internal compiler error: in size_binop_loc, at
fold-const.cc:2085
 2584 | };
  | ^
  CC [M]  drivers/char/ipmi/ipmi_si_hotmod.o
[...]
  AR  drivers/soc/loongson/built-in.a
0x17a1200 internal_error(char const*, ...)
/usr/src/gcc/gcc/diagnostic-global-context.cc:517
0x61909f fancy_abort(char const*, int, char const*)
/usr/src/gcc/gcc/diagnostic.cc:1551
  CC  net/sched/sch_api.o
  AR  drivers/soc/mediatek/built-in.a
  AR  drivers/soc/microchip/built-in.a
  CC  kernel/cgroup/freezer.o
  CC  net/netlink/genetlink.o
  AR  drivers/soc/nuvoton/built-in.a
0x5eb81f size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
/usr/src/gcc/gcc/fold-const.cc:2085
  AR  drivers/soc/pxa/built-in.a
  CC  drivers/pci/host-bridge.o
0xf90739 array_size_for_constructor
/usr/src/gcc/gcc/varasm.cc:5490
0xf90739 output_constructor_regular_field
/usr/src/gcc/gcc/varasm.cc:5660
0xf90739 output_constructor
/usr/src/gcc/gcc/varasm.cc:5956
0xf90a01 assemble_variable_contents
/usr/src/gcc/gcc/varasm.cc:2269
0xf93297 assemble_variable(tree_node*, int, int, int)
/usr/src/gcc/gcc/varasm.cc:2448
  AR  drivers/soc/amlogic/built-in.a
0xf95cda varpool_node::assemble_decl()
/usr/src/gcc/gcc/varpool.cc:596
0xf95cda varpool_node::assemble_decl()
/usr/src/gcc/gcc/varpool.cc:564
0xf966ee symbol_table::output_variables()
/usr/src/gcc/gcc/varpool.cc:764
0x7c014d symbol_table::compile()
/usr/src/gcc/gcc/cgraphunit.cc:2407
0x7c2e37 symbol_table::compile()
/usr/src/gcc/gcc/cgraphunit.cc:2315
0x7c2e37 symbol_table::finalize_compilation_unit()
/usr/src/gcc/gcc/cgraphunit.cc:2589
  AR  drivers/soc/qcom/built-in.a
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.
```

[1]: https://github.com/johnny-mnemonic/linux-ia64/tree/v6.12-rc4-w-ia64

[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu

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

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

--- Comment #5 from Jeffrey A. Law  ---
*** Bug 117226 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/117226] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu with ext-dce since r15-1901-g98914f9eba5f19

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Jeffrey A. Law  ---
Same root cause.

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

[Bug rtl-optimization/116915] [15 Regression] wrong code at -O{s,2,3} on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug gcov-profile/117211] [15 regression] Building gcc configured with --enable-coverage=opt fails with a link error after r15-4286-gc397a8c12296b7

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

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117110
 Resolution|--- |FIXED

--- Comment #2 from Martin Jambor  ---
AFAICT, this has been fixed with r15-4345-g384faebde257b0 (Jakub Jelinek:
genmatch: Revert recent genmatch changes, instead add custom diag_vfprintf
routine [PR117110]).

[Bug middle-end/117123] [14/15 regression] Generated code at -Os on trunk is larger than GCC 14.4 since r14-6536-gcd794c39610177 (sccopy)

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
   Assignee|pheeck at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #11 from Richard Biener  ---
So without SCCCOPY we do

Starting insert iteration 1
Replaced redundant PHI node defining spud_0_16 with patatino_a.0_1
Replaced redundant PHI node defining spud_0_6 with patatino_a.0_1
Replaced redundant PHI node defining k_7 with 0
Replaced _2 & _19 with 0 in all uses of _18 = _2 & _19;
Removing unexecutable edge from if (_18 != 0)

so we're not doing any insertion but we are instead able to simplify.  With
SCCCOPY

Starting insert iteration 1
Skipping partial redundancy for expression {gt_expr,spud_0_15,1000} (0026), no
redundancy on to be optimized for speed edge
Skipping partial redundancy for expression {bit_and_expr,pretmp_8,_18} (0027),
no redundancy on to be optimized for speed edge
Skipping partial redundancy for expression {mult_expr,k_6,l_25} (0002), no
redundancy on to be optimized for speed edge
Skipping partial redundancy for expression {plus_expr,_2,spud_0_23} (0008), no
redundancy on to be optimized for speed edge
Skipping partial redundancy for expression {plus_expr,l_25,1} (0009), no
redundancy on to be optimized for speed edge

I think the difference is in value-numbering, in the good case we do

-Value numbering stmt = spud_0_16 = PHI 
-Predication says 10 and patatino_a.0_1 are equal on edge 19 -> 4
-Predication says 0 and patatino_a.0_1 are equal on edge 16 -> 4
-Setting value number of spud_0_16 to patatino_a.0_1 (changed)

while in the bad case

+Value numbering stmt = spud_0_15 = PHI <10(19), 0(16), patatino_a.0_1(17)>
+Setting value number of spud_0_15 to spud_0_15 (changed)
+Making available beyond BB5 spud_0_15 for value spud_0_15

so what tree-ssa-sccvn.cc:visit_phi does is dependent on the order of
arguments.  This is because for the use of equivalences we seek for
patatino_a.0_1 == 10 on the 19->4 edge but with the other order we look
for 10 == 0 on the 16->5 edge but such kind of equivalence is of course
not present.  For the equivalence code to work best we'd need to make sure
to first process an edge with a varying SSA def.

I'll see how to arrive at this without confusing the code even more.

[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085

[frank.scheiner at web dot de via Gcc-bugs]

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

--- Comment #7 from Frank Scheiner  ---
(In reply to Jakub Jelinek from comment #3)
> Another option would be to revert r15-4402 and r15-4377 and reapply once
> this fix is tested and approved.

Reverting both commits results in a working compiler:

```
# bski /usr/src/ski/ski-bootloader/ski-bootloader
/boot/vmlinux-6.12.0-rc4-4714f12a36a0-ia64-ski-hp-sim-00037-g4714f12a36a0-dirty
root=/dev/sda simscsi=./sd simeth=enp3s0f0 init=/root/bin/ski_test.bash
PATH=/bin:/sbin:/usr/bin:/usr/sbin rw memblock=debug & 
loading
/boot/vmlinux-6.12.0-rc4-4714f12a36a0-ia64-ski-hp-sim-00037-g4714f12a36a0-dirty...
probing initramfs ...
initramfs not passed
starting kernel...
Linux version 6.12.0-4714f12a36a0-ia64-ski-hp-sim-g4714f12a36a0-dirty
(root@dl380-g7) (ia64-linux-gcc (GCC) 15.0.0 20241020 (experimental), GNU ld
(GNU Binutils) 2.43.1) #1 SMP PREEMPT Mon Oct 21 15:06:56 CEST 2024
efi: EFI v1.0 by Hewlett-Packard
efi: SALsystab=0x10a510 
warning: unable to switch EFI into virtual mode (status=131)
No I/O port range found in EFI memory map, falling back to AR.KR0
(0xc00)
printk: legacy console [simcons0] enabled
[...]
```

[Bug middle-end/116290] [12/13/14 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:69934cb171fdd9d58dd64bb1811afaf43f6f7e44

commit r14-10810-g69934cb171fdd9d58dd64bb1811afaf43f6f7e44
Author: Richard Biener 
Date:   Sun Oct 13 15:12:44 2024 +0200

tree-optimization/116290 - fix compare-debug issue in ldist

Loop distribution does different analysis with -g0/-g due to counting
a debug stmt starting a BB against a limit which will everntually
lead to different IVOPTs choices.  I've fixed a possible IVOPTs
issue on the way even though it doesn't make a difference here.

PR tree-optimization/116290
* tree-loop-distribution.cc (determine_reduction_stmt_1): PHIs
have no debug variants.  Start with first non-debug real stmt.
* tree-ssa-loop-ivopts.cc (find_givs_in_bb): Do not analyze
debug stmts.

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

(cherry picked from commit 566740013b3445162b8c4bc2205e4e568d014968)

[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10809-g2ac6159f8b5119e75a19f70f3c4578895f59cb53
Author: Richard Biener 
Date:   Fri May 17 11:02:29 2024 +0200

middle-end/115110 - Fix view_converted_memref_p

view_converted_memref_p was checking the reference type against the
pointer type of the offset operand rather than its pointed-to type
which leads to all refs being subject to view-convert treatment
in get_alias_set causing numerous testsuite fails but with its
new uses from r15-512-g9b7cad5884f21c is also a wrong-code issue.

PR middle-end/115110
* tree-ssa-alias.cc (view_converted_memref_p): Fix.

(cherry picked from commit a5b3721c06646bf5b9b50a22964e8e2bd4d03f5f)

[Bug lto/116907] [14 regression] ICE when building kakoune-2024.05.18 with LTO

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

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

--- Comment #35 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

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

commit r14-10812-ga4744558b6a1d0a1c203acc827b6ad0cfe039212
Author: Richard Biener 
Date:   Sun Oct 13 12:44:04 2024 +0200

tree-optimization/116907 - stale BLOCK reference from DECL_VALUE_EXPR

When we remove unused BLOCKs we fail to clean references to them
from DECL_VALUE_EXPRs of variables in other BLOCKs which in the
PR causes LTO streaming to walk into pointers to GGC freed blocks.

There's the question of whether such DECL_VALUE_EXPRs should keep
variables and blocks referenced live (it doesn't seem to do that)
and whether such DECL_VALUE_EXPRs should have survived in the
first place.

PR tree-optimization/116907
* tree-ssa-live.cc (clear_unused_block_pointer_in_block): New
helper.
(clear_unused_block_pointer): Call it.

(cherry picked from commit 7d15248d41dc45a4ba2d38ff532b672a5c0651d0)

[Bug tree-optimization/116982] [14 Regregression] ICE on valid code at -O3 with "-fno-tree-dce -fno-tree-dominator-opts -fno-tree-pre -fno-tree-dse -fno-tree-copy-prop -fno-tree-fre -fno-code-hoisting

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:1d11536881e60f36a2b8ad9919169ac7a8bc0e3e

commit r14-10813-g1d11536881e60f36a2b8ad9919169ac7a8bc0e3e
Author: Richard Biener 
Date:   Mon Oct 7 11:05:17 2024 +0200

tree-optimization/116982 - analyze scalar loop exit early

The following makes sure to discover the scalar loop IV exit during
analysis as failure to do so (if DCE and friends are disabled this
can happen due to if-conversion doing DCE and FRE on the if-converted
loop) would ICE later.

I refrained from larger refactoring to be able to eventually backport.

PR tree-optimization/116982
* tree-vectorizer.h (vect_analyze_loop): Pass in .LOOP_VECTORIZED
call.
(vect_analyze_loop_form): Likewise.
* tree-vect-loop.cc (vect_analyze_loop_form): Reject loops where we
cannot determine a IV exit for the scalar loop.
(vect_analyze_loop): Adjust.
* tree-vectorizer.cc (try_vectorize_loop_1): Likewise.
* tree-parloops.cc (gather_scalar_reductions): Likewise.

(cherry picked from commit 9b86efd5210101954bd187c3aa8bb909610a5746)

[Bug tree-optimization/117104] [12/13/14 regression] ICE when building python-3.12.7 (prepare_cmp_insn, at optabs.cc:4622) with -O2 -march=x86-64-v4 -fno-vect-cost-model -fwrapv

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:44c3eba2dfa71cb7cd9f8c3e7f33ef2b08132a51

commit r14-10814-g44c3eba2dfa71cb7cd9f8c3e7f33ef2b08132a51
Author: Richard Biener 
Date:   Sat Oct 12 14:51:37 2024 +0200

tree-optimization/117104 - add missed guards to max(a,b) != a
simplification

For vector types we have to make sure the comparison result is a vector
type and the resulting compare operation is supported.  As the resulting
compare is never an equality compare I didn't bother to check for the
cbranch case.

PR tree-optimization/117104
* match.pd ((cmp:c (minmax:c @0 @1) @0) -> (out @0 @1)): Properly
guard the vector case.

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

(cherry picked from commit f54d42e7e7a558b273d87f95b3e5b1938f5a)

[Bug tree-optimization/116481] [12/13/14 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:8d8b8ed7835a1a03932a8c90c7c725f9903450d5

commit r14-10811-g8d8b8ed7835a1a03932a8c90c7c725f9903450d5
Author: Richard Biener 
Date:   Sun Oct 13 11:42:27 2024 +0200

tree-optimization/116481 - avoid building function_type[]

The following avoids building an array type with function or method
element type during diagnosing an array bound violation as this
will result in an error, rejecting a program with a not too useful
error message.  Instead build such array type manually.

PR tree-optimization/116481
* pointer-query.cc (build_printable_array_type):
Build an array types with function or method element type
manually to avoid bogus diagnostic.

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

(cherry picked from commit 1506027347776a2f6ec5b92d56ef192e85944e2e)

[Bug middle-end/116290] [12/13 Regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||14.2.0
  Known to work||14.2.1
Summary|[12/13/14 regression]   |[12/13 Regression]
   |-fcompare-debug |-fcompare-debug
   |-gno-statement-frontiers|-gno-statement-frontiers
   |-O2 failure with|-O2 failure with
   |evolution-data-server-3.52. |evolution-data-server-3.52.
   |4   |4
   Priority|P3  |P2

[Bug tree-optimization/116982] [14 Regregression] ICE on valid code at -O3 with "-fno-tree-dce -fno-tree-dominator-opts -fno-tree-pre -fno-tree-dse -fno-tree-copy-prop -fno-tree-fre -fno-code-hoisting

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail||14.2.0
   Priority|P3  |P2
  Known to work||14.2.1

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

[Bug target/117248] New: gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic exception

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

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

Bug ID: 117248
   Summary: gcc/libgcc/libgcc2.h:232:25: internal compiler error:
Arithmetic exception
   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
CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

While working on changes to support LRA, the following bug was
introduced.  It only occurs when LRA is used.  It doesn't occur with
legacy reload.

It occurs building libgcc in stage 2.

/home/dave/gnu/gcc/objdir64/./gcc/xgcc -B/home/dave/gnu/gcc/objdir64/./gcc/
-B/o
pt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-15/hppa64-hp-h
pux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/include
-isyste
m /opt/gnu64/gcc/gcc-15/hppa64-hp-hpux11.11/sys-include   -fno-checking -O2 -g
-
O2  -O2 -g -DIN_GCC   -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./incl
ude  -frandom-seed=fixed-seed -Dpa64=1 -DELF=1 -mlong-calls  -g -DIN_LIBGCC2
-fb
uilding-libgcc -fno-stack-protector  -frandom-seed=fixed-seed -Dpa64=1 -DELF=1
-
mlong-calls  -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/.
 -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS
-D
USE_EMUTLS  -o _umoddi3_di.o -MT _umoddi3_di.o -MD -MP -MF _umoddi3_di.dep
-DLIB
GCC2_UNITS_PER_WORD=4 -DL_umoddi3 -c ../../../gcc/libgcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../gcc/libgcc/libgcc2.c:56:
../../../gcc/libgcc/libgcc2.c: In function '__umoddi3':
../../../gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic
except
ion
  232 | #define __NDW(a,b)  __ ## a ## di ## b
  | ^~
../../../gcc/libgcc/libgcc2.h:290:25: note: in expansion of macro '__NDW'
  290 | #define __umoddi3   __NDW(umod,3)
  | ^
../../../gcc/libgcc/libgcc2.c:1286:1: note: in expansion of macro '__umoddi3'
 1286 | __umoddi3 (UDWtype u, UDWtype v)
  | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[3]: *** [../../../gcc/libgcc/config/pa/t-dimode:23: _umoddi3_di.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
'/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libgcc'
make[2]: *** [Makefile:18835: all-stage2-target-libgcc] Error 2

Program received signal SIGFPE, Arithmetic exception.
0x425cede8 in $$divU () at ../../gcc/gcc/gimple-expr.h:66
66return (type1 == type2
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   
breakpoint already hit 27704 times
ignore next 281 hits
1.1 y 0x414f4e24 in
vect_slp_function(function*) at ../../gcc/gcc/gimple-iterator.h:168
1.2 y 0x83ffbfc349a0 <$$divU>
1.3 y 0x83ffbfe3f9cc <$$divU>
(gdb) bt
#0  0x425cede8 in $$divU () at ../../gcc/gcc/gimple-expr.h:66
#1  0x8001004c1f58 in ?? ()
#2  0x414d007c in vectorizable_slp_permutation_1 (
vinfo=0x800100496ff0, gsi=0x0, node=0x8001005aa3d8, perm=...,
children=..., dump_p=false) at ../../gcc/gcc/tree-vect-slp.cc:10435
#3  0x414e8928 in vectorizable_slp_permutation (
vinfo=0x83ffbf480540, gsi=0x0, node=0x8001004886e8,
cost_vec=0x8001005aa400) at ../../gcc/gcc/dumpfile.h:534
#4  vect_slp_analyze_node_operations_1 (vinfo=0x83ffbf480540,
node=0x8001004886e8, node_instance=0x2, cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7433
#5  vect_slp_analyze_node_operations (vinfo=0x83ffbf480540,
node=, node_instance=0x2, visited_set=...,
visited_vec=..., cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7656
#6  0x414e80c8 in vect_slp_analyze_node_operations (
vinfo=0x83ffbf480540, node=, node_instance=0x2,
visited_set=..., visited_vec=..., cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7633
#7  0x414e80c8 in vect_slp_analyze_node_operations (
vinfo=0x83ffbf480540, node=, node_instance=0x2,
visited_set=..., visited_vec=..., cost_vec=0x8001005aa400)
at ../../gcc/gcc/tree-vect-slp.cc:7633
---Type  to continue, or q  to quit---
#8  0x414ea594 in vect_slp_analyze_operations (vinfo=0x0)
at ../../gcc/gcc/tree-vect-slp.cc:8051
#9  0x414f26a0 in vect_sl

[Bug c++/117224] warning states "this" is explicit by-copy capture but it's an explicit by-reference capture

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
It seems GCC's warning was consistent with the C++ standard until
wg21.link/p0018r3 which introduced '*this' captures and in turn changed the
standard's wording to be in terms of the current object instead of the 'this'
pointer.

While the warning could use updating, it doesn't seem outright wrong in its
current form since a by-reference capture of the current object is equivalent
to a by-copy capture of the 'this' pointer (and indeed that's how it's
implemented).

[Bug c/117190] [15 Regression] ICE on linux-6.11.3: in size_binop_loc, at fold-const.cc:2085

[frank.scheiner at web dot de via Gcc-bugs]

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

--- Comment #6 from Frank Scheiner  ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 59372 [details]
> gcc15-pr117190.patch
> 
> Untested fix.
Unfortunately applying the patch onto gcc-15-20241020
(01f50ebfd97a7bd17a4cc94c403a8e126986c02c) makes it only worse for my use case:

```
[...]
  CC  init/main.o
during RTL pass: dse2
init/main.c: In function 'set_reset_devices':
init/main.c:187:1: internal compiler error: Segmentation fault
  187 | }
  | ^
0x17a1200 internal_error(char const*, ...)
/usr/src/gcc/gcc/diagnostic-global-context.cc:517
0xc3918f crash_signal
/usr/src/gcc/gcc/toplev.cc:321
0xc14ae0 poly_int_rtx_p(rtx_def const*, poly_int<1u, long>*)
/usr/src/gcc/gcc/rtl.h:2418
0xc14ae0 simplify_context::simplify_binary_operation_1(rtx_code, machine_mode,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/usr/src/gcc/gcc/simplify-rtx.cc:2880
0xc1748d simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
/usr/src/gcc/gcc/simplify-rtx.cc:2682
0xc199fc simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/usr/src/gcc/gcc/rtl.h:3503
0xc199fc simplify_rtx(rtx_def const*)
/usr/src/gcc/gcc/simplify-rtx.cc:8136
0x7ce297 cselib_expand_value_rtx_1
/usr/src/gcc/gcc/cselib.cc:2154
0x7ce468 expand_loc
/usr/src/gcc/gcc/cselib.cc:1782
0x7ce180 cselib_expand_value_rtx_1
/usr/src/gcc/gcc/cselib.cc:1945
0x7cfa06 cselib_expand_value_rtx(rtx_def*, bitmap_head*, int)
/usr/src/gcc/gcc/cselib.cc:1842
0x1578119 canon_address
/usr/src/gcc/gcc/dse.cc:1157
0x15789c0 record_store
/usr/src/gcc/gcc/dse.cc:1431
0x157ab3a scan_insn
/usr/src/gcc/gcc/dse.cc:2692
0x157ab3a dse_step1
/usr/src/gcc/gcc/dse.cc:2809
0x157ab3a rest_of_handle_dse
/usr/src/gcc/gcc/dse.cc:3726
0x157ab3a execute
/usr/src/gcc/gcc/dse.cc:3799
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.
make[3]: *** [scripts/Makefile.build:229: init/main.o] Error 1
make[2]: *** [scripts/Makefile.build:478: init] Error 2
make[1]: *** [/dev/shm/torvalds-linux/Makefile:1936: .] Error 2
make: *** [Makefile:224: __sub-make] Error 2
```
...as it already breaks early on. Haven't yet tested reverting the mentioned
commits.

[Bug libstdc++/117220] [15 regression] is broken with Clang (stl_iterator.h:1080:42: error: an attribute list cannot appear here)

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-4515-gcba80691251efccf44ab9aecb26558319605c9ea
Author: Jonathan Wakely 
Date:   Mon Oct 21 12:09:36 2024 +0100

libstdc++: Fix order of [[...]] and __attribute__((...)) attrs [PR117220]

GCC allows these in either order, but Clang doesn't like the C++11-style
[[__nodiscard__]] coming after __attribute__((__always_inline__)).

libstdc++-v3/ChangeLog:

PR libstdc++/117220
* include/bits/stl_iterator.h: Move _GLIBCXX_NODISCARD
annotations after __attribute__((__always_inline__)).

[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involving -Os, flto, and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||14.2.0
Summary|[12/13/14 Regression]   |[12/13 Regression]
   |Miscompilation involving|Miscompilation involving
   |-Os, flto, and  |-Os, flto, and
   |-fno-strict-aliasing since  |-fno-strict-aliasing since
   |r12-656-ga564da506f52be66   |r12-656-ga564da506f52be66
  Known to work||14.2.1

--- Comment #15 from Richard Biener  ---
Fixed for 14.3

[Bug lto/116907] [14 regression] ICE when building kakoune-2024.05.18 with LTO

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #36 from Richard Biener  ---
Fixed (for sure latent, but I'm not going to backport further at this point).

[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involving -Os, flto, and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

--- Comment #16 from Sam James  ---
We should add the testcase as well (I can do it).

[Bug libstdc++/117220] [15 regression] is broken with Clang (stl_iterator.h:1080:42: error: an attribute list cannot appear here)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed

[Bug rtl-optimization/116783] [14/15 Regression] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Alex Coplan :

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

commit r15-4518-gc0e54ce1999ccf2241f74c5188b11b92e5aedc1f
Author: Alex Coplan 
Date:   Fri Sep 20 17:39:39 2024 +0100

pair-fusion: Assume alias conflict if common address reg changes [PR116783]

As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into
returning false when a common base register (in this case, x1) was
modified between the mem and the store insn.  This lead to wrong code as
the accesses really did alias.

To avoid this sort of problem, this patch avoids invoking RTL alias
analysis altogether (and assume an alias conflict) if the two insns to
be compared share a common address register R, and the insns see different
definitions of R (i.e. it was modified in between).

gcc/ChangeLog:

PR rtl-optimization/116783
* pair-fusion.cc (def_walker::cand_addr_uses): New.
(def_walker::def_walker): Add parameter for candidate address
uses.
(def_walker::alias_conflict_p): Declare.
(def_walker::addr_reg_conflict_p): New.
(def_walker::conflict_p): New.
(store_walker::store_walker): Add parameter for candidate
address uses and pass to base ctor.
(store_walker::conflict_p): Rename to ...
(store_walker::alias_conflict_p): ... this.
(load_walker::load_walker): Add parameter for candidate
address uses and pass to base ctor.
(load_walker::conflict_p): Rename to ...
(load_walker::alias_conflict_p): ... this.
(pair_fusion_bb_info::try_fuse_pair): Collect address register
uses for candidate insns and pass down to alias walkers.

gcc/testsuite/ChangeLog:

PR rtl-optimization/116783
* g++.dg/torture/pr116783.C: New test.

[Bug middle-end/117123] [14/15 regression] Generated code at -Os on trunk is larger than GCC 14.4 since r14-6536-gcd794c39610177 (sccopy)

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

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

--- Comment #10 from Filip Kastl  ---
I've looked at the pre-details dumps for runs with and without sccopy1 (I'm
compiling the reduced testcase with -Os).  Even when I adjust for different SSA
name versions, there are many differences in the dumps.  The ANTIC_IN and
ANTIC_OUT sets certainly differ between the two runs.  The first ANTIC_IN set
that is different is ANTIC_IN[8]

without sccopy1:
[changed] ANTIC_IN[8] := { _2 (0002), spud_0_6 (0001), {gt_expr,spud_0_6,1000}
(0010) }

with sccopy1:
[changed] ANTIC_IN[8] := { _18 (0013), spud_0_5 (0003), {gt_expr,spud_0_5,1000}
(0014), {bit_and_expr,_18,_19} (0012) }

SSA name version 2 maps to 18 and 6 maps to 5 so that's ok.  But in the run
with sccopy1 there is an extra element -- the expression _18 & _19.  As I've
noted, the GIMPLE code before pre is the same in both runs up to reordering
blocks and edges.  However, pre produces a different ANTIC_IN.

Should I rename the report to something like "PRE gets confused by edge order
and fails to optimize out code at -Os"?

Btw, if this is sufficient evidence that this is a bug in pre and if that's ok,
I'll unassign myself from this bug.

[Bug c++/117246] g++ O1 finline bug

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html#index-
> flifetime-dse
> 
> `To preserve stores before the constructor starts (e.g. because your
> operator new clears the object storage) but still treat the object as dead
> after the destructor, you can use -flifetime-dse=1.`

The code is not valid C++ though, so should be fixed instead of disabling
optimizations.
https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse

operator new is for allocating memory, not initializing members. A constructor
is for initializing members.

[Bug c++/117246] g++ O1 finline bug

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

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

--- Comment #4 from Jonathan Wakely  ---
The 'delete test' is undefined behaviour as well. You should enable warnings
when compiling: -Wall

[Bug rtl-optimization/116783] [14 Regression] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

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

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

Alex Coplan  changed:

   What|Removed |Added

Summary|[14/15 Regression] Wrong|[14 Regression] Wrong code
   |code at -O2 with late pair  |at -O2 with late pair
   |fusion pass (wrong alias|fusion pass (wrong alias
   |analysis)   |analysis)

--- Comment #6 from Alex Coplan  ---
Fixed on trunk, will work on a backport to 14 after a week or so.

[Bug c++/117231] [15 regression] Incorrect code generation for std::generator

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jakub at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107637

--- Comment #1 from Patrick Palka  ---
Seems to have started with r15-3840-g650e9156656187.

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions since r13-6128-g4782

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #8 from uecker at gcc dot gnu.org ---
See 117145 for a patch.

[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2

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

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

--- Comment #7 from uecker at gcc dot gnu.org ---
Created attachment 59404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59404&action=edit
patch


Candidate patch for PR117145 and PR11745

[Bug target/116425] RISC-V missed optimization: vector lowering along lmul boundaries

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

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

--- Comment #3 from Jeffrey A. Law  ---
The vector loads you're referring to always load a full vector register and do
not need a configuration to be set by vsetvl. There's also move instructions
that copy from one vector register to another without needing to worry about
the vector configuration.

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

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

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

--- Comment #5 from Joseph S. Myers  ---
I agree that we should consider -ftrapping-math to be misnamed and to be about
exception flags, not anything that would involve preserving the order in which
exceptions are raised (between function calls or anything else that might
examine / modify exception state), or preserving the number of times a given
exception is raised beyond preserving whether that number is zero or nonzero
(again, between anything that might examine / modify exception state).

[Bug target/117240] ICE: in copy_to_mode_reg, at explow.cc:657 with __builtin_ia32_vaesenc_v32qi() or __builtin_ia32_vaesenc_v64qi()

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 59403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59403&action=edit
testcase failing with -mevex512 -mvaes

$ x86_64-pc-linux-gnu-gcc -mevex512 -mvaes 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_v64qi(v, v);
  |  ^~
0x2c7f67e internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xe7fc61 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1551
0x789792 copy_to_mode_reg(machine_mode, rtx_def*)
/repo/gcc-trunk/gcc/explow.cc:657
0x1acd21a ix86_expand_binop_builtin
/repo/gcc-trunk/gcc/config/i386/i386-expand.cc:10433
0x1171a79 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:12401
0x117e6c5 store_expr(tree_node*, rtx_def*, int, bool, bool)
/repo/gcc-trunk/gcc/expr.cc:6766
0x11809c3 expand_assignment(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/expr.cc:6487
0x1030099 expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:2894
0x1030099 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3963
0x1030099 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4105
0x1036bee expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6161
0x10388d7 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.

[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value

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

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

François Dumont  changed:

   What|Removed |Added

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

--- Comment #12 from François Dumont  ---
I agree with Jonathan, this use case is showing that the optimization is not
Standard compliant. I'll got it removed shortly.

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5

[Bug middle-end/117249] New: [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

Bug ID: 117249
   Summary: [12/13/14/15 Regression] --disable-checking is broken
since r5-2450
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Since r5-2450-gb787e7a2c2c9be, --disable-checking has been broken since it
added a few gcc_assert that has side effects.

e.g.:
```
-  slot = pointer_map_insert (data->eh_map, (void *)old_r);
-  gcc_assert (*slot == NULL);
-  *slot = (void *)new_r;
+  gcc_assert (!data->eh_map->put (old_r, new_r));
```

Either we should remove assert checking or fix these locations.
Since it has been broken for 10 years now I think we should just remove assert
checking.

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

--- Comment #1 from Andrew Pinski  ---
Note assert checking has been enabled for release checking so this is why it
was not noticed until now. I only noticed because I was working on SLSR and
noticed the bad gcc_assert and was going to submit a patch to fix those but
decided to double check to see when the bad gcc_assert was added and noticed it
was after SLSR was done rather than before.

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2014-August/394801.html

[Bug testsuite/117250] New: [15] RISC-V: gfortran.dg/unsigned_38.f90 Error: Operand of unary numeric operator '-' at (1) is UNSIGNED(4)

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 117250
   Summary: [15] RISC-V: gfortran.dg/unsigned_38.f90 Error:
Operand of unary numeric operator '-' at (1) is
UNSIGNED(4)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Postcommit is finding the following error on all linux targets:
FAIL: gfortran.dg/unsigned_38.f90   -O  (test for excess errors)

https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1953

Test has been failing since its introduction in r15-4494-g4f9b1735ab5

Testsuite log: 
Executing on host:
/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/testsuite/gfortran4/../../gfortran
-B/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/testsuite/gfortran4/../../
-B/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/lib32/ilp32d/libgfortran/

/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gfortran.dg/unsigned_38.f90
 -march=rv32gcv -mabi=ilp32d -mcmodel=medlow   -fdiagnostics-plain-output 
-fdiagnostics-plain-output-O  -funsigned -S   -o unsigned_38.s(timeout
= 600)
spawn -ignore SIGHUP
/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/testsuite/gfortran4/../../gfortran
-B/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/testsuite/gfortran4/../../
-B/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/lib32/ilp32d/libgfortran/
/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gfortran.dg/unsigned_38.f90
-march=rv32gcv -mabi=ilp32d -mcmodel=medlow -fdiagnostics-plain-output
-fdiagnostics-plain-output -O -funsigned -S -o unsigned_38.s
/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gfortran.dg/unsigned_38.f90:5:14:
Error: Operand of unary numeric operator '-' at (1) is UNSIGNED(4)
compiler exited with status 1
FAIL: gfortran.dg/unsigned_38.f90   -O  (test for excess errors)
Excess errors:
/data-disk-1/github/rise-postcommit-7/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gfortran.dg/unsigned_38.f90:5:14:
Error: Operand of unary numeric operator '-' at (1) is UNSIGNED(4)

[Bug testsuite/117250] [15] RISC-V: gfortran.dg/unsigned_38.f90 Error: Operand of unary numeric operator '-' at (1) is UNSIGNED(4)

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

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

--- Comment #1 from Edwin Lu  ---
Failed to see https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1955
which shows the test as fixed already. Closing bugzilla

[Bug target/117251] SHA3 code for PowerPC has a major slow down

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

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|15.0|14.0
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||14.0
   Host||powerpc64le-unknown-linux-g
   ||nu
   Last reconfirmed||2024-10-21
  Build||powerpc64le-unknown-linux-g
   ||nu
 Target||powerpc64le-unknown-linux-g
   ||nu
  Known to work||13.0
 Ever confirmed|0   |1

--- Comment #1 from Michael Meissner  ---
I am setting the priority and importance higher since SHA3 is a critical part
of the Linux operating system.

[Bug target/117251] SHA3 code for PowerPC has a major slow down

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
I have patches, and I will take the bug.

[Bug target/117251] SHA3 code for PowerPC has a major slow down

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

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

--- Comment #2 from Michael Meissner  ---
Created attachment 59406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59406&action=edit
Singlebuff.c test

The singlebuff.c is a simpler test case than multibuff.c.  However, the numbers
quoted and such are based on the multibuff.c test.

[Bug tree-optimization/117252] New: SLSR does not always handle mem_refs

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

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

Bug ID: 117252
   Summary: SLSR does not always handle mem_refs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-dom3" } */

struct x
{
  int a[16];
  int b[16];
  int c[16];
};

extern void foo (int, int, int);


void
f1 (int *p, __SIZE_TYPE__ n)
{
  foo (p[n], p[16+n], p[n+2*16]);
}

/* { dg-final { scan-tree-dump-times "\\* 4;" 1 "dom3" { target { int32 } } } }
*/
/* { dg-final { scan-tree-dump-times "\\* 2;" 1 "dom3" { target { int16 } } } }
*/
/* { dg-final { scan-tree-dump-times "p_\\d\+\\(D\\) \\+ \[^\r\n\]*_\\d\+;" 1
"dom3" } } */
/*
  { dg-final { scan-tree-dump-times "MEM *? *\\\[\\(struct x
\\*\\)\[^\r\n\]*_\\d\+" 3 "dom3" } } */

```

Currently SLSR produces:
```
  _1 = n_12(D) * 4;
  _2 = p_13(D) + _1;
  _3 = *_2;
  _5 = _1 + 64;
  _6 = p_13(D) + _5;
  _7 = *_6;
  _9 = _5 + 64;
  _10 = p_13(D) + _9;
  _11 = *_10;
  foo (_3, _7, _11);
```

Which is good that is able to remove the multiple n*4 but it does not remove
the redundant `p + _1 ` (which is removed on the rtl level later on).

Note this is a reduced testcase from gcc.dg/tree-ssa/slsr-27.c if we expand out
the array reference early.

[Bug target/117253] [14/15 regression] Generated code at -Os on trunk is larger than GCC 13.3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.4

--- Comment #1 from Andrew Pinski  ---
aarch64 does NOT show a regression. 

But basically the issue:
if ((i * j) > 20 && (i + j) < 15) {
  result += i * j;
}

is converted to result += (i * j) * ((i * j) > 20 && (i + j) < 15).

And then selects the multiply due to code size and it just goes down hill from
there.

This is 100% a synthetic test so I am not sure we are worried about the code
size increase here for x86_64; especially for x86_64.

[Bug target/117251] New: SHA3 code for PowerPC has a major slow down

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

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

Bug ID: 117251
   Summary: SHA3 code for PowerPC has a major slow down
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

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

The sha3 functions compiled for the powerpc has a slowdown in GCC 15 and GCC 14
compared to GCC 13 and GCC 12 when compiled for power10, due to excessive
amounts of spilling.

The main function for multibuf.c has 3,747 lines, all of which are using vector
unsigned long long.  There are 696 vector shifts (all shifts are constant),
1,824 vector xor's and 600 vector andc's.

The timing for these runs is the following:

Trunk  (sources checked out October 5th):6.15 seconds
GCC 14 (sources checked out October 21st):   6.28 seconds
GCC 13 (sources checked out October 21st):   5.57 seconds
GCC 12 (sources checked out October 21st):   5.61 seconds
GCC 11 (sources checked out October 21st):   9.56 seconds

In looking at it, the main thing that steps out is the reason for either
spilling or moving variables is the support in gcc/rs6000/fusion.md (generated
by gcc/rs6000/genfusion.pl) that tries to fuse the vec_andc feeding into
vec_xor, and other vec_xor's feeding into vec_xor.

On the powerpc for power10, there is a special fusion mode that happens if the
machine has a VANDC or VXOR instruction that is adjacent to a VXOR instruction
and the VANDC/VXOR feeds into the 2nd VXOR instruction.

While the Power10 has 64 vector registers (which uses the XXL prefix to do the
logical operation), the fusion only works with the older Altivec instruction
set (which uses the V prefix).  The Altivec instruction only has 32 vector
registers (which are overlaid over the VSX vector registers 32-63).

By having the combiner patterns fuse_vandc_vxor and fuse_vxor_vxor to do this
fusion, it means that the register allocator has more register pressure for the
traditional Altivec registers instead of the VSX registers.

In addition, since there are vector shifts, these shifts only work on the
traditional Altivec registers, which adds to the Altivec register pressure.

Finally loading up the vector constants for the shifts requires Altivec
registers (using XXSPLTIB and VEXTSB2D to form the constant).  But this doesn't
add to the register pressure, since these constants are all used in the VRLD
vector shift instruction.

Here are some summaries for the various compilers:

Trunk   GCC14   GCC13   GCC12   GCC11
-   -   -   -   -
Fuse VANDC -> VXOR600 600 600 600 600
Fuse VXOR -> VXOR 240 240 120 120 120

Spill vector to stack 364 364 172 184 110
Load spilled vector from stack962 962 713 723 166
Vector moves  100 100  70  72   3,055

Vector shift right696 696 696 696 696
XXLANDC or VANDC  600 600 600 600 600
XXLXOR or VXOR  1,824   1,824   1,824   1,824   1,825

XXSPLTIB and VEXTSB2D to load constants24  24  24  24  24

This means that current trunk and GCC 14 have more vector spills and loads than
GCC 13 and GCC 12.  In addition, they have some more vector moves.

Current trunk and GCC 14-12 have more vector spills than GCC 11, but GCC 11 has
many more vector moves that the other compilers.  Thus even though it has way
less spills, the vector moves are why GCC 11 has the slowest results.

[Bug target/117251] SHA3 code for PowerPC has a major slow down

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

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

--- Comment #6 from Michael Meissner  ---
Note, in the first comment, I mis-read the instruction, and the instruction
being used is vector unsigned long long rotate left, and not vector unsigned
long long shift left.

I.e.:

Trunk   GCC14   GCC13   GCC12   GCC11
-   -   -   -   -
Vector rotate right   696 696 696 696 696

[Bug target/117251] SHA3 code for PowerPC has a major slow down

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

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

--- Comment #5 from Michael Meissner  ---
For the singlebuff.c benchmark, the numbers are:

Trunk  (sources checked out October 5th):5.40 seconds
GCC 14 (sources checked out October 21st):   5.40 seconds
GCC 13 (sources checked out October 21st):   5.35 seconds
GCC 12 (sources checked out October 21st):   5.36 seconds
GCC 11 (sources checked out October 21st):   7.54 seconds

And the instruction summaries are:

Trunk   GCC14   GCC13   GCC12   GCC11
-   -   -   -   -
Fuse VANDC -> VXOR600 600 600 600 600
Fuse VXOR -> VXOR 240 240 120 120 120

Spill vector to stack 379 379 382 382  63
Load spilled vector from stack796 796 757 757  68
Vector moves   80  80 119 119   2,409

Vector rotate right   696 696 696 696 696
XXLANDC or VANDC  600 600 600 600 600
XXLXOR or VXOR  1,824   1,824   1,824   1,824   1,824

XXSPLTIB and VEXTSB2D to load constants96  96  96  96  96

[Bug target/117251] SHA3 code for PowerPC has a major slow down

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

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

--- Comment #4 from Michael Meissner  ---
I tracked down the commit that first made the slowdown visible:

commit 3a61ca1b9256535e1bfb19b2d46cde21f3908a5d (HEAD)
Author: Jan Hubicka 
Date:   Thu Jul 6 18:56:22 2023 +0200

Improve profile updates after loop-ch and cunroll

Extend loop-ch and loop unrolling to fix profile in case the loop is
known to not iterate at all (or iterate few times) while profile claims it
iterates more.  While this is kind of symptomatic fix, it is best we can do
incase profile was originally esitmated incorrectly.

In the testcase the problematic loop is produced by vectorizer and I think
vectorizer should know and account into its costs that vectorizer loop
and/or
epilogue is not going to loop after the transformation.  So it would be
nice
to fix it on that side, too.

The patch avoids about half of profile mismatches caused by cunroll.

Pass dump id and name|static mismatcdynamic mismatch
 |in count |in count
107t cunrolli|  3+3|17251   +17251
115t threadfull  |  3  |14376-2875
116t vrp |  5+2|30908   +16532
117t dse |  5  |30908
118t dce |  3-2|17251   -13657
127t ch  | 13   +10|17251
131t dom | 39   +26|17251
133t isolate-paths   | 47+8|17251
134t reassoc | 49+2|17251
136t forwprop| 53+4|   202501  +185250
159t cddce   | 61+8|   216211   +13710
161t ldist   | 62+1|   216211
172t ifcvt   | 66+4|   373711  +157500
173t vect|143   +77|  9802097 +9428386
176t cunroll |221   +78| 15639591 +5837494
183t loopdone|218-3| 15577640   -61951
195t fre |214-4| 15577640
197t dom |213-1| 16671606 +1093966
199t threadfull  |215+2| 16879581  +207975
200t vrp |217+2| 17077750  +198169
204t dce |215-2| 17004486   -73264
206t sink|213-2| 17004486
211t cddce   |219+6| 17005926+1440
255t optimized   |217-2| 17005926
256r expand  |210-7| 19571573 +2565647
258r into_cfglayout  |208-2| 19571573
275r loop2_unroll|212+4| 22992432 +3420859
291r ce2 |210-2| 23011838
312r pro_and_epilogue|230   +20| 23073776   +61938
315r jump2   |236+6| 27110534 +4036758
323r bbro|229-7| 21826835 -5283699

W/o the patch cunroll does:

176t cunroll |294  +151|126548439   +116746342

and we end up with 291 mismatches at bbro.

Bootstrapped/regtested x86_64-linux. Plan to commit it after the
scale_loop_frequency patch.

gcc/ChangeLog:

PR middle-end/25623
* tree-ssa-loop-ch.cc (ch_base::copy_headers): Scale loop frequency
to maximal number
of iterations determined.
* tree-ssa-loop-ivcanon.cc (try_unroll_loop_completely): Likewise.

gcc/testsuite/ChangeLog:

PR middle-end/25623
* gfortran.dg/pr25623-2.f90: New test.

However, I backed that particular patch back out of the trunk sources, and it
shows similar regressions.

Here is the scale loop patch which was mentioned above, and is the adjacent
patch.  At present, I have not tried backing out this patch:

commit d4c2e34deef8cbd81ba2ef3389fdbaf95c70e225
Author: Jan Hubicka 
Date:   Thu Jul 6 18:51:02 2023 +0200

Improve scale_loop_profile

Original scale_loop_profile was implemented to only handle very simple
loops
produced by vectorizer at that time (basically loops with only one exit and
no
subloops). It also has not been updated to new profile-count API very
carefully.

The function does two thigs
 1) scales down the loop profile by a given probability.
This is useful, for example, to scale down profile after peeling when
loop
body is executed less often than before
 2) update profile to cap iteration count by ITERATION_BOUND parameter.

I changed ITERATION_BOUND to be actual bound on number of iterations as
used elsewhere (i.e.

[Bug tree-optimization/117253] New: [14/15 regression] Generated code at -Os on trunk is larger than GCC 13.3

[dccitaliano at gmail dot com via Gcc-bugs]

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

Bug ID: 117253
   Summary: [14/15 regression] Generated code at -Os on trunk is
larger than GCC 13.3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dccitaliano at gmail dot com
  Target Milestone: ---

https://gcc.godbolt.org/z/cqvMzPd4d

Inline code:

int f(int a) {
  int* ptr = &a;
  int result = *ptr;
  int* arr = new int[10];
  for (int i = 0; i < 10; i++) {
arr[i] = i;
  }
  union Data {
int i;
float f;
  } data;
  for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; j++) {
  if ((i + j) % 3 == 0 && (i * j) % 2 != 0) {
if ((i * j) > 20 && (i + j) < 15) {
  result += i * j;
}
result += i + j;
*ptr += arr[i] + arr[j];
data.i = i + j;
data.f = (float)data.i / 2.0f;
result += data.i;
for (int k = 0; k < 5; k++) {
  if ((k * i) % 4 == 0 && (j * k) % 5 != 0) {
result += k * i * j;
  }
}
  }
}
  }
  delete[] arr;
  return result;
}

This points to:

commit 55fcaa9a8bd9c8ce97ca929fc902c88cf92786a0
Author: Andrew Pinski 
Date:   Wed Jun 7 09:05:15 2023 -0700

Add Plus to the op list of `(zero_one == 0) ? y : z  y` pattern

This adds plus to the op list of `(zero_one == 0) ? y : z  y` patterns
which currently has bit_ior and bit_xor.
This shows up now in GCC after the boolization work that Uroš has been
doing.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/97711
PR tree-optimization/110155

gcc/ChangeLog:

* match.pd ((zero_one == 0) ? y : z  y): Add plus to the op.
((zero_one != 0) ? z  y : y): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/branchless-cond-add-2.c: New test.
* gcc.dg/tree-ssa/branchless-cond-add.c: New test.

 gcc/match.pd  |  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/branchless-cond-add-2.c |  8 
 gcc/testsuite/gcc.dg/tree-ssa/branchless-cond-add.c   | 18 ++
 3 files changed, 28 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/branchless-cond-add-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/branchless-cond-add.c

[Bug target/117253] [14/15 regression] Generated code at -Os on trunk is larger than GCC 13.3

[dccitaliano at gmail dot com via Gcc-bugs]

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

Davide Italiano  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Davide Italiano  ---
(In reply to Andrew Pinski from comment #1)
> aarch64 does NOT show a regression. 
> 
> But basically the issue:
> if ((i * j) > 20 && (i + j) < 15) {
>   result += i * j;
> }
> 
> is converted to result += (i * j) * ((i * j) > 20 && (i + j) < 15).
> 
> And then selects the multiply due to code size and it just goes down hill
> from there.
> 
> This is 100% a synthetic test so I am not sure we are worried about the code
> size increase here for x86_64; especially for x86_64.

Thanks for taking a look Andrew. Not extremely familiar with this code, but I
wonder if the fact this shows a regression only on some arches suggests this
peephole is kind-of target-dependent?

[Bug c/117254] New: ICE: have var_decl in get_len, at tree.h:6512

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 117254
   Summary: ICE: have var_decl in get_len, at tree.h:6512
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC) 

***
Program:
$ cat mutant.c
int g;
char *strncpy();
#define a(b, c, d) strncpy(b, c)
void e() {
  struct {
__attribute__((nonstring)) char bn[g];
  } f;
  a(f, f.bn, );
}

***
Command Lines:
$ gcc mutant.c
mutant.c: In function 'e':
mutant.c:8:5: warning: incompatible type for argument 1 of 'strncpy'
[-Wbuiltin-declaration-mismatch]
8 |   a(f, f.bn, );
  | ^
mutant.c:3:28: note: in definition of macro 'a'
3 | #define a(b, c, d) strncpy(b, c)
  |^
mutant.c:2:7: note: expected 'char *' but argument is of type 'struct
'
2 | char *strncpy();
  |   ^~~
mutant.c:3:20: warning: too few arguments to built-in function 'strncpy'
expecting 3 [-Wbuiltin-declaration-mismatch]
3 | #define a(b, c, d) strncpy(b, c)
  |^~~
mutant.c:8:3: note: in expansion of macro 'a'
8 |   a(f, f.bn, );
  |   ^
mutant.c:2:7: note: declared here
2 | char *strncpy();
  |   ^~~
during GIMPLE pass: waccess
mutant.c:4:6: internal compiler error: tree check: expected integer_cst, have
var_decl in get_len, at tree.h:6503
4 | void e() {
  |  ^
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x2685230 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xd4aa08 tree_check(tree_node const*, char const*, int, char const*, tree_code)
???:0
0x103d6d7 wi::extended_tree<128>::get_len() const
???:0
0x103d4eb wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
???:0
0x103d0c4 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
???:0
0x103c402 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
???:0
0x169187b wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::result_type
wi::add >,
int>(generic_wide_int > const&, int const&)
???:0
0x168f2b2 wi::binary_traits >, int,
wi::int_traits > >::precision_type,
wi::int_traits::precision_type>::operator_result
operator+ >,
int>(generic_wide_int > const&, int const&)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Also ICE on trunk.
Compiler Explorer: https://godbolt.org/z/bn19rjc4o

[Bug target/117253] [14/15 regression] Generated code at -Os on trunk is larger than GCC 13.3

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
Davide, was this reduced from a real application or are you
fuzzing/experimenting? (The reports are welcome either way.)

[Bug target/116959] [15 regression] RISC-V: more ICEs in compute_nregs_for_mode

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

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

--- Comment #3 from Edwin Lu  ---
Marking fixed due to
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1942

[Bug target/116822] [15 regression] RISC-V: ICE in compute_nregs_for_mode, at config/riscv/riscv-vector-costs.cc

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

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

--- Comment #4 from Edwin Lu  ---
Not quite sure how it happened but
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1942 shows the error
has been fixed. Also looking at the previous godbolt
(https://godbolt.org/z/rET13Gr99) no longer shows an ICE

[Bug target/117238] 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

--- Comment #1 from John David Anglin  ---
This is caused by infinite loop in LRA.

We have a problem handling OImode:

(insn 385 384 386 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 20)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 20))
"/home/dave/gnu/gcc/g
cc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42 {*pa.md:2195}
 (nil))
(insn 386 385 387 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 24)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 24))
"/home/dave/gnu/gcc/g
cc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42 {*pa.md:2195}
 (nil))
(insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
(subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
"/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42
{*pa.md:2195}
 (nil))
(insn 35 387 36 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 4)
(mem:SI (plus:SI (reg/f:SI 173)
(const_int 4 [0x4])) [1  S4 A32]))
"/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15 42
{*pa.md:2195}
 (nil))

The insns generated by LRA aren't valid. OImode can't fit in a set of
registers on this target, so the subreg:SI operations shown above can
never be simplified to a general registers.  e has to be in memory.
The pa architecture does not support moving data directly between two
memory locations.

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
I think the right fix is to add a put_noreplace method that asserts internally
and transform incorrect gcc_assert (!...->put(...)) instances to that.

[Bug middle-end/117249] [12/13/14/15 Regression] --disable-checking is broken since r5-2450

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #3)
> I think the right fix is to add a put_noreplace method that asserts
> internally and transform incorrect gcc_assert (!...->put(...)) instances to
> that.

That would be definitely a decent fix. Though since this has been broken for 10
years now, maybe removing the ability to disable assert checking is the better
way forward. I have not audited all gcc_asserts that have been added in the
last 10 years to see if there are other issues that slipped in either.

[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:36e91df7716d34aa5694533837551593ec28f22b

commit r15-4532-g36e91df7716d34aa5694533837551593ec28f22b
Author: Jeff Law 
Date:   Mon Oct 21 13:37:21 2024 -0600

[committed][PR rtl-optimization/116488] Fix SIGN_EXTEND source handling in
ext-dce

A while back I noticed that the code to call carry_backpropagate was being
called after the optimization step.  Which seemed wrong, but at the time I
didn't have a testcase showing it as a problem.  Now I have 4 :-)

The way things used to work, the extension would be stripped away before
calling carry_backpropagte, meaning carry_backpropagate would never see a
SIGN_EXTENSION.  Thus the code trying to account for the sign extended bit
was
never reached.

Getting that bit marked live is what's needed to fix these testcases.
Fallout
is minor with just an adjustment needed to sensibly deal with vector modes
in a
place where we didn't have them before.

I'm still somewhat concerned about this code.  Specifically whether or not
we
can get in here with arbitrarily complex RTL, and if so do we need to
recurse
down and look at those sub-expressions.

So while this patch fixes the most pressing issue, I wouldn't be terribly
surprised if we're back inside this code at some point.

Bootstrapped and regression tested on x86_64, ppc64le, riscv64, s390x,
mips64,
loongarch, aarch64, m68k, alpha, hppa, sh4, sh4eb, perhaps something else
that
I've forgotten...  Also tested on all the crosses in my tester.

PR rtl-optimization/116488
PR rtl-optimization/116579
PR rtl-optimization/116915
PR rtl-optimization/117226
gcc/
* ext-dce.cc (carry_backpropagate): Properly handle SIGN_EXTEND,
add
ZERO_EXTEND handling as well.
(ext_dce_process_uses): Call carry_backpropagate before the
optimization
step.

gcc/testsuite/
* gcc.dg/torture/pr116488.c: New test.
* gcc.dg/torture/pr116579.c: New test.
* gcc.dg/torture/pr116915.c: New test.
* gcc.dg/torture/pr117226.c: New test.

[Bug rtl-optimization/116915] [15 Regression] wrong code at -O{s,2,3} on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:36e91df7716d34aa5694533837551593ec28f22b

commit r15-4532-g36e91df7716d34aa5694533837551593ec28f22b
Author: Jeff Law 
Date:   Mon Oct 21 13:37:21 2024 -0600

[committed][PR rtl-optimization/116488] Fix SIGN_EXTEND source handling in
ext-dce

A while back I noticed that the code to call carry_backpropagate was being
called after the optimization step.  Which seemed wrong, but at the time I
didn't have a testcase showing it as a problem.  Now I have 4 :-)

The way things used to work, the extension would be stripped away before
calling carry_backpropagte, meaning carry_backpropagate would never see a
SIGN_EXTENSION.  Thus the code trying to account for the sign extended bit
was
never reached.

Getting that bit marked live is what's needed to fix these testcases.
Fallout
is minor with just an adjustment needed to sensibly deal with vector modes
in a
place where we didn't have them before.

I'm still somewhat concerned about this code.  Specifically whether or not
we
can get in here with arbitrarily complex RTL, and if so do we need to
recurse
down and look at those sub-expressions.

So while this patch fixes the most pressing issue, I wouldn't be terribly
surprised if we're back inside this code at some point.

Bootstrapped and regression tested on x86_64, ppc64le, riscv64, s390x,
mips64,
loongarch, aarch64, m68k, alpha, hppa, sh4, sh4eb, perhaps something else
that
I've forgotten...  Also tested on all the crosses in my tester.

PR rtl-optimization/116488
PR rtl-optimization/116579
PR rtl-optimization/116915
PR rtl-optimization/117226
gcc/
* ext-dce.cc (carry_backpropagate): Properly handle SIGN_EXTEND,
add
ZERO_EXTEND handling as well.
(ext_dce_process_uses): Call carry_backpropagate before the
optimization
step.

gcc/testsuite/
* gcc.dg/torture/pr116488.c: New test.
* gcc.dg/torture/pr116579.c: New test.
* gcc.dg/torture/pr116915.c: New test.
* gcc.dg/torture/pr117226.c: New test.

[Bug rtl-optimization/117226] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-forwprop" on x86_64-linux-gnu with ext-dce since r15-1901-g98914f9eba5f19

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

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

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

https://gcc.gnu.org/g:36e91df7716d34aa5694533837551593ec28f22b

commit r15-4532-g36e91df7716d34aa5694533837551593ec28f22b
Author: Jeff Law 
Date:   Mon Oct 21 13:37:21 2024 -0600

[committed][PR rtl-optimization/116488] Fix SIGN_EXTEND source handling in
ext-dce

A while back I noticed that the code to call carry_backpropagate was being
called after the optimization step.  Which seemed wrong, but at the time I
didn't have a testcase showing it as a problem.  Now I have 4 :-)

The way things used to work, the extension would be stripped away before
calling carry_backpropagte, meaning carry_backpropagate would never see a
SIGN_EXTENSION.  Thus the code trying to account for the sign extended bit
was
never reached.

Getting that bit marked live is what's needed to fix these testcases.
Fallout
is minor with just an adjustment needed to sensibly deal with vector modes
in a
place where we didn't have them before.

I'm still somewhat concerned about this code.  Specifically whether or not
we
can get in here with arbitrarily complex RTL, and if so do we need to
recurse
down and look at those sub-expressions.

So while this patch fixes the most pressing issue, I wouldn't be terribly
surprised if we're back inside this code at some point.

Bootstrapped and regression tested on x86_64, ppc64le, riscv64, s390x,
mips64,
loongarch, aarch64, m68k, alpha, hppa, sh4, sh4eb, perhaps something else
that
I've forgotten...  Also tested on all the crosses in my tester.

PR rtl-optimization/116488
PR rtl-optimization/116579
PR rtl-optimization/116915
PR rtl-optimization/117226
gcc/
* ext-dce.cc (carry_backpropagate): Properly handle SIGN_EXTEND,
add
ZERO_EXTEND handling as well.
(ext_dce_process_uses): Call carry_backpropagate before the
optimization
step.

gcc/testsuite/
* gcc.dg/torture/pr116488.c: New test.
* gcc.dg/torture/pr116579.c: New test.
* gcc.dg/torture/pr116915.c: New test.
* gcc.dg/torture/pr117226.c: New test.