[Bug rust/119508] Hundreds of rust tests XPASS

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

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #10 from Mark Wielaard  ---
commit 89ca1e3cb697a87f02682a1fb1f62f02d0671c57
Author: Owen Avery 
Date:   Sun Mar 30 19:08:45 2025 -0400

gccrs: nr2.0: Improve test script

gcc/testsuite/ChangeLog:

* rust/compile/nr2/compile.exp: Avoid absolute paths in output,
adjust phrasing of output, and avoid false XPASS output when
tests are run in parallel.

Signed-off-by: Owen Avery 

[Bug other/66300] GCC_ENABLE_PLUGINS references undefined variables, breaking configure

[ossman at cendio dot se via Gcc-bugs]

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

Pierre Ossman  changed:

   What|Removed |Added

Version|5.1.0   |14.2.0

--- Comment #2 from Pierre Ossman  ---
Still an issue, unfortunately.

Happens whenever you cross compile gcc. Which I'm surprised it's not affecting
more people?

[Bug libstdc++/119673] MinGW-w64 GCC with win32 thread model cannot compile 'std' module

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Thanks for the pointer, I'll mimic this fix.

[Bug target/119626] On aarch64, use the bfcvt instruction to cast to __bf16 when target supports it

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #7 from mcccs at gmx dot com ---
Today Microsoft Copilot wrongly quoted what I earlier said (bots are reading
these threads), so I need to fix my mistake for anyone reading this thread:

If you want to allow the compiler to use the bfcvt instruction on Arm, use the
argument -march=armv9.1-a or -march=armv8.6-a or -march=armv[any version]+bf16
not +fp16! FP16 is not BF16

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Ah,
2025-04-08  Jakub Jelinek  

PR rtl-optimization/119672
* simplify-rtx.cc (simplify_context::simplify_relational_operation_1):
For POPCOUNT == 0 or != 0 optimizations use
CONST0_RTX (GET_MODE (XEXP (op0, 0))) rather than const0_rtx.

--- gcc/simplify-rtx.cc.jj  2025-04-07 11:54:49.216910340 +0200
+++ gcc/simplify-rtx.cc 2025-04-08 11:14:53.826293652 +0200
@@ -6465,14 +6465,16 @@ simplify_context::simplify_relational_op
   case LEU:
/* (eq (popcount x) (const_int 0)) -> (eq x (const_int 0)).  */
return simplify_gen_relational (EQ, mode, GET_MODE (XEXP (op0, 0)),
-   XEXP (op0, 0), const0_rtx);
+   XEXP (op0, 0),
+   CONST0_RTX (GET_MODE (XEXP (op0, 0;

   case NE:
   case GT:
   case GTU:
/* (ne (popcount x) (const_int 0)) -> (ne x (const_int 0)).  */
return simplify_gen_relational (NE, mode, GET_MODE (XEXP (op0, 0)),
-   XEXP (op0, 0), const0_rtx);
+   XEXP (op0, 0),
+   CONST0_RTX (GET_MODE (XEXP (op0, 0;

   default:
break;
should fix this.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

--- Comment #5 from Jakub Jelinek  ---
I will test this on aarch64-linux but don't have setup to test it for riscv.

[Bug libgomp/119677] New: [OpenMP][6.1] Support omp_default_device / Cleanup modify_call_for_omp_dispatch via GOMP_DEVICE_DEFAULT_OMP_61

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

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

Bug ID: 119677
   Summary: [OpenMP][6.1] Support omp_default_device / Cleanup
modify_call_for_omp_dispatch via
GOMP_DEVICE_DEFAULT_OMP_61
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 61034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61034&action=edit
Patch that updates modify_call_for_omp_dispatch (+ testcase changes) but no
full libgomp/target.c update

OpenMP 5.2 added omp_initial_device and omp_invalid_device;
OpenMP 6.1/TR14 will add 'omp_default_device'.

Since r15-8654-g99e2906ae255fc, GCC already uses GOMP_DEVICE_DEFAULT_OMP_61
internally.

EXPECTED:

(1) Use GOMP_DEVICE_DEFAULT_OMP_61 internally to avoid 'omp_get_default_device'
call in modify_call_for_omp_dispatch -> See attached patch.

(2) Consider whether it makes sense also with other compiler-generated lib
calls

(3) API routines in libgomp/target.c have special code to handle:

  if (device_num == omp_initial_device 
  || device_num == gomp_get_num_devices ())

which needs to also handle device_num := omp_default_device to avoids
invalid code.

  For instance, it could be replaced by:

if (is_intial_device (&device_num))

with

  static inline bool
  is_initial_device (int &device_num)
{
  if (*device_num == GOMP_DEVICE_DEFAULT_OMP_61)
{ 
  struct gomp_task_icv *icv = gomp_icv (false);
  *device_num = icv->default_device_var;
}
  return (*device_num == omp_initial_device
  || *device_num == omp_get_initial_device ());
}


BTW: Note that omp_set_default_device() ignores omp_default_device
(according to the spec and as implemented). Otherwise, call it would
make it impossible to recover a 'real' device number.

(4) Add omp_default_device to omp.h / omp_lib.
+ add some testcases
+ consider updating the documentation for it, cf. PR119676.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

--- Comment #7 from Jakub Jelinek  ---
Thanks, I've posted it to gcc-patches in case some CI picks it up too:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680408.html

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

Robin Dapp  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org

--- Comment #6 from Robin Dapp  ---
(In reply to Jakub Jelinek from comment #5)
> I will test this on aarch64-linux but don't have setup to test it for riscv.

I'm going to test it.

[Bug target/119675] New: nvptx 'error: PTX does not support weak declarations (only weak definitions)'

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

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

Bug ID: 119675
   Summary: nvptx 'error: PTX does not support weak declarations
(only weak definitions)'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Per Subversion r236990 (Git commit 721547cd0dd19a03a9e9405cfdbd6d0870eaaf68),

"[PTX] weak references", a number of nvptx target test cases fail due to
nvptx-specific 'error: PTX does not support weak declarations (only weak
definitions)'.

The curious thing, though, is that GCN as per commit
2f58d8ac03911063d6a8887a2bee7b4e25ac1871 "GCN: Don't emit weak undefined
symbols [PR119369]" also has issues with weak undefined symbols, and thus has
their support disabled (but without the nvptx-specific error diagnostic cited
above) -- and such test cases PASS, including their execution test.

For example (random), libstdc++
'23_containers/multiset/modifiers/insert/insert_range.cc':

GCN:

PASS: 23_containers/multiset/modifiers/insert/insert_range.cc  -std=gnu++23
(test for excess errors)
PASS: 23_containers/multiset/modifiers/insert/insert_range.cc  -std=gnu++23
execution test

nvptx:

In file included from
[...]/build-gcc/nvptx-none/libstdc++-v3/include/algorithm:65,
 from
[...]/source-gcc/libstdc++-v3/testsuite/23_containers/multiset/modifiers/insert/insert_range.cc:3:
[...]/build-gcc/nvptx-none/libstdc++-v3/include/bits/ranges_algo.h:1838:
error: PTX does not support weak declarations (only weak definitions)
[...]
FAIL: 23_containers/multiset/modifiers/insert/insert_range.cc  -std=gnu++23
(test for excess errors)

..., which points to 'source-gcc/libstdc++-v3/include/bits/ranges_algo.h':

[...]
  42 #if __glibcxx_concepts
  43 namespace std _GLIBCXX_VISIBILITY(default)
  44 {
  45 _GLIBCXX_BEGIN_NAMESPACE_VERSION
  46 namespace ranges
  47 {
[...]
1838   inline constexpr __sort_fn sort{};
[...]

What is GCN doing differently, and could nvptx do similarly?

[Bug target/119617] ICE: in standard_sse_constant_opcode, at config/i386/i386.cc:5465 with -fzero-call-used-regs=all -mabi=ms -mavx512f -mno-evex512

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #7 from Haochen Jiang  ---
The problem is under msabi, -fzero-call-used-regs=all will also try to clear
xmm16+. However, under -mavx512f -mno-evex512, we have no instructions to do
that.

There are two solutions for that:

1. Reject mno-evex512 since GCC 15.
or
2. When using vpxor* in standard_sse_constant_opcode, do not check
TARGET_EVEX512 and emit zmm instructions even under "-mavx512f -mno-evex512"
since there will be no hardware fails on that.

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords||ice-on-valid-code

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-08
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jakub Jelinek  ---
Slightly reduced: -march=rv32gcv -mabi=ilp32d -O2 -fvect-cost-model=unlimited
unsigned char a;

int
foo (void)
{
  short b = 0;
  for (short a = 0; a != 19; a++)
if (a)
  b = 32872 >> a;
  return b;
}

[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Created attachment 61033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61033&action=edit
Rewrite atomic builtin checks

[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |16.0

[Bug rust/119508] Hundreds of rust tests XPASS

[pierre-emmanuel.patry at embecosm dot com via Gcc-bugs]

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

--- Comment #7 from Pierre-Emmanuel Patry  ---
89ca1e3cb697a87f02682a1fb1f62f02d0671c57 Should have fixed this.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

--- Comment #3 from Jakub Jelinek  ---
The ICE is on trying to optimize MINUS of
(unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
and
(const_int 0 [0])
with mode E_RVVMF32BImode.
poly_int_rtx_p (op1) is true, so it feels like all the requirements of
neg_poly_int_rtx:
/* Negate I, which satisfies poly_int_rtx_p.  MODE is the mode of I.  */
are met.
  /* Don't let a relocatable value get a negative coeff.  */
  if (poly_int_rtx_p (op1) && GET_MODE (op0) != VOIDmode)
return simplify_gen_binary (PLUS, mode,
op0,
neg_poly_int_rtx (mode, op1));
But wi::to_poly_wide that neg_poly_int_rtx uses handles vector modes if it is
passed CONST_POLY_INT and for CONST_INT just assumes the mode must be scalar
mode (which is not the case here).

[Bug libgomp/119676] New: [OpenMP] Move constant/kind/type documentation from gfortran to libgomp.texi + update/add C/C++

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

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

Bug ID: 119676
   Summary: [OpenMP] Move constant/kind/type documentation from
gfortran to libgomp.texi + update/add C/C++
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: documentation, openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, sandra at gcc dot gnu.org
  Target Milestone: ---

Fortran documents the intrinsic modules; this includes OpenMP and OpenACC;
however the latter are mostly documented in libgomp.texi.

Therefore, the Fortran documentation is only about parameters/named constants
to be used as value or as kind parameter and derived types.

→
https://gcc.gnu.org/onlinedocs/gfortran/OpenMP-Modules-OMP_005fLIB-and-OMP_005fLIB_005fKINDS.html

It makes much more sense to move the actual doumentation to libgomp.texi /
https://gcc.gnu.org/onlinedocs/libgomp/ and only leave the (slightly reworded)
cross ref to libgomp.texi.

Besides moving, the list needs to be updated (not up to date) and also updated
for C/C++.

Presumably, we want to follow OpenMP and add a new section "Runtime Library
Definitions" under libgomp.texi's existing "OpenMP Runtime Library Routines"
chapter.

[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"

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

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

--- Comment #8 from Jonathan Wakely  ---
Peter Dimov pointed out an even simpler example of valid-but-questionable code:

std::unique_ptr p(new int);
p.reset(p.get());
(void) p.release();

The pointer is invalidated by the self-reset, but then is released and so the
invalid pointer is never used.

He also noted that we can add a self-reset check to std::shared_ptr, because
its constructor (and therefore also reset) has a precondition that 'delete p'
is well-formed. There's no such precondition for std::unique_ptr.

[Bug target/119678] New: FreeBSD RISC-V broken due to single-char typo in macro FBSD_LINK_PG_NOTES

[mcccs at gmx dot com via Gcc-bugs]

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

Bug ID: 119678
   Summary: FreeBSD RISC-V broken due to single-char typo in macro
FBSD_LINK_PG_NOTES
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/pull/108 has found out that the commit

https://github.com/gcc-mirror/gcc/commit/48abb540701447b0cd9df7542720ab65a34fc1b1

has a typo that

gcc/config/riscv/freebsd.h

refers to

FBSD_LINK_PG_NOTES, which is undefined

instead of

FBSD_LINK_PG_NOTE

[Bug target/119678] [15 regression] FreeBSD RISC-V broken due to single-char typo in macro FBSD_LINK_PG_NOTES since r15-1124-g48abb540701447

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||build
Summary|FreeBSD RISC-V broken due   |[15 regression] FreeBSD
   |to single-char typo in  |RISC-V broken due to
   |macro FBSD_LINK_PG_NOTES|single-char typo in macro
   ||FBSD_LINK_PG_NOTES since
   ||r15-1124-g48abb540701447
 CC||andreast at gcc dot gnu.org,
   ||gerald at pfeifer dot com
   Target Milestone|--- |15.0

--- Comment #1 from Sam James  ---
r15-1124-g48abb540701447

[Bug rust/119508] Hundreds of rust tests XPASS

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

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

--- Comment #8 from Thomas Schwinge  ---
GCC/Rust master branch commit b9aaa6192f3310a0cb26f7773b31703a8c9c544c "nr2.0:
Improve test script" you mean?  Yes, likely -- but that's not yet in upstream
GCC.

[Bug rust/119508] Hundreds of rust tests XPASS

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

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

--- Comment #9 from Sam James  ---
It is, as r15-9287-g89ca1e3cb697a8.

[Bug target/119664] [15 regression] ICE compiling Linux with h8300-linux compiler

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Summary|ICE compiling Linux with|[15 regression] ICE
   |h8300-linux compiler|compiling Linux with
   ||h8300-linux compiler

[Bug target/119664] ICE compiling Linux with h8300-linux compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce. 15.0.1 20250406 ICEs, 14.2.0 works.

[Bug lto/119625] lto1: fatal error: open failed: No such file or directory

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

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

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

https://gcc.gnu.org/g:15baa0055601a00b77e2e0ed6259bbc9e5ea5fa9

commit r15-9306-g15baa0055601a00b77e2e0ed6259bbc9e5ea5fa9
Author: Jakub Jelinek 
Date:   Tue Apr 8 11:53:34 2025 +0200

lto: Add & ~CF_SET into lto-opts.cc [PR119625]

The following patch uses & ~CF_SET so that we get the -fcf-protection=
options into .gnu.lto_.opts section even when it has CF_SET bit set.

2025-04-08  Jakub Jelinek  

PR lto/119625
* lto-opts.cc (lto_write_options): Mask of CF_SET from
global_options.x_flag_cf_protection.

[Bug c/119679] New: [RISC-V] Compiler adds and removes stack to functions even when not needed

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

Bug ID: 119679
   Summary: [RISC-V] Compiler adds and removes stack to functions
even when not needed
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.romano at gmail dot com
  Target Milestone: ---

This C code:

typedef struct {
  unsigned long one;
  unsigned long two;
} twin;

twin function( twin t ) {
  return (twin){ 0,0 };
}

results in this assembly file:

.file   "p.c"
.option nopic
.attribute arch,
"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align  1
.globl  function
.type   function, @function
function:
addisp,sp,-32
li  a0,0
li  a1,0
addisp,sp,32
jr  ra
.size   function, .-function
.ident  "GCC: (g04696df09) 14.2.0"
.section.note.GNU-stack,"",@progbits

when passed through "riscv64-unknown-elf-gcc (g04696df09) 14.2.0" with "-O",
"-O2", "-O3" and "-Os" optimization options.

The generated code just uses "a0" and "a1" registers and needs no local stack
("sp") inside the function body.

So those two instructions on "sp" register are pretty useless nd get generated
also with "-fomit-frame-pointer" option.

As a comparison, clang v20.1.0 works in an expected way.

You can check this also on GodBolt:

https://godbolt.org/z/11Gedzn4Y

[Bug rtl-optimization/119594] [15 regression] wrong code at -Os with "-fno-dce -fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu since r15-1575

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/119664] [15 regression] ICE compiling Linux with h8300-linux compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
It's enough to compile with: -std=gnu89 -Os -fno-omit-frame-pointer.
Using -O2 or dropping -fno-omit-frame-pointer hides the issue.

[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug libstdc++/119671] Use-after-free for formatting floating-point types to wide strings

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

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

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

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

commit r15-9273-ge33b62eed7fd0a82d758b23252d288585b6790d2
Author: Jonathan Wakely 
Date:   Mon Apr 7 19:52:55 2025 +0100

libstdc++: Fix use-after-free in std::format [PR119671]

When formatting floating-point values to wide strings there's a case
where we invalidate a std::wstring buffer while a std::wstring_view is
still referring to it.

libstdc++-v3/ChangeLog:

PR libstdc++/119671
* include/std/format (__formatter_fp::format): Do not invalidate
__wstr unless _M_localized returns a valid string.
* testsuite/std/format/functions/format.cc: Check wide string
formatting of floating-point types with classic locale.

Reviewed-by: Tomasz Kaminski 

[Bug libstdc++/119673] MinGW-w64 GCC with win32 thread model cannot compile 'std' module

[c at cyano dot cn via Gcc-bugs]

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

--- Comment #1 from Cyano Hao  ---
Command to compile std module:

```
Z:\tmp\test\mingw64-win32-15\mingw64-win32-15\bin\x86_64-w64-mingw32-g++ -c
-m64 -fvisibility=hidden -fvisibility-inlines-hidden -O3 -std=c++23
-fmodules-ts -D_GLIBCXX_USE_CXX11_ABI=1 -DNDEBUG
-fmodule-mapper=C:\users\cyano\Temp\.xmake\250408\c++23\import-std\Z:\tmp\test\mingw64-win32-15\mingw64-win32-15\bin\..\lib
```

[Bug libstdc++/119667] libstdc++ configure checks for libbacktrace need atomics for void* and size_t

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-04-08
 CC||tschwinge at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Thomas Schwinge  ---
Right, I'd noticed that, too, in context of PR119645 (GCN, nvptx: libstdc++
'checking for atomic builtins [...]... no') -- where we don't support
libbacktrace anyway.

(In reply to Jonathan Wakely from comment #0)
> presumably [...] it's only checking
> if the compiler is new enough to support __atomic_ builtins at all. But for
> libstdc++ we actually care about whether the builtins are supported
> natively, and we don't want to use them if they're relying on libatomic.

If it isn't already, it would seem good to document the rationale for that
requirement.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug other/66300] GCC_ENABLE_PLUGINS references undefined variables, breaking configure

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/20250228165012.3862219-1-l.stelm...@samsung.com/

[Bug target/119298] [15 Regression] 538.imagick_r is faster when compiled with GCC 14.2 and -Ofast -flto -march=native than with master on Zen5 since r15-3441-g4292297a0f938f

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

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-08
 Ever confirmed|0   |1

--- Comment #5 from Martin Jambor  ---
This is likely a store-to-load-forwarding stall issue.  I have tracked
it down to two SLP1 transformations - dumps below.

Even though MeanShiftImage receives 10% more samples, its assembly is
the same and the transformations slowing things down happens in
GetVirtualPixelsFromNexus (which is being called from the hottest loop
of MeanShiftImage).

I have verified that the same slow-down happens with
-flto-partition=one and then used option
-fdbg-cnt=vect_slp:1-1043:1046-10 (using unpatched master revision
337b9ff4854) to avoid the two SLP vectorizations and confirmed the
run-time performance has been restored.

The two SLP1 transformations are reported to take place at
magick/cache.c:2573 but that is where the function
GetVirtualPixelsFromNexus begins.  Looking at dumps with -lineno, the
vectorized statements are followed immediately by one from
magick/random.c:629 (load of the normalize field at the end of
function GetPseudoRandomValue).

The SLP1 transformations are:

---
/home/mjambor/gcc/benchmarks/cpu2017/benchspec/CPU/538.imagick_r/build/build_peak_trunk-lto-nat-m64./gvpfn/imagick_r.ltrans1.ltrans.188t.slp1
  2025-04-07 23:28:47.568570350 +0200
+++ gvpfn/imagick_r.ltrans1.ltrans.188t.slp12025-04-07 23:28:50.673570142
+0200
@@ -3897,54 +3899,10 @@
 magick/cache.c:2699:7: note: created &virtual_pixel
 magick/cache.c:2699:7: note: add new stmt: MEM 
[(short unsigned int *)&virtual_pixel] = { 0, 0, 0, 65535 };
 magick/cache.c:2699:7: note: vectorizing stmts using SLP.
-magick/cache.c:2573:33: optimized: basic block part vectorized using 32 byte
vectors
-magick/cache.c:2573:33: note: Vectorizing SLP tree:
-magick/cache.c:2573:33: note: node 0x3648860 (max_nunits=4, refcnt=1)
vector(4) long unsigned int
-magick/cache.c:2573:33: note: op template: MEM[(long unsigned int
*)prephitmp_900 + 32B] = _929;
-magick/cache.c:2573:33: note:  stmt 0 MEM[(long unsigned int *)prephitmp_900 +
32B] = _929;
-magick/cache.c:2573:33: note:  stmt 1 MEM[(long unsigned int *)prephitmp_900 +
40B] = D__lsm.193_931;
-magick/cache.c:2573:33: note:  stmt 2 MEM[(long unsigned int *)prephitmp_900 +
48B] = D__lsm.194_932;
-magick/cache.c:2573:33: note:  stmt 3 MEM[(long unsigned int *)prephitmp_900 +
56B] = D__lsm.195_930;
-magick/cache.c:2573:33: note:  children 0x3648a10
-magick/cache.c:2573:33: note: node (external) 0x3648a10 (max_nunits=1,
refcnt=1) vector(4) long unsigned int
-magick/cache.c:2573:33: note:  { _929, D__lsm.193_931, D__lsm.194_932,
D__lsm.195_930 }
-magick/cache.c:2573:33: note: -->vectorizing SLP node starting from:
MEM[(long unsigned int *)prephitmp_900 + 32B] = _929;
-magick/cache.c:2573:33: note: vect_is_simple_use: operand D__lsm.193_931 = PHI
, type of def: internal
-magick/cache.c:2573:33: note: vect_is_simple_use: operand D__lsm.194_932 = PHI
, type of def: internal
-magick/cache.c:2573:33: note: vect_is_simple_use: operand D__lsm.195_930 = PHI
, type of def: internal
-magick/cache.c:2573:33: note: transform store. ncopies = 1
-magick/cache.c:2573:33: note: create vector_type-pointer variable to type:
vector(4) long unsigned int  vectorizing a pointer ref: MEM[(long unsigned int
*)prephitmp_900 + 32B]
-magick/cache.c:2573:33: note: created vectp.214_881
-magick/cache.c:2573:33: note: add new stmt: MEM 
[(long unsigned int *)vectp.214_881] = _882;
-magick/cache.c:2573:33: note: vectorizing stmts using SLP.
-magick/cache.c:2573:33: optimized: basic block part vectorized using 32 byte
vectors
-magick/cache.c:2573:33: note: Vectorizing SLP tree:
-magick/cache.c:2573:33: note: node 0x3648aa0 (max_nunits=4, refcnt=1)
vector(4) long unsigned int
-magick/cache.c:2573:33: note: op template: MEM[(long unsigned int
*)prephitmp_900 + 32B] = _552;
-magick/cache.c:2573:33: note:  stmt 0 MEM[(long unsigned int *)prephitmp_900 +
32B] = _552;
-magick/cache.c:2573:33: note:  stmt 1 MEM[(long unsigned int *)prephitmp_900 +
40B] = D__lsm.189_606;
-magick/cache.c:2573:33: note:  stmt 2 MEM[(long unsigned int *)prephitmp_900 +
48B] = D__lsm.190_568;
-magick/cache.c:2573:33: note:  stmt 3 MEM[(long unsigned int *)prephitmp_900 +
56B] = D__lsm.191_342;
-magick/cache.c:2573:33: note:  children 0x3648c50
-magick/cache.c:2573:33: note: node (external) 0x3648c50 (max_nunits=1,
refcnt=1) vector(4) long unsigned int
-magick/cache.c:2573:33: note:  { _552, D__lsm.189_606, D__lsm.190_568,
D__lsm.191_342 }
-magick/cache.c:2573:33: note: -->vectorizing SLP node starting from:
MEM[(long unsigned int *)prephitmp_900 + 32B] = _552;
-magick/cache.c:2573:33: note: vect_is_simple_use: operand D__lsm.189_606 = PHI
, type of

[Bug middle-end/119679] [RISC-V] Compiler adds and removes stack to functions even when not needed

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

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

--- Comment #1 from Andrew Pinski  ---
I am suspect there is a dup of this.

[Bug target/119678] [15 regression] FreeBSD RISC-V broken due to single-char typo referring to macro FBSD_LINK_PG_NOTE since r15-1124-g48abb540701447

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

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

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

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

commit r15-9312-gf53c5cde64770d6c175737a50fea81feba80
Author: Jakub Jelinek 
Date:   Tue Apr 8 12:39:16 2025 +0200

riscv: Fix a typo in config/riscv/freebsd.h [PR119678]

The r15-1124 commit had a typo in one of the FBSD_LINK_PG_NOTE
macro uses.

Fixed thusly, tested with
../configure --target riscv64-unknown-freebsd14 --disable-bootstrap
--enable-languages=c --disable-libsanitizer --disable-libgomp
make -j32
Before it failed while compiling gcc.cc:
In file included from ./tm.h:44,
 from ../../gcc/gcc.cc:35:
../../gcc/config/riscv/freebsd.h:45:5: error: expected â,â or â;â
before âFBSD_LINK_PG_NOTESâ
   45 |   " FBSD_LINK_PG_NOTES "   
\
  | ^~
../../gcc/gcc.cc:1211:32: note: in expansion of macro âLINK_SPECâ
Now it fails later on during libgcc configury because I don't have
corresponding binutils.

2025-04-08  Jakub Jelinek  

PR target/119678
* config/riscv/freebsd.h (LINK_SPEC): Use FBSD_LINK_PG_NOTE rather
than non-existing FBSD_LINK_PG_NOTES.

[Bug target/119678] [15 regression] FreeBSD RISC-V broken due to single-char typo referring to macro FBSD_LINK_PG_NOTE since r15-1124-g48abb540701447

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

[Bug target/119664] [15 regression] ICE compiling Linux with h8300-linux compiler

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikael Pettersson  ---
Maybe it's moot given Jakub's observation, but git bisect identified

9d20529d94b23275885f380d155fe8671ab5353a is the first new commit
commit 9d20529d94b23275885f380d155fe8671ab5353a (HEAD)
Author: Richard Sandiford 
Date:   Wed Jul 10 17:01:29 2024 +0100

recog: Handle some mode-changing hardreg propagations

as the starting-point of the ICE.

[Bug middle-end/119679] [RISC-V] Compiler adds and removes stack to functions even when not needed with a return of struct with 2 unsigned long

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug rtl-optimization/119681] extraneous move instructions when unrolling core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|Aarch64 |Aarch64 x86_64
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Keywords||ra
   Last reconfirmed||2025-04-08
Summary|extraneous move |extraneous move
   |instructions when unrolling |instructions when unrolling
   |core_list_reverse () with   |core_list_reverse () with
   |-O3 -funroll-all-loops  |-O3 -funroll-all-loops; not
   ||copying the return block
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
To some extent this is a RA issue and about range splitting. In this case we
have an exit to this location:
```
(insn 23 18 24 7 (set (reg/i:DI 0 x0)
(reg/v/f:DI 104 [ list ])) "/app/example.c":29:1 70 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg/v/f:DI 104 [ list ])
(nil)))
(insn 24 23 59 7 (use (reg/i:DI 0 x0)) "/app/example.c":29:1 -1
 (nil))
  ; pc falls through to BB 1
```
;; BB 1 is the exit block

If we had copied this block a few times and split/renamed 104 in the others it
the RA would do its job. The question comes how to detect this and do that
without copying too much? I am not 100% sure copying that bb 3x times is always
the right thing to do.

And as I mentioned this depends on the micro-architecture of which way is
better.

You see the same behavior on x86_64 too but the micro-architecture of most
x86_64 is that the move is free so there is no need to hide the latency
anyways. Though it does increase the number of instructions inside the inner
loop which could cause to go across 2 icache blocks which might be where the
slow down is rather than anything else.

I also not so sure this optimization applies in general or just for coremarks.
Plus inlining core_list_reverse might allow for the moves to go away in general
since it is not constrained to using the return register which is the biggest
constraint here.

[Bug rtl-optimization/119681] extraneous move instructions when unrolling core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

[artemiy at synopsys dot com via Gcc-bugs]

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

--- Comment #3 from Artemiy Volkov  ---
(In reply to Andrew Pinski from comment #1)
> > Under certain conditions
> 
> Yes it depends on the micro-arch . In many new ones the rename (move) is
> free as long as there are enough rename registers.
> 
> 
> Which core are you testing with?

The (draft) patch that I have was originally conceived to be useful for a very
small RISC-V core with load latency = 1, where the removal of these moves is
beneficial, but I'm observing a 0.5% improvement for Coremark (compiled with
-O2 -funroll-all-loops) even on a Cortex-A53.

[Bug rtl-optimization/119681] extraneous move instructions when unrolling core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

[artemiy at synopsys dot com via Gcc-bugs]

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

--- Comment #4 from Artemiy Volkov  ---
Created attachment 61036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61036&action=edit
patch v0.1

[Bug rtl-optimization/119681] extraneous move instructions when unrolling core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|Aarch64 x86_64  |Aarch64 x86_64 riscv

--- Comment #5 from Andrew Pinski  ---
(In reply to Artemiy Volkov from comment #3)
> The (draft) patch that I have was originally conceived to be useful for a
> very small RISC-V core with load latency = 1, where the removal of these
> moves is beneficial, but I'm observing a 0.5% improvement for Coremark
> (compiled with -O2 -funroll-all-loops) even on a Cortex-A53.

Oh I see this is not a big core. Even the successor of a53 cores have this kind
of rename for free. 

Do you have benchmarks besides coremarks? Like say for spec 2017 or the
original eembc benchmarks? How much is the compile time increase?
Does this pattern show up in other locations besides coremarks?

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/119662] [OpenMP] Wrong-code for 'omp dispatch' with append_args clause and unhelpful debug line location

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
FIXED.

For some semi-related cleanup in modify_call_for_omp_dispatch (replace
omp_get_default_device() call by using the omp_default_device constant), see PR
119677

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

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

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

--- Comment #13 from Jakub Jelinek  ---
The "incremental" patch turned out to be mostly independent from the other
(except for both touching adjacent lines in one spot), and Richi has acked that
one, so I've committed it now.  The earlier patch still needs to be reviewed
and I'll work on the remaining part and then perhaps try to compare *.s files
from all the compilations to see if they are identical.

[Bug rtl-optimization/119681] New: extraneous move instructions when unrolling core_list_reverse ()

[artemiy at synopsys dot com via Gcc-bugs]

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

Bug ID: 119681
   Summary: extraneous move instructions when unrolling
core_list_reverse ()
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: artemiy at synopsys dot com
  Target Milestone: ---

When unrolling the core_list_reverse () loop from Coremark (with an unroll
pragma):

list_head *
core_list_reverse(list_head *list)
{
list_head *next = 0, *tmp;
#pragma GCC unroll 4
while (list)
{
tmp= list->next;
list->next = next;
next   = list;
list   = tmp;
}
return next;
}

gcc (15 or any version) doesn't split the variable 'next', causing a move to x0
at every iteration:

core_list_reverse:
cbz x0, .L2
ldr x1, [x0]
mov x6, 0
str x6, [x0]
mov x3, x0
cbz x1, .L2
.L4:
ldr x2, [x1]
str x3, [x1]
mov x0, x1
cbz x2, .L2
ldr x4, [x2]
str x1, [x2]
mov x0, x2
cbz x4, .L2
ldr x5, [x4]
str x2, [x4]
mov x0, x4
mov x6, x4
cbz x5, .L2
mov x0, x5
mov x3, x0
ldr x1, [x0]
str x6, [x0]
cbnzx1, .L4
.L2:
ret

LLVM behavior, for comparison:

core_list_reverse:
cbz x0, .LBB0_6
mov x8, x0
mov x0, xzr
.LBB0_2:
ldr x10, [x8]
str x0, [x8]
cbz x10, .LBB0_7
ldr x9, [x10]
str x8, [x10]
cbz x9, .LBB0_8
ldr x0, [x9]
str x10, [x9]
cbz x0, .LBB0_9
ldr x8, [x0]
str x9, [x0]
cbnzx8, .LBB0_2
.LBB0_6:
ret
.LBB0_7:
mov x0, x8
ret
.LBB0_8:
mov x0, x10
ret
.LBB0_9:
mov x0, x9
ret

Under certain conditions (the load doesn't fully hide the latency of the mov,
the loop is executed a sufficient number of times, etc.), the version with
multiple exits is faster.

godbolt for convenience: https://godbolt.org/z/W965qqWKe

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/home/art/install/aarch64-gcc/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/art/install/aarch64-gcc/libexec/gcc/aarch64-unknown-linux-gnu/15.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../../src/gcc/configure --enable-checking --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/art/install/aarch64-gcc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250408 (experimental) (GCC)

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

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

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

--- Comment #15 from Jakub Jelinek  ---
Note, the above was clearly problematic also in native cobol1, because it emits
random garbage from compiler memory into the binaries and decides on whether it
is same exception as previously based on the random garbage (host structure
padding).

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

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

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

--- Comment #14 from Jakub Jelinek  ---
--- gcc/cobol/structs.h.jj  2025-03-28 20:34:01.659747026 +0100
+++ gcc/cobol/structs.h 2025-04-08 16:20:56.436127535 +0200
@@ -54,6 +54,7 @@ extern GTY(()) tree cblc_field_p_type_no
 extern GTY(()) tree cblc_field_pp_type_node;
 extern GTY(()) tree cblc_file_type_node;
 extern GTY(()) tree cblc_file_p_type_node;
+extern GTY(()) tree cbl_enabled_exception_type_node;
 extern GTY(()) tree cblc_goto_type_node;

 extern void create_our_type_nodes();
--- gcc/cobol/structs.cc.jj 2025-04-07 21:10:11.385496862 +0200
+++ gcc/cobol/structs.cc2025-04-08 16:21:34.775594364 +0200
@@ -156,6 +156,7 @@ tree cblc_field_p_type_node;
 tree cblc_field_pp_type_node;
 tree cblc_file_type_node;
 tree cblc_file_p_type_node;
+tree cbl_enabled_exception_type_node;
 tree cblc_goto_type_node;

 // The following functions return type_decl nodes for the various structures
@@ -285,6 +286,29 @@ typedef struct cblc_file_t
 return retval;
 }

+static tree
+create_cbl_enabled_exception_t()
+{
+/*
+struct cbl_enabled_exception_t
+{
+bool enabled, location;
+ec_type_t ec;
+size_t file;
+};
+*/
+tree retval = NULL_TREE;
+retval = gg_get_filelevel_struct_type_decl( "cbl_enabled_exception_t",
+4,
+BOOL,   "enabled",
+BOOL,   "location",
+UINT,   "ec",
+SIZE_T, "file");
+retval = TREE_TYPE(retval);
+
+return retval;
+}
+
 void
 create_our_type_nodes()
 {
@@ -297,6 +321,7 @@ create_our_type_nodes()
 cblc_field_pp_type_node   =
build_pointer_type(cblc_field_p_type_node);
 cblc_file_type_node   = create_cblc_file_t();
 cblc_file_p_type_node =
build_pointer_type(cblc_file_type_node);
+cbl_enabled_exception_type_node   = create_cbl_enabled_exception_t();
 }
 }

--- gcc/cobol/genapi.cc.jj  2025-04-07 21:10:24.645312313 +0200
+++ gcc/cobol/genapi.cc 2025-04-08 18:20:55.691518519 +0200
@@ -13295,24 +13295,29 @@ static void
 stash_exceptions( const cbl_enabled_exceptions_array_t *enabled )
   {
   // We need to create a static array of bytes
-  size_t narg = enabled->nbytes();
-  unsigned char *p = (unsigned char *)(enabled->ecs);
-
-  static size_t prior_narg = 0;
-  static size_t max_narg   = 128;
-  static unsigned char *prior_p = (unsigned char *)xmalloc(max_narg);
+  size_t nec = enabled->nec;
+  size_t sz = int_size_in_bytes(cbl_enabled_exception_type_node);
+  size_t narg = nec * sz;
+  cbl_enabled_exception_t *p = enabled->ecs;
+
+  static size_t prior_nec = 0;
+  static size_t max_nec   = 0;
+  static cbl_enabled_exception_t *prior_p;

   bool we_got_new_data = false;
-  if( prior_narg != narg )
+  if( prior_nec != nec )
 {
 we_got_new_data = true;
 }
   else
 {
-// The narg counts are the same.
-for(size_t i=0; i max_narg )
+  if( nec > max_nec )
 {
-max_narg = narg;
-prior_p = (unsigned char *)xrealloc(prior_p, max_narg);
+max_nec = nec;
+prior_p = (cbl_enabled_exception_t *)
+  xrealloc(prior_p, max_nec * sizeof(cbl_enabled_exception_t));
 }

-  memcpy(prior_p, p, narg);
+  memcpy((unsigned char *)prior_p, (unsigned char *)p,
+ nec * sizeof(cbl_enabled_exception_t));

   static int count = 1;

@@ -13349,12 +13356,33 @@ stash_exceptions( const cbl_enabled_exce
 TREE_TYPE(constr) = array_of_chars_type;
 TREE_STATIC(constr)= 1;
 TREE_CONSTANT(constr)  = 1;
+unsigned char *q = XALLOCAVEC(unsigned char, sz);

-for(size_t i=0; i 64-bit cobol1 down to a single variable from many.
Now on to the last one.

[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO

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

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

--- Comment #24 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:659e222b82c41ae0730a0bb93d891864b6ae5e16

commit r13-9497-g659e222b82c41ae0730a0bb93d891864b6ae5e16
Author: Martin Jambor 
Date:   Fri Mar 7 17:17:24 2025 +0100

ipa-cp: Avoid ICE when redistributing nodes among edges to recursive clones
(PR 118318)

PR 118318 reported an ICE during PGO build of Firefox when IPA-CP, in
the final stages of update_counts_for_self_gen_clones where it
attempts to guess how to distribute profile count among clones created
for recursive edges and the various edges that are created in the
process.  If one such edge has profile count of kind GUESSED_GLOBAL0,
the compatibility check in the operator+ will lead to an ICE.  After
discussing the situation with Honza, we concluded that there is little
more we can do other than check for this situation before touching the
edge count, so this is what this patch does.

gcc/ChangeLog:

2025-02-28  Martin Jambor  

PR ipa/118318
* ipa-cp.cc (adjust_clone_incoming_counts): Add a compatible_p
check.

(cherry picked from commit 7deb498425799aceb7659ea25614175a49533184)

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #13 from Patrick Palka  ---
If we strengthen the comment #6 testcase with

@@ -6,4 +6,4 @@ concept tt = ;
 template  typename U>
 concept is_specialization_of = tt;
 template  concept is_foo = is_specialization_of;
-auto ttt =  is_foo> ;
+static_assert(!is_foo>);

then GCC >= 14 ICEs, and GCC < 14 incorrectly reject, exhibiting no real
regression.

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #12 from Patrick Palka  ---
(In reply to Jason Merrill from comment #11)
> (In reply to Patrick Palka from comment #8)
> > Started with r14-9938, though I bet before this commit it only accidentally
> > worked.
> 
> This failure does seem to be strongly connected to that commit.
Note that we rejected the unreduced testcase before that commit, which is why I
suspect this situation only accidentally/narrowly worked.
> 
> When normalizing is_foo for , we get to normalizing tt
> for , which means substituting  into .
> 
> Since r14-9938, because in_template_context is false we return the lambda
> unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure type still
> refers to the is_specialization_of tparms in its CLASSTYPE_TEMPLATE_INFO.
> 
> The first failure comes in normalization caching find_template_parameters
> walking over the parameter mapping; any_template_parm_r walks into the
> TREE_TYPE of a LAMBDA_EXPR without considering EXTRA_ARGS and finds a
> template parm from the wrong parameter list.
> 
> If I prevent that by skipping caching of lambdas, I then hit another crash
> in tsubst_lambda_expr during satisfaction, because add_extra_args expects
> dependent EXTRA_ARGS to have been set with tf_partial, but the earlier
> substitution correctly wasn't tf_partial, so the expectation is violated.
Substituting  into  seems like a partial substitution
to me.  If the lambda itself had any template parameters of its own, or autos,
we wouldn't want to reduce their level, so it seems tf_partial should be set
during normalization?
> 
> It seems to me that the underlying issue is the "in_template_context is
> false"; we're normalizing a concept, that is a template context.  So I guess
> normalize_concept_definition needs to set current_template_parms.
Makes sense to me, that sounds like it'd be sufficient to restore the behavior
before that commit. I wonder if it'd be enough to also accept the original
testcase.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

--- Comment #8 from Robin Dapp  ---
(In reply to Jakub Jelinek from comment #7)
> Thanks, I've posted it to gcc-patches in case some CI picks it up too:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680408.html

Testing looked good on rv64gcv_zvl512b (no bootstrap).  Actually the CI should
be picking it up if "riscv" is found anywhere in the mail body but at least in
patchwork it doesn't appear:

https://patchwork.sourceware.org/project/gcc/list/?q=riscv

[Bug middle-end/119662] [OpenMP] Wrong-code for 'omp dispatch' with append_args clause and unhelpful debug line location

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:0f77d88fdf797842ac0134a4013b4227dd5a658f

commit r15-9314-g0f77d88fdf797842ac0134a4013b4227dd5a658f
Author: Tobias Burnus 
Date:   Tue Apr 8 13:47:53 2025 +0200

OpenMP: Fix append_args handling in modify_call_for_omp_dispatch

At tree level, the addr ref is also required for array dummy arguments,
contrary to C; the GOMP_interop calls in modify_call_for_omp_dispatch
were updated accordingly (using build_fold_addr_expr).

As the GOMP_interop calls had no location data associated with them,
the init call happened as soon as executing the previous line of code,
which was confusing; solution: use the location data of the function
call itself.

PR middle-end/119662

gcc/ChangeLog:

* gimplify.cc (modify_call_for_omp_dispatch): Fix GOMP_interop
arg passing; add location info to function calls.

libgomp/ChangeLog:

* testsuite/libgomp.c/append-args-fr-1.c: New test.
* testsuite/libgomp.c/append-args-fr.h: New test.

gcc/testsuite/ChangeLog:
* c-c++-common/gomp/append-args-interop.c: Update for fixed
GOMP_interop call.
* g++.dg/gomp/append-args-8.C: Likewise.
* gfortran.dg/gomp/append-args-interop.f90: Likewise.

[Bug cobol/119637] link error for LINAGE-COUNTER

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

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

Robert Dubner  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-08
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P4
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rdubner at gcc dot 
gnu.org

--- Comment #1 from Robert Dubner  ---
One of the reasons for what you are seeing is because although the parser
accepts accepts

   FD  mini-report
   linage is 16 lines
   with footing at 15
   lines at top 2
   lines at bottom 2.
   01  report-line pic x(80).

we aren't doing anything with the various values.  

And it appears that we established LINAGE-COUNTER as a global register that we
don't actually do anything with.

Not only is that incorrect -- it needs to be established on a per-file basis --
but as you discovered we didn't even manage to define the variable in global
space.

I am setting this to a lower-priority enhancement.  We'll get to it eventually.

[Bug c/119612] [15 regression] gcc.dg/pr106465.c newly re-broken

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r15-9315-ga3382d9d675f42db96a51d902afc49a0a4cfadee
Author: Martin Uecker 
Date:   Fri Apr 4 21:01:48 2025 +0200

c: fix checking for a tag for variably modified tagged types [PR119612]

The checking assertion added for PR118765 did not take into account
that add_decl_expr can change TYPE_NAME to a TYPE_DECL with no name
for certain cases of variably modified types.  This also implies that we
might sometimes not reliably detect the absence of a tag when only
considering TYPE_NAME.  This patch introduces a new helper function
c_type_tag to reliable compute the tag for a tagged types and uses it
for code where the switch to C23 may cause regressions.

PR c/119612

gcc/c/ChangeLog:
* c-tree.h (c_type_tag): Add prototype.
* c-typeck.cc (c_type_tag): New function.
(tagged_types_tu_compatible_p, composite_type_internal): Use
c_type_tag.
* c-decl.cc (c_struct_hasher::hash, previous_tag): Use c_type_tag.

gcc/testsuite/ChangeLog:
* gcc.dg/gnu23-tag-6.c: New test.
* gcc.dg/pr119612.c: New test.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

Nicolas Boulenguez  changed:

   What|Removed |Added

  Attachment #59360|0   |1
is obsolete||
  Attachment #59644|0   |1
is obsolete||
  Attachment #59645|0   |1
is obsolete||

--- Comment #37 from Nicolas Boulenguez  ---
Created attachment 61037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61037&action=edit
v14 to_duration_64 musl

Hello.
Sorry for the answer delay.

I wonder what is blocking patch 3, which fixes one word in the documentation.

v14 is rebased on fdbe017b.
I will test it again after we are done with style issues and painful rebase
work.

> > I have no way to guess what kind of merge you will prefer in this
> > context.
> we can't change the Calendar API. User code using the new "*_64"
> function will break.
> A possible solution would be to implement the API using your change.

Improving these functions is not a prerequisite for my patches.
Here are some suggestions to anyone working on them.

Ada.Calendar.To_Duration_64 and To_Timespec_64 are in the private part,
and only used by the body of Ada.Calendar_Conversions.
Apparently, this scheme was necessary for Ada private types,
but not for Interfaces.C.*.

Most issues described in the header of my commit introducing C_Time
also affect these two functions. For example,
  To_Timespec (0, Sec, Nsec)
should not set Sec to -1.

When Duration has 64 bits and time_t has 32 bits, should
To_Timespec (2.0**33, Secs, Nsecs)
  set Secs and Nsecs to the correct converted values,
or report an error because the user will almost certainly call
  a C function with the resulting Secs,
  and the C function will return random data or crash?
The second option is trivial to implement on top of System.C_Time.
The first one probably requires some duplication of the implementations
and python tests.

> +#if defined(__USE_TIME64_REDIRECTS) || (__TIMESIZE == 32 && 
> __USE_TIME_BITS64)
> +  C("Glibc_Use_Time_Bits64", Boolean, "True", "Y2038 Glibc transition")
> Would it make sense to drop the "Glibc" here? Having "Glibc" means
> that we end up with glibc specifics in files that are not glibc
> specific (e.g.  a-exetim__posix.adb or s-osinte__linux.ads).
> Are these particular macros glibc specific? We need these to build
> with other libc (e.g. musl).

Could you be more specific about the changes you have in mind?  These
macros seem specific to glibc, but I hardly see how they could break a
build with musl (unless musl uses the same macros for a different
purpose, which seems unlikely).

You probably want the glibc patch for this bug easily extensible, in
case someone tries to also fix musl.
Is a musl fix a prerequisite for applying the glibc fix?

Do you want the symbol names imported as static strings in
s-oscons-tmplt.c, then each file importing with
 External_Name => System.OS_Constants.Foo_External_Name ?

Just as a discussion basis, the attached patch 2 replaces the boolean
with an enumerated type, and adds the Musl External_Names as far as I
understand them in https://musl.libc.org/time64.html.

Note however that _REDIR_TIME64 is not documented and will never be
  https://www.openwall.com/lists/musl/2013/03/29/13
so testing a fix on musl won’t be straightforward.
A ./configure test may be necessary.

[Bug c++/112632] [14 Regression] Non-type template parameter created with converting constructor sometimes has original type

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||nlebedenko at hotmail dot com

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

[Bug rtl-optimization/119681] move instructions inside the unrolled loop of core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Artemiy Volkov from comment #10)
> 
> CMIIW, but this live range splitting is done a bit later by web and works
> well in the case where those pseudos' live ranges can be split without
> changing the CFG.  To handle the case when multiple definitions of a
> variable are visible at the exit BB, you need to create copies of the exit
> BB before you can rename the variable, which is what I do in this patch.

I am not sure you need a copy of the exit BB but rather splitting the edge and
do an insert of a move on the new BB and allow the other parts of GCC do the
copy ...

This is basically what out of SSA does rather than a full exit BB copy.

[Bug cobol/119682] reference-modification (temporary literal?) yields wrong result

[simonsobisch at gnu dot org via Gcc-bugs]

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

--- Comment #1 from Simon Sobisch  ---
Created attachment 61038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61038&action=edit
original program showing the bug

[Bug rtl-optimization/119681] move instructions inside the unrolled loop of core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

[artemiy at synopsys dot com via Gcc-bugs]

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

--- Comment #12 from Artemiy Volkov  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Artemiy Volkov from comment #10)
> > 
> > CMIIW, but this live range splitting is done a bit later by web and works
> > well in the case where those pseudos' live ranges can be split without
> > changing the CFG.  To handle the case when multiple definitions of a
> > variable are visible at the exit BB, you need to create copies of the exit
> > BB before you can rename the variable, which is what I do in this patch.
> 
> I am not sure you need a copy of the exit BB but rather splitting the edge
> and do an insert of a move on the new BB and allow the other parts of GCC do
> the copy ...
> 
> This is basically what out of SSA does rather than a full exit BB copy.

Right.  I am not sure why I said "copies of the exit BB".  The patch splits the
exit edge N times, where N is the unroll factor.  In each of the new exit BBs
it inserts a move instruction for each variable defined in the loop and live in
at the old exit BB.  This has the effect of splitting the DU chains of those
variables.  Then I rename the resulting DU chains when feasible.  And yes, it
is emulating an effect of a phi-function at the entry to the exit BB.

[Bug cobol/119682] New: reference-modification (temporary literal?) yields wrong result

[simonsobisch at gnu dot org via Gcc-bugs]

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

Bug ID: 119682
   Summary: reference-modification (temporary literal?) yields
wrong result
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simonsobisch at gnu dot org
  Target Milestone: ---

I'd consider that a much worse than any SIGSEGV that may arise - as that is
"basic COBOL". It is even more shocking that this was not found before, even
with full UAT and "what ever part of NIST".

Program to reproduce the issue:

   IDENTIFICATION DIVISION.
   PROGRAM-ID. bug.
   DATA DIVISION.
   WORKING-STORAGE SECTION.
   01 N-D1  PIC 9(04).
   PROCEDURE DIVISION.
   MOVE '12' TO N-D1(2:2)
   IF N-D1(2:2) > '12'
  DISPLAY ' INVALID COMPARE ' N-D1(2:2) '!'.
   GOBACK.

Note: works as expected when the data-definition is changed to 9(03).

[Bug c++/119574] [14/15 regression] ICE on lambda in default template argument since r15-3530

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #7 from Richard Biener  ---
Patrick?  Can you please have a look here?

While the trunk ICE is suppressed by release checking the ICE on the 14 branch
is a different one, and that prevails with release checking as Andrew says.
So I wonder what fixed it on trunk with release checking?  It also makes the
issue on the 14 branch more severe (and we should possibly track both
issues separately...).

t.ii: In substitution of ‘template  [with auto G =
]’:
t.ii:2:23:   required from ‘void f(F) [with F = ]’
2 | void f(F op = {}) { op(); }
  | ~~^~
t.ii:4:15:   required from here
4 | int main() { f(); }
  |  ~^~
t.ii:1:43: internal compiler error: in get_innermost_template_args, at
cp/pt.cc:684
1 | template  () {})>
  |   ^
0x110d617 get_innermost_template_args(tree_node*, int)
/space/rguenther/src/gcc-14-branch/gcc/cp/pt.cc:684

[Bug bootstrap/119680] New: [15 Regression] Bootstrap fails with --enable-host-pie

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

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

Bug ID: 119680
   Summary: [15 Regression] Bootstrap fails with --enable-host-pie
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We now link libbacktrace.a into collect2 via LIBDEPS where I get the following:

[  275s] g++ -pie   -fmessage-length=0 -grecord-gcc-switches -O2
-funwind-tables
 -fasynchronous-unwind-tables -fstack-clash-protection -g -DIN_GCC
-DCROSS_D
IRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-
Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute
 -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-va
riadic-macros -Wno-overlength-strings  -DHAVE_CONFIG_H -pie -static-libstdc++
-s
tatic-libgcc  -o Tcollect2 \
[  275s]collect2.o collect2-aix.o vec.o ggc-none.o collect-utils.o
file-
find.o hash-table.o selftest.o libcommon.a ../libcpp/libcpp.a  
../libbacktrace/
.libs/libbacktrace.a ../libiberty/pic/libiberty.a
../libdecnumber/libdecnumber.a

[  275s]
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld
: ../libbacktrace/.libs/libbacktrace.a(backtrace.o): relocation R_X86_64_32
agai
nst `.text' can not be used when making a PIE object; recompile with -fPIE
[  275s]
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld
: failed to set dynamic section sizes: bad value
[  275s] collect2: error: ld returned 1 exit status
[  275s] make[2]: *** [Makefile:2587: collect2] Error 1

It seems while we have elaborate setup for libiberty:

# Use the "pic" build of libiberty if --enable-host-shared or
--enable-host-pie,
# unless we are building for mingw.
LIBIBERTY_PICDIR=$(if $(findstring mingw,$(target)),,pic)
ifneq ($(enable_host_shared)$(enable_host_pie),)
LIBIBERTY = ../libiberty/$(LIBIBERTY_PICDIR)/libiberty.a
else
LIBIBERTY = ../libiberty/libiberty.a
endif
ifeq ($(enable_host_shared),yes)
BUILD_LIBIBERTY = $(build_libobjdir)/libiberty/$(LIBIBERTY_PICDIR)/libiberty.a
else
BUILD_LIBIBERTY = $(build_libobjdir)/libiberty/libiberty.a
endif   

we lack any such for libbacktrace.  I'm not sure why we now end up using
libbacktrace.a from collect2 or whether apart from collect2 sth else is
affected as well.  We don't build a PIC host libbacktrace.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

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

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

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

https://gcc.gnu.org/g:04918a2d3f20b02ac3efad1096c33894d57789a0

commit r15-9316-g04918a2d3f20b02ac3efad1096c33894d57789a0
Author: Jakub Jelinek 
Date:   Tue Apr 8 15:14:58 2025 +0200

simplify-rtx: Fix up POPCOUNT optimization [PR119672]

The gcc.dg/vect/pr113281-1.c test and many others ICE on riscv since
presumably the r15-9238 change which allowed more cases of vector modes
in simplify_const_relational_operation.
In the testcase it is EQ of
(popcount:SI (unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE))
and
(const_int 0 [0])
which it tries to fold as EQ comparison of
(unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
with
(const_int 0 [0])
which ICEs because const0_rtx isn't a vector.
Fixed by using CONST0_RTX, so that we pass
(const_vector:RVVMF32BI repeat [
(const_int 0 [0])
])
instead.

2025-04-08  Jakub Jelinek  

PR rtl-optimization/119672
* simplify-rtx.cc
(simplify_context::simplify_relational_operation_1):
For POPCOUNT == 0 or != 0 optimizations use
CONST0_RTX (GET_MODE (XEXP (op0, 0))) rather than const0_rtx.

[Bug target/119298] [15 Regression] 538.imagick_r is faster when compiled with GCC 14.2 and -Ofast -flto -march=native than with master on Zen5 since r15-3441-g4292297a0f938f

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

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

--- Comment #6 from Richard Biener  ---
So this is likely a Zen5 tuning thing that makes the vectorization profitable.
Though since this just transforms stores this cannot be a STLF fail, instead
it's likely the vector(4) long unsigned int builds from scalars that cause
this.

It's also not possible the add/sub insn cost change causes this.

Could it be that this is in the end sth similar as we see with LBM?

[Bug target/119664] [15 regression] ICE compiling Linux with h8300-linux compiler

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-08
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jakub Jelinek  ---
Guess latent since r12-2601 , but it is actually late_combine2 that propagates
it.
There is a mismatch on the mode iterators introduced by that commit,
(define_insn_and_split ""
  [(set (pc)
(if_then_else (match_operator 3 "eqne_operator"
[(zero_extract:QHSI (match_operand:QHSI 1
"register_operand" "r")
(const_int 1)
(match_operand 2
"const_int_operand" "n"))
 (const_int 0)])
  (label_ref (match_operand 0 "" ""))
  (pc)))]
in jumpcall.md uses QHSI, but
(define_insn ""
  [(set (reg:CCZ CC_REG)
(eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
  (const_int 1)
  (match_operand 1 "const_int_operand" "n"))
(const_int 0)))]
in testcompare.md uses HSI.
--- gcc/config/h8300/jumpcall.md.jj 2021-08-30 08:36:11.044519071 +0200
+++ gcc/config/h8300/jumpcall.md2025-04-08 13:11:03.643093722 +0200
@@ -146,9 +146,9 @@
 (define_insn_and_split ""
   [(set (pc)
(if_then_else (match_operator 3 "eqne_operator"
-   [(zero_extract:QHSI (match_operand:QHSI 1
"register_operand" "r")
-   (const_int 1)
-   (match_operand 2
"const_int_operand" "n"))
+   [(zero_extract:HSI (match_operand:HSI 1
"register_operand" "r")
+  (const_int 1)
+  (match_operand 2 "const_int_operand"
"n"))
 (const_int 0)])
  (label_ref (match_operand 0 "" ""))
  (pc)))]
@@ -156,7 +156,7 @@
   "#"
   "&& reload_completed"
   [(set (reg:CCZ CC_REG)
-   (eq (zero_extract:QHSI (match_dup 1) (const_int 1) (match_dup 2))
+   (eq (zero_extract:HSI (match_dup 1) (const_int 1) (match_dup 2))
(const_int 0)))
(set (pc)
(if_then_else (match_op_dup 3 [(reg:CCZ CC_REG) (const_int 0)])
fixes this, but what do I know about h8300...

[Bug c++/119652] [14/15 Regression] constinit empty direct-list-initialization incorrectly rejected since r14-660

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 14.3/15.

[Bug c++/117530] [14/15 Regression] Mismatch of lambda type with itself in recursive alias declaration

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r15-9313-gd034c78c7be613db3c25fddec1dd50222327117b
Author: Jason Merrill 
Date:   Mon Apr 7 14:35:14 2025 -0400

c++: self-dependent alias template [PR117530]

Here, instantiating B means instantiating A, which means
instantiating B.  And then when we go to register the initial
instantiation, it conflicts with the inner one.  Fixed by checking after
tsubst whether there's already something in the hash table.  We already did
something much like this in tsubst_decl, but that doesn't handle this case.

While I was here, I noticed that we had a pop_deferring_access_checks on
one
early exit but not another, and since I wanted to add yet another I
switched
to using deferring_access_check_sentinel.

PR c++/117530

gcc/cp/ChangeLog:

* pt.cc (instantiate_template): Check retrieve_specialization after
tsubst.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-uneval27.C: New test.

[Bug c++/119574] [14/15 regression] ICE on lambda in default template argument since r15-3530

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

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

--- Comment #8 from Richard Biener  ---
On trunk the following partial revert fixes the testcase.  The backported
fix for PR116567 didn't contain this optimization so I conclude that fix
caused a different issue?

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 95b89f1281b..07a9564cbed 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -13740,8 +13740,7 @@ add_extra_args (tree extra, tree args, tsubst_flags_t
complain, tree in_decl)
   gcc_assert (!TREE_PURPOSE (extra));
   extra = TREE_VALUE (extra);
 }
-  gcc_checking_assert (TREE_STATIC (extra) == uses_template_parms (extra));
-  if (TREE_STATIC (extra))
+  if (uses_template_parms (extra))
 /* This is a partial substitution into e.g. a requires-expr or lambda-expr
inside a default template argument; we expect 'extra' to be a full set
of template arguments for the template context, so it suffices to just

[Bug c++/117530] [14 Regression] Mismatch of lambda type with itself in recursive alias declaration

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/119594] [15 regression] wrong code at -Os with "-fno-dce -fno-tree-dce -fno-tree-dse" on x86_64-linux-gnu since r15-1575

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

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

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

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

commit r15-9307-g1a8e821577dfb535aa54df311ccb282363a93355
Author: Jakub Jelinek 
Date:   Tue Apr 8 11:55:13 2025 +0200

cse: Fix up delete_trivially_dead_insns [PR119594]

The following testcase is miscompiled by delete_trivially_dead_insns,
latently since r0-6313, actually since r15-1575.

The problem is in that r0-6313 change, which made count_reg_usage not
count uses of the pseudo which the containing SET sets.  That is needed
so we can delete those instructions as trivially dead if they are really
dead, but has the following problem.  After fwprop proper we have:
(insn 7 2 8 2 (set (reg/v:DI 101 [ g ])
(const_int -1 [0x])) "pr119594.c":8:10 95
{*movdi_internal}
 (nil))
...
(insn 26 24 27 7 (set (reg:DI 104 [ g ])
(zero_extend:DI (subreg:SI (reg/v:DI 101 [ g ]) 0)))
"pr119594.c":11:8 175 {*zero_extendsidi2}
 (expr_list:REG_EQUAL (const_int 4294967295 [0x])
(expr_list:REG_DEAD (reg/v:DI 101 [ g ])
(nil
(insn 27 26 28 7 (set (reg/v:DI 101 [ g ])
(zero_extend:DI (subreg:SI (reg/v:DI 101 [ g ]) 0)))
"pr119594.c":11:8 175 {*zero_extendsidi2}
 (expr_list:REG_EQUAL (const_int 4294967295 [0x])
(expr_list:REG_UNUSED (reg/v:DI 101 [ g ])
(nil
and nothing else uses or sets the 101 and 104 pseudos.  The subpass doesn't
look at REG_UNUSED or REG_DEAD notes (correctly, as they aren't guaranteed
to be accurate).  The last change in the IL was forward propagation of
(reg:DI 104 [ g ]) value into the following insn.
Now, count_reg_usage doesn't count anything on insn 7, the SET_DEST is a
reg, so we don't count that and SET_SRC doesn't contain any regs.
On insn 26 it counts one usage of pseudo 101 (so counts[101] = 1) and
on insn 27 since r0-6313 doesn't count anything as that insn sets
pseudo 101 to something that uses it, it isn't a side-effect instruction
and can't throw.

Now, after counting reg usages the subpass walks the IL from end to start,
sees insn 27, counts[101] is non-zero, so insn_live_p is true, nothing is
deleted.  Then sees insn 26, counts[104] is zero, insn_live_p is false,
we delete the insn and decrease associated counts, in this case counts[101]
becomes zero.  And finally later we process insn 7, counts[101] is now
zero,
insn_live_p is false, we delete the insn (and decrease associated counts,
which aren't any).
Except that this resulted in insn 27 staying in the IL but using a REG
which is no longer set (and worse, having a REG_EQUAL note of something we
need later in the same bb, so we then assume pseudo 101 contains
0x,
which it no longer does.

Now, if insn 26 was after insn 27, this would work just fine, we'd first
delete that and then insn 27 and then insn 7, which is why most of the time
it happens to work fine.

The following patch fixes it by detecting the cases where there are
self-references after a pseudo has been used at least once outside of the
self-references or just as REG_P SET_DEST and in that case only increases
the count for the pseudo, making it not trivially deletable.

2025-04-08  Eric Botcazou 
Jakub Jelinek  

PR rtl-optimization/119594
* cse.cc (count_reg_usage): Count even x == dest regs if they have
non-zero counts already and incr is positive.

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

[Bug target/119664] [15 regression] ICE compiling Linux with h8300-linux compiler

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug bootstrap/119680] Build fails with --enable-host-pie linking collect2

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Possibly do it like for libcpp, always build libbacktrace PIE (like we build it
PIC for host-hared):

diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 75b3a7536f1..6549cdeacf4 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -175,11 +175,16 @@ else
   fi
 fi

+# Enable --enable-host-pie.
+AC_ARG_ENABLE(host-pie,
+[AS_HELP_STRING([--enable-host-pie],
+[build host code as PIE])],
+[PIC_FLAG=-fPIE], [PIC_FLAG=])
 # Enable --enable-host-shared.
 AC_ARG_ENABLE(host-shared,
 [AS_HELP_STRING([--enable-host-shared],
[build host code as shared libraries])],
-[PIC_FLAG=-fPIC], [PIC_FLAG=])
+[PIC_FLAG=-fPIC])
 AC_SUBST(PIC_FLAG)

 # Enable Intel CET on Intel CET enabled host if jit is enabled.

[Bug rtl-optimization/119681] extraneous move instructions when unrolling core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

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

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

--- Comment #6 from Andrew Pinski  ---
>(Note that the GIMPLE unroller already does this, but it doesn't handle 
>uncountable loops.)

Actually the gimple unroller does NOT duplicate exit blocks at all. Rather it
is how out of ssa works when it deals with phi nodes here and splits the live
range which allows the rtl to work better.

[Bug rtl-optimization/119681] extraneous move instructions when unrolling core_list_reverse () with -O3 -funroll-all-loops; not copying the return block

[artemiy at synopsys dot com via Gcc-bugs]

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

--- Comment #7 from Artemiy Volkov  ---
(In reply to Andrew Pinski from comment #6)
> >(Note that the GIMPLE unroller already does this, but it doesn't handle 
> >uncountable loops.)
> 
> Actually the gimple unroller does NOT duplicate exit blocks at all. Rather
> it is how out of ssa works when it deals with phi nodes here and splits the
> live range which allows the rtl to work better.

Thanks.  I will amend the wording.

[Bug c++/90468] Documentation: typo in the part that tells whether the positive or the negative form of an option is documented

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

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

--- Comment #6 from Jonathan Wakely  ---
I think it's referring to control-flow problems and data-flow problems, but
maybe I'm wrong about that. I'm not sure what a warning about control is, but I
know what control flow is

Also, I think the original was about warnings that are _sensitive to_
control-flow and data-flow, not necessarily warnings _about_ control-flow and
data-flow. Although I can't think of any examples of warnings sensitive to
control-flow or data-flow where you couldn't argue that they are also about
those. So maybe it doesn't matter.

[Bug target/119629] mismatch between [power9-64] builtins and their instructions

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #1)
> (In reply to Alexandre Oliva from comment #0)
> > - TARGET_64BIT seems to imply TARGET_POWERPC64, but TARGET_POWERPC64 doesn't
> > imply TARGET_64BIT
> I'll answer this first, since it affects your observations and questions.
> Yes, TARGET_64BIT implies TARGET_POWERPC64 and yes, TARGET_POWERPC64 does
> not imply TARGET_64BIT. Confusing I know!

TARGET_64BIT is kind of generic (every target defines it itself, but many do,
and the meaning is the same always: are pointers 64-bit, essentially).

TARGET_POWERPC64 means the target supports 64-bit instructions.  This is true
for all CPUs that *can* run SF=1, 64-bit addressing enabled.  You can run all
these instructions when SF=0 as well, and most of those instructions make sense
somewhat as well.  When running in 32-bit mode the contents of the top half
of the registers is not guaranteed, can be killed at any point really, but
that is not often a problem, many insns have a useful effect using only the
low half of register contents!


> TARGET_64BIT (ie, -m64) tells us whether the binary we are creating will be
> running in 64-bit mode or not.

Whether the ABI is a 64-bit ABI.  Yes.

> TARGET_POWERPC64 (-mpowerpc64) tells us
> whether we can emit 64-bit ISA instructions.

Long long long ago it was a special category in the PEM even, but nowadays
pretty much every CPU supports it of course :-)

> The confusion is that most
> 64-bit ISA instructions execute just fine in 32-bit mode (ie, -m32) _when_
> they are run on 64-bit hardware.

Yes.  The registers are 64-bit (on 64-bit hardware) anyway, and most OSes
save all contents always.  But in GCC we do not depend on that.  On older Linux
the top half of register contents could be vandalised in some cases, for
example.


> We do support and there are specialized
> use cases for -m32 -mpower64 compiles, which is when TARGET_64BIT can be
> false and TARGET_POWERPC64 true.

"Specialised"...  It is the default for most people, anyone using any recent
-mcpu=!


> > cmpeqb's conditions are TARGET_P9_MISC && TARGET_64BIT,
> This is correct, as the cmpeqb ISA description states that the instruction
> has UB in 32-bit mode.  This is unlike many of our 64-bit load and store
> instructions which do work in 32-bit mode, so they're gated by
> TARGET_POWERPC64.

Yup.  Instructions that have output bits not in the top 32 bits of a GPR that
depend on the top 32 bits of GPRs need -m64.

> > but the conditions that enable the expansion of __builtin_scalar_byte_in_set
> > are those of [power9-64], namely TARGET_MODULE && TARGET_POWERPC64.  
> I believe this is a bug and this and the other [power*-64] tests should be
> using TARGET_64BIT instead of TARGET_POWERPC64.

Sounds like it yes.

> > On a powerpc-elf standard build, TARGET_POWERPC64 is enabled, but
> > TARGET_64BIT isn't, and so gcc.target/powerpc/byte-in-set-2.c fails
> > to compile with an ICE (instruction not recognized) instead of the
> > expected error.
> 
> That powerpc-elf enables TARGET_POWERPC64 smells like a bug to me as well,
> but not knowing who/what uses that target triplet, I cannot say for certain.

It should not (and does not!) be enabled by default, no.  But if you use -mcpu=
or similar chances are you get TARGET_POWERPC64 enabled, as you should.

> Segher & Mike, do you agree that powerpc-elf should not be enabling
> TARGET_POWERPC64 by default?  This does not happen on a powerpc-linux build.

All our subtargets (OS targets) have their own default CPUs as well, this might
matter here?

[Bug target/119629] mismatch between [power9-64] builtins and their instructions

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

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

--- Comment #4 from Segher Boessenkool  ---
Hi Alex,

(In reply to Alexandre Oliva from comment #0)
> This raises a number of problems:
> 
> - instructions and expanders for these builtins don't have their conditions
> tested, so they must necessarily follow from the builtin conditions, and
> this case clearly isn't

"They don't have their conditions tested"?  What does that mean?

> - TARGET_64BIT seems to imply TARGET_POWERPC64, but TARGET_POWERPC64 doesn't
> imply TARGET_64BIT

Yes.  As it should.  TARGET_POWERPC64 enables instructions that require 64-bit
registers.

> - TARGET_MODULO isn't used very often in conditions in the .md file, but it
> can be controlled independently from TARGET_P9_MISC

Yes?  What is the question?

>From rs6000.opt:
mmodulo
Target Undocumented Mask(MODULO) Var(rs6000_isa_flags)
Generate the integer modulo instructions.

Normally you would not use this -m ever, just have it set by the -mcpu= you
use.

> - the misuse of TARGET_64BIT in cmpeqb alone makes me worry that other
> instructions guarded by it may have the same condition mismatch problem.

This has happened many times over the last few decades.  Most of those problems
are solved by now.  Maybe you should take solace in the fact that we do not
have macros for the twenty-odd different things where the differences matter,
and we do not allow controlling these separately :-)

> cfuged seems to be one of those, and [power10-64] accepts TARGET_POWERPC64
> instead.  there may be more.
> 
> it looks like a review by someone familiar with this port and these
> instructions would probably be useful

I would hope that existing testcases catch most of these problems.  But we have
many testcases that are disabled for unnecessary reasons :-(

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #17 from Patrick Palka  ---
(In reply to Jason Merrill from comment #15)
> (In reply to Patrick Palka from comment #12)
> > Substituting  into  seems like a partial
> > substitution to me.  If the lambda itself had any template parameters of its
> > own, or autos, we wouldn't want to reduce their level, so it seems
> > tf_partial should be set during normalization?
> 
> Hmm, perhaps, it certainly seems related to the use of tf_partial in
> instantiate_template.  But doing that brings back the tsubst_lambda_expr
> EXTRA_ARGS problems.
Yeah, passing tf_partial wouldn't be sufficient IIUC.
> 
> I think part of the problem is that tf_partial has gotten overloaded.  The
> original meaning was "we only have arguments for some of the parms at this
> level".  The use in instantiate_template has broadened the meaning to
> "substituting without changing the number of levels of parms".  Which would
> also apply in normalization.
> 
> But it's unclear to me why we would want EXTRA_ARGS in that broader sense;
> if we have all the args, we're just substituting them, I'd expect that to
> work fine with the "leave auto alone" meaning.
Even with level-less auto, what about a generic lambda's own template
parameters?  We still need to avoid lowering their levels prematurely during a
dependent/partial substitution.

template
struct A {
  template
  using type = decltype([]{});

  void f() { type t; }
};

template void A::f();

Here we eagerly substitute the alias template ahead of time with a full set of
generic arguments {{T},{int}}.  And then at instantiation time we substitute
again with a full set of concrete arguments {{char},{int}}.  If we don't pass
tf_partial the first time around, the level of V would be prematurely lowered
to 1 which causes the instantiation time substitution to misbehave.
> 
> And the assumption in add_extra_args seems wrong for the original sense; in
> general with tf_partial we would not have a full set of template arguments,
> though we might have enough of them to do the substitution.  And we should
> have the right number of levels, which is the point of that change.
At least for the fn_type_unification and coerce_template_parms call sites that
pass tf_partial under the old meaning, we should always have a full set of
template arguments (with some arguments missing in the innermost level).  Ditto
the instantiate_template call site under the broader meaning.

[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #11 from Edwin Lu  ---
(In reply to Robin Dapp from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > Thanks, I've posted it to gcc-patches in case some CI picks it up too:
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680408.html
> 
> Testing looked good on rv64gcv_zvl512b (no bootstrap).  Actually the CI
> should be picking it up if "riscv" is found anywhere in the mail body but at
> least in patchwork it doesn't appear:
> 
> https://patchwork.sourceware.org/project/gcc/list/?q=riscv

The CI should have picked it up but I think there was still some fallout due to
the outage yesterday. The patchwork mbox link for the patch (and several other
patches around that time) are completely broken so the patch slipped through
the system. 

The CI searches for riscv/risc-v (case insensitive) in the mbox or if
patchworks...@rivosinc.com is cc'ed when sent up to the patch list. I'll try to
make the CI a bit more robust in case something like this happens again.

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #18 from Patrick Palka  ---
I think I see what you mean -- for the instantiate_template (and possibly even
coerce_template_parms) call site, we could define and pass a new flag
tf_no_level_lowering instead of tf_partial to tell tsubst_lambda_expr to
eagerly substitute, without any level lowering, instead of deferring the
substitution using the EXTRA_ARGS mechanism, so that we don't unnecessarily
defer in more cases.  We'd still need to use tf_partial and defer from e.g.
fn_type_unification though.

[Bug tree-optimization/83022] malloc & memset -> calloc is not always an optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-11-17 00:00:00 |2025-4-8
   Assignee|nathan at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #7 from Andrew Pinski  ---
Since I am working in this area I am going to take over as there has been no
movement on this since 2017 really.

My idea is to do the following:

if bb of the malloc and the "memset" are the same allow it.

check the pred of the "memset" bb to see if the malloc bb.
  if not, reject
  otherwise check that the last statement of the malloc bb is a condtional and
that is checking on the address is non null


This will allow for things like:
```
void *m (int s, bool c, bool *a)
{
  void *r = __builtin_malloc (s);
  *a = 1;
 if (r)
  {
__builtin_memset (r, 0, s);
  }
  return r;
}
```

[Bug c++/119668] C++20 Nested concepts with NTTP triggers ICE

[nlebedenko at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from Nikolay Lebedenko  ---
(In reply to Andrew Pinski from comment #1)
> >It does not appear in GCC 14.1+.
> 
> Did you read https://gcc.gnu.org/bugs/#dontwant ?
> > Duplicate bug reports, or reports of bugs already fixed in the development 
> > tree, especially those that have already been reported as fixed last week 
> > :-)
> 
> 
> Considering this is not a regression this will most likely be closed as a
> dup or closed as fixed depending on which commit fixed it.

Yes, I did read it, I just figured that since GCC 13.3 was released after GCC
14.1, perhaps GCC 13.x was still going to receive further updates (where
potentially this issue could get fixed). I also looked for existing / fixed
reports but couldn't find anything that was relevant.

I am a bit confused with how GCC does versioning, I figured that some previous
major versions are still actively supported and receive patches, sorry if I'm
not understanding something.

I really appreciate what you guys do, sorry if I've mistakenly submitted a
duplicate!

[Bug bootstrap/119680] Build fails with --enable-host-pie linking collect2

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[15 Regression] Bootstrap   |Build fails with
   |fails with  |--enable-host-pie linking
   |--enable-host-pie   |collect2
 Target||riscv
   Keywords||build
  Known to fail||14.2.1, 15.0
   Host||x86_64-unknown-linux-gnu
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
The particular build that failed for me was a cross to riscv64 using binutils
2.43 and glibc 2.31 configured with

[   37s] + ../configure 'CFLAGS= -fmessage-length=0 -grecord-gcc-switches -O2
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g'
'CXXFLAGS= -fmessage-length=0 -grecord-gcc-switches -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' 'XCFLAGS=
-fmessage-length=0 -grecord-gcc-switches -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' 'TCFLAGS=
-fmessage-length=0 -grecord-gcc-switches -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' 'GDCFLAGS=
-fmessage-length=0 -grecord-gcc-switches -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -g' --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c --enable-host-pie
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/15
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/usr/riscv64-suse-linux/sys-root/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-15
--program-prefix=riscv64-suse-linux- --target=riscv64-suse-linux --disable-nls
--with-sysroot=/usr/riscv64-suse-linux/sys-root
--with-build-sysroot=/usr/riscv64-suse-linux/sys-root
--with-build-time-tools=/usr/riscv64-suse-linux/bin --disable-gcov
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-libquadmath --disable-libatomic --without-headers
--with-newlib --disable-multilib --disable-bootstrap
--enable-link-serialization --disable-libsanitizer --build=x86_64-suse-linux
--host=x86_64-suse-linux

>From a newer codebase a cross build from ppc64le -> x86_64 works fine
linking collect2, it seems no symbols are picked up from libbacktrace there.

Fails on both trunk and the 14 branch (--enable-host-pie is new there).

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

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

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

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

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

commit r15-9317-g1b5b02be5740b69f670b1591ac63eb6a69ff1f79
Author: Jakub Jelinek 
Date:   Tue Apr 8 15:57:45 2025 +0200

cobol: Further fixes for cobol cross-compilation from 32-bit arches
[PR119364]

On top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680256.html
patch this brings make check-cobol when using the cross compiler from
32-bit host to x86_64-linux to the following:
  Running /home/jakub/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
  FAIL: cobol.dg/group1/declarative_1.cob   -O0  execution test
  FAIL: cobol.dg/group1/declarative_1.cob   -O1  execution test
  FAIL: cobol.dg/group1/declarative_1.cob   -O2  execution test
  FAIL: cobol.dg/group1/declarative_1.cob   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
  FAIL: cobol.dg/group1/declarative_1.cob   -O3 -g  execution test
  FAIL: cobol.dg/group1/declarative_1.cob   -Os  execution test

  === cobol Summary ===

  # of expected passes3123
  # of unexpected failures6
  # of expected failures  6
(which has some analysis but not a fix yet).

This patch fixes various cases where host size of various types
(void *, int, size_t, unsigned char) is used in place where
size of those types in bytes on the target should be used instead.
At least the size of void * and size_t actually differns between
ilp32 hosts and lp64 targets, int could be different in theory as well
but we actually don't support 16-bit ints on the host side and only support
lp64 targets right now for cobol, and finally sizeof(unsigned char) is
always 1, so there is no point to multiply by that and it is still
wrong to use host sizeof for the target decisions.

2025-04-08  Jakub Jelinek  

PR cobol/119364
* genapi.cc (function_handle_from_name): Use sizeof_pointer.
(parser_file_add): Use int_size_in_bytes(VOID_P) and
int_size_in_bytes(int).
(inspect_tally): Use int_size_in_bytes(VOID_P).
(inspect_replacing): Likewise.
(gg_array_of_field_pointers): Likewise.
(gg_array_of_file_pointers): Likewise.
(parser_set_pointers): Use sizeof_pointer.
* cobol1.cc (create_our_type_nodes_init): Use
int_size_in_bytes(SIZE_T) and int_size_in_bytes(VOID_P).
* gengen.cc (gg_array_of_size_t): Use int_size_in_bytes(SIZE_T).
(gg_array_of_bytes): Just use N, don't multiply it by
sizeof(unsigned char).
* parse.y: Include tree.h.  Use int_size_in_bytes(ptr_type_node).

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #11 from Jason Merrill  ---
(In reply to Patrick Palka from comment #8)
> Started with r14-9938, though I bet before this commit it only accidentally
> worked.

This failure does seem to be strongly connected to that commit.

When normalizing is_foo for , we get to normalizing tt for
, which means substituting  into .

Since r14-9938, because in_template_context is false we return the lambda
unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure type still
refers to the is_specialization_of tparms in its CLASSTYPE_TEMPLATE_INFO.

The first failure comes in normalization caching find_template_parameters
walking over the parameter mapping; any_template_parm_r walks into the
TREE_TYPE of a LAMBDA_EXPR without considering EXTRA_ARGS and finds a template
parm from the wrong parameter list.

If I prevent that by skipping caching of lambdas, I then hit another crash in
tsubst_lambda_expr during satisfaction, because add_extra_args expects
dependent EXTRA_ARGS to have been set with tf_partial, but the earlier
substitution correctly wasn't tf_partial, so the expectation is violated.

It seems to me that the underlying issue is the "in_template_context is false";
we're normalizing a concept, that is a template context.  So I guess
normalize_concept_definition needs to set current_template_parms.

[Bug tree-optimization/87900] malloc + memset to calloc doesn't work for aggregate initialization

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

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

--- Comment #4 from Andrew Pinski  ---
The question now comes should this be handled too:
```
typedef int type;

#define size (4)
type *foo ()
{
  type *p = (type *)__builtin_malloc (size*sizeof(type));
  type tmp[size] = {};
  __builtin_memcpy(p,tmp,sizeof(tmp));
  return p;
}
```

MY patch does not handle this because we get:
```
  p_3 = __builtin_malloc (16);
  MEM  [(char * {ref-all})p_3] = 0;
```

I am thinking that is ok here.

What is interesting is that change the type to char and then do a non-power of
2, clang will transform it into calloc (my patch too) but if you have a power
of 2 up to 8, clang will not do the transformation (at least for aarch64).

I am not 100% sure if we want to have a lower limit for the size of memset
either. clang acts similar enough to my patch though.

[Bug tree-optimization/83022] [12/13/14/15 Regression] malloc & memset -> calloc is not always an optimization

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

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

--- Comment #11 from Andrew Pinski  ---
https://inbox.sourceware.org/gcc-patches/f4b5d106-8176-b7bd-709b-d43518878...@acm.org/

Ok, Nathan did submit something similar to my patch in the end and I missed it.

Let me poke at the probility counts but that will be for tomorrow.

This logic definitely needs to be in its own function too.

[Bug tree-optimization/119683] [13/14/15 Regression] recalculating the return value which was already in the register right before function return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.4
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-08
Summary|[13/14 Regression]  |[13/14/15 Regression]
   |recalculating the return|recalculating the return
   |value which was already in  |value which was already in
   |the register right before   |the register right before
   |function return |function return
  Component|middle-end  |tree-optimization

--- Comment #1 from Andrew Pinski  ---
The difference is:
  _3 = (int) c_12(D);
  _4 = _3 + -48;
  _15 = (unsigned int) _4;

vs

  _26 = c_12(D) + -48;
  _15 = (unsigned int) _26;


The match pattern:
((T)(A)) + CST -> (T)(A + CST)

used to handle this. but for some reason it is not doing it any more ...

[Bug tree-optimization/83022] [12/13/14/15 Regression] malloc & memset -> calloc is not always an optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
Summary|malloc & memset -> calloc   |[12/13/14/15 Regression]
   |is not always an|malloc & memset -> calloc
   |optimization|is not always an
   ||optimization

--- Comment #10 from Andrew Pinski  ---
Techincally this is a regression so I am going to mark it as such. If I get
some time over the next week I will submit a version to try to introduce this
for GCC 15.

[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled

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

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

--- Comment #11 from Vineet Gupta  ---
Debug log for the smaller test [1]

https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680355.html

It hits the same ABNORMAL_EDGE assert.

 - bb 17 has V insns, needing vsetvl - which LCM tries to "bubble up" to
15,16... 
 - bb 38 has the unwinder call (dest of abnormal edge). It is code_label/s
address taken in eh_tables, no direct call flow leading to it).
 - bb 16 and 15 have "abnormal edges" to bb 38.


We see the following output where LCM is working its way up (read from bottom
up)

  ;; 19 succs { 20 31 }  # P2. lift up 3 (succ 31 was lift up 2)
  ;; 30 succs { 38 31 }  # P2. lift up 3 (succ 31 was lift up 2)
  ;; 31 succs { 44 32 }  # P2. lift up 2b (succ 44 was succ of 15 - lift up 1)
  ;; 44 succs { 15 } # P2. lift up 2a (succ 15 was lift up 1)
  ;; 15 succs { 38 16 }  # P2. lift up 1 (succ 16 was lift up 1)
  ;; 16 succs { 38 17 }  # P2. lift up 0 (succ 17 had vsetvl locally needed)
  ;; 17 succs { 18 31 }  # P1. VSETVL locally needed


LCM needs to elide the "abnormal" edges (so BBS with such edges such as 16 and
15)and it seems current code even does that. With added debug code in
invalid_opt_bb_p () we see following

  ...
   --- skipping abnormal SUCC edge bb 15 -> bb 38):  --- skipping bb 15): 
   --- skipping abnormal SUCC edge bb 16 -> bb 38):  --- skipping bb 16): 
  ...
   --- skipping abnormal PRED edge bb 5 -> bb 38):  --- skipping bb 38): 

However the computed *earliest* bitmap used for vsetvl placement has those bbs,
hence the issue.

Robin suggested (from a different
[PR/119547](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547) that it should
also take into account the *transparent* bitmap which seems to do ths trick.

[Bug tree-optimization/83022] [12/13/14/15 Regression] malloc & memset -> calloc is not always an optimization

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

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

--- Comment #12 from Andrew Pinski  ---
Created attachment 61041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61041&action=edit
Testcases for probability

In the case of dontcombine and maybecombine we should not do the combine of
memset/malloc to calloc. docombine we should.

[Bug tree-optimization/83022] [12/13/14/15 Regression] malloc & memset -> calloc is not always an optimization

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

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

--- Comment #13 from Andrew Pinski  ---
Note clang does not check for probability.

[Bug tree-optimization/87900] malloc + memset to calloc doesn't work for aggregate initialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||83022
   See Also|https://gcc.gnu.org/bugzill |https://github.com/llvm/llv
   |a/show_bug.cgi?id=83022 |m-project/issues/46503

--- Comment #5 from Andrew Pinski  ---
Oh for small power of 2 sizes, clang has a bug report about that:
https://github.com/llvm/llvm-project/issues/46503

So maybe we should handle ` = 0 ` case too ...
It is not hard to add. But first I want to fix PR 83022 before this one.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022
[Bug 83022] [12/13/14/15 Regression] malloc & memset -> calloc is not always an
optimization

[Bug tree-optimization/83022] [12/13/14/15 Regression] malloc & memset -> calloc is not always an optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://reviews.llvm.org/D1
   ||03009,
   ||https://reviews.llvm.org/D1
   ||08485

--- Comment #14 from Andrew Pinski  ---
https://reviews.llvm.org/D108485 is how LLVM fixed this issue.

[Bug c++/119175] [14/15 Regression] ICE segfault on lambda in requires clause of generic lambda in requires clause

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

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

Jason Merrill  changed:

   What|Removed |Added

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