[Bug c++/116208] `__ct_base ` is used instead of the ctor name in warning's `inlined from` when using LTO

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
I don't understand how that could be the case.
If the diagnostics comes from lto1, then it doesn't even link in cp/errors.o
and has its own langhooks, not the C++ one.

[Bug c++/116208] `__ct_base ` is used instead of the ctor name in warning's `inlined from` when using LTO

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

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

--- Comment #12 from Simon Martin  ---
Yeah, I tried with a revert and it does change anything.

[Bug target/117449] New: [15 Regression] ICE in gen_reg_rtx on aarch64 via aarch64_emit_opt_vec_rotate

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

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

Bug ID: 117449
   Summary: [15 Regression] ICE in gen_reg_rtx on aarch64 via
aarch64_emit_opt_vec_rotate
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails (reduced from perlbench_r from SPEC CPU 2017):

$ cat t.c
unsigned long *a;
int i;
void f() {
  for (i = 0; i < 80; i++)
a[i] = (a[i] >> 8 | a[i] << 64 - 8) ^ a[i];
}
$ gcc/xgcc -B gcc -c t.c -S -o /dev/null -O2 -march=armv8-a+sha3
during RTL pass: split2
t.c: In function ‘f’:
t.c:6:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1177
6 | }
  | ^
0x2244a6b internal_error(char const*, ...)
$SRC/gcc/diagnostic-global-context.cc:518
0x79cc0f fancy_abort(char const*, int, char const*)
$SRC/gcc/diagnostic.cc:1696
0xa9dbd3 gen_reg_rtx(machine_mode)
$SRC/gcc/emit-rtl.cc:1177
0xab9523 force_reg(machine_mode, rtx_def*)
$SRC/gcc/explow.cc:682
0x13ecdff aarch64_evpc_tbl
$SRC/gcc/config/aarch64/aarch64.cc:26297
0x13edeef aarch64_vectorize_vec_perm_const
$SRC/gcc/config/aarch64/aarch64.cc:26575
0xdfd133 expand_vec_perm_const(machine_mode, rtx_def*, rtx_def*,
int_vector_builder > const&, machine_mode, rtx_def*)
$SRC/gcc/optabs.cc:6499
0xac8ce3 expand_rotate_as_vec_perm(machine_mode, rtx_def*, rtx_def*, rtx_def*)
$SRC/gcc/expmed.cc:6325
0x13e8dbb aarch64_emit_opt_vec_rotate(rtx_def*, rtx_def*, rtx_def*)
$SRC/gcc/config/aarch64/aarch64.cc:16055
0x1bb073f gen_split_155(rtx_insn*, rtx_def**)
$SRC/gcc/config/aarch64/aarch64-simd.md:1316
0xaa0bd3 try_split(rtx_def*, rtx_insn*, int)
$SRC/gcc/emit-rtl.cc:3941
0xebfa1f split_insn
$SRC/gcc/recog.cc:3475
0xec5423 split_all_insns()
$SRC/gcc/recog.cc:3579
0xec550f execute
$SRC/gcc/recog.cc:4503
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

I suspect r15-4876-g19757e1c28de07b45da03117e6ff7ae3e21e5a7a.

[Bug target/117449] [15 Regression] ICE in gen_reg_rtx on aarch64 via aarch64_emit_opt_vec_rotate

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2024-11-05
   Target Milestone|--- |15.0
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Mine.

[Bug c++/116208] `__ct_base ` is used instead of the ctor name in warning's `inlined from` when using LTO

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

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

Simon Martin  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |simartin at gcc dot 
gnu.org

--- Comment #10 from Simon Martin  ---
(In reply to Sam James from comment #9)
> (In reply to Simon Martin from comment #8)
> > [...]
> > How do you reproduce this? Are you configuring with
> > --with-build-config=bootstrap-lto?
> 
> Sorry for the delay -- I just confirmed I can reproduce it on trunk with
> just ./configure --with-build-config="bootstrap-lto":
Thanks a lot, super helpful!

I think this is due to r0-57483-g93604b1a023480, that can actually be reverted
since r0-124856-g0f9aaac79ed0b5.

Will confirm and hopefully come up with a small testcase we can add to the
testsuite.

[Bug middle-end/117442] [15 Regression] Cannot build libgfortran with enable-gather-detailed-mem-stats after r15-4760-g0b73e9382ab51c

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-11-05
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Seems to happen at exit if there's a buffered diagnostic in error_buffer, due
to its global dtor.

I'm looking at a fix.

[Bug fortran/115070] [13/14 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Paul Thomas :

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

commit r14-10886-gc16e4ecd8fdc2230a313fe795333fa97652ba19f
Author: Paul Thomas 
Date:   Tue Nov 5 15:54:45 2024 +

Fortran: Fix regressions with intent(out) class[PR115070, PR115348].

2024-11-05  Paul Thomas  

gcc/fortran
PR fortran/115070
PR fortran/115348
* trans-expr.cc (gfc_trans_class_init_assign): If all the
components of the default initializer are null for a scalar,
build an empty statement to prevent prior declarations from
disappearing.

gcc/testsuite/
PR fortran/115070
* gfortran.dg/ieee/pr115070.f90: New test.

PR fortran/115348
* gfortran.dg/pr115348.f90: New test.

[Bug fortran/115348] [13/14 Regression] -fcheck=recursion issue with intent(out) derived type argument without components with default value

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

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

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

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

commit r14-10886-gc16e4ecd8fdc2230a313fe795333fa97652ba19f
Author: Paul Thomas 
Date:   Tue Nov 5 15:54:45 2024 +

Fortran: Fix regressions with intent(out) class[PR115070, PR115348].

2024-11-05  Paul Thomas  

gcc/fortran
PR fortran/115070
PR fortran/115348
* trans-expr.cc (gfc_trans_class_init_assign): If all the
components of the default initializer are null for a scalar,
build an empty statement to prevent prior declarations from
disappearing.

gcc/testsuite/
PR fortran/115070
* gfortran.dg/ieee/pr115070.f90: New test.

PR fortran/115348
* gfortran.dg/pr115348.f90: New test.

[Bug analyzer/116977] RFE: Analyzer: track OpenACC "host" vs. "device" pointers

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

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

--- Comment #4 from Thomas Schwinge  ---
David, thanks for the pointers; Vedant is looking into this.

Question:

(In reply to David Malcolm from comment #2)
> Note that the analyzer assumes that pointers in different memory spaces can't 
> alias.

Are you saying that, given two pointers with different values, the analyzer
currently assumes that these don't "alias" (don't point to the same underlying
region of memory)?  That is correct for OpenACC host vs. device pointers.  For
example:

char *a_h = malloc(N);
char *a_d = acc_create(a_h, N);

The 'acc_create' call creates a device memory object "corresponding" to the
host memory object (as specified by 'a_h, N'), but 'a_h' and 'a_d' don't
"alias": OpenACC calls the memory object pointed to by 'a_d' a "visible device
copy", and this means that the memory objects pointed to by 'a_h' and 'a_d' may
diverge.

And/or are you saying that, considering the example above, the analyzer
currently assumes that even if 'a_h' is known to be in the "host" memory space
and 'a_d' is known to be in the "device" memory space (to be implemented),
still 'a_d' must not "alias" 'a_h' in the meaning that the value of 'a_d' must
be different from 'a_h'?

(Is this the same underlying issue that the analyzer currently doesn't (seem
to?) handle address spaces, 'TYPE_ADDR_SPACE'?  There's no GCC PR for that yet,
as far as I can tell, right?)

There is, indeed, per my quick review, no provision in OpenACC from that would
follow that a pointer to a "visible device copy" may not have the same value as
the corresponding host pointer.  (..., or the host/device pointer value spaces
be disjoint, generally.)  I'll bring that up with the OpenACC Technical
Committee.

However, for all practical purposes, we shall assume that host vs. device
pointer values will always be disjoint (other than 'NULL'), for the reason that
the device shares a virtual address space with the host.  Nvidia/CUDA, for
example, calls this 'CU_DEVICE_ATTRIBUTE_UNIFIED_ADDRESSING', and "Unified
addressing is automatically enabled in 64-bit processes",
.  (In
the libgomp nvptx plugin, we 'assert' this to be true.)

> So that might be worth modeling, if I'm understanding OpenACC's pointer model 
> correctly.

[Bug fortran/116388] [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

[trnka at scm dot com via Gcc-bugs]

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

--- Comment #3 from Tomáš Trnka  ---
(In reply to Paul Thomas from comment #2)
> Do you want to apply the fix or shall I do the honours?

I'd love to do it, but I don't have commit access. So if I understand it
correctly, I would have to send a patch to the mailing list and have someone
else (you?) apply it for me. I wouldn't mind doing that to learn the procedure,
but I don't want to waste your time (or anyone else's). So just please pick the
way that's easiest for you.

[Bug c++/116634] [14/15 Regression] constexpr string arrays dont compile in gcc 14.x but works for gcc 13 and earlier.

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

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

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

https://gcc.gnu.org/g:3545aab00152ed3db1d7ce6ca4e1671dde276980

commit r15-4961-g3545aab00152ed3db1d7ce6ca4e1671dde276980
Author: Jason Merrill 
Date:   Mon Nov 4 17:48:46 2024 -0500

c++: allow array mem-init with -fpermissive [PR116634]

We've accidentally accepted this forever (at least as far back as 4.7), but
it's always been ill-formed; this was PR59465.  And we didn't accept it for
scalar types.  But rather than switch to a hard error for this code, let's
give a permerror so affected code can continue to work with -fpermissive.

PR c++/116634

gcc/cp/ChangeLog:

* init.cc (can_init_array_with_p): Allow PR59465 case with
permerror.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/aggr-init1.C: Expect warning with -fpermissive.
* g++.dg/init/array62.C: Adjust diagnostic.
* g++.dg/init/array63.C: Adjust diagnostic.
* g++.dg/init/array64.C: Adjust diagnostic.

[Bug c++/116634] [14 Regression] constexpr string arrays dont compile in gcc 14.x but works for gcc 13 and earlier.

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[14/15 Regression]  |[14 Regression] constexpr
   |constexpr string arrays |string arrays dont compile
   |dont compile in gcc 14.x|in gcc 14.x but works for
   |but works for gcc 13 and|gcc 13 and earlier.
   |earlier.|
   Assignee|mpolacek at gcc dot gnu.org|jason at gcc dot gnu.org

--- Comment #7 from Jason Merrill  ---
Trunk will now allow this with -fpermissive.

[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Di Zhao :

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

commit r15-4956-g5c19ba52519be975d4464b063d3d5a2c700dd241
Author: Di Zhao 
Date:   Tue Nov 5 12:28:54 2024 +0800

testsuite: fix testcase pr110279-1.c

The test case is for targets that support FMA. Previously
the "target" selector is missed in dg-final command.

gcc/testsuite/ChangeLog:
PR tree-optimization/110279
* gcc.dg/pr110279-1.c: add target selector.

[Bug c++/117129] [14/15 Regression] internal compiler error: Segmentation fault at gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int)

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #4 from Simon Martin  ---
Fixed in GCC 15.

[Bug c++/117099] [14/15 Regression] internal compiler error: Segmentation fault in finalize_nrv(tree_node*, tree_node*)

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #5 from Simon Martin  ---
Fixed in GCC 15.

[Bug c++/117099] [14/15 Regression] internal compiler error: Segmentation fault in finalize_nrv(tree_node*, tree_node*)

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

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

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|14.3|15.0

[Bug ipa/117440] [12/13/14/15 regression] ICE: in merge, at ipa-modref.cc:2138 at -Os

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE: in merge, at   |[12/13/14/15 regression]
   |ipa-modref.cc:2138 at -Os   |ICE: in merge, at
   ||ipa-modref.cc:2138 at -Os
   Target Milestone|--- |12.5
  Known to work||11.5.0
  Known to fail||12.4.1, 13.3.1, 14.2.1,
   ||15.0

[Bug testsuite/117444] [15 regression] Assembler output changes after r15-4756-g06bc3a734e8890

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
Fixed.

[Bug c/117445] ICE: in gimple_build_assign_1, at gimple.cc:480

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-Novembe
   ||r/667617.html

--- Comment #4 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667617.html

[Bug testsuite/117444] [15 regression] Assembler output changes after r15-4756-g06bc3a734e8890

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

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

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
  Component|target  |testsuite
 Ever confirmed|0   |1

[Bug testsuite/117444] [15 regression] Assembler output changes after r15-4756-g06bc3a734e8890

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r15-4962-gf185a89fc4b6e6f5ae5475cd7c723b3acf39976b
Author: Peter Bergner 
Date:   Tue Nov 5 10:30:46 2024 -0600

testsuite: Fix up gcc.target/powerpc/safe-indirect-jump-3.c test [PR117444]

The test safe-indirect-jump-3.c FAILs on powerpc64le-linux with the change
in jump table generation behavior with commit r15-4756-g06bc3a734e8890,
since it is compiled without optimization and expects jump tables to be
generated.  Add an explicit -fjump-tables to dg-options to get the old
behavior back.

2024-11-05  Peter Bergner  

gcc/testsuite/
PR testsuite/117444
* gcc.target/powerpc/safe-indirect-jump-3.c: Add -fjump-tables to
dg-options.

[Bug fortran/117434] [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #8 from kargls at comcast dot net ---
(In reply to Iain Sandoe from comment #7)

> 
> 
>   - however, for O0 we get a MAIN__ function which contains:
>:
>   FRAME.3.FRAME_BASE.PARENT = 0B;
>   __builtin_init_trampoline (&FRAME.3.test, test, &FRAME.3);
>   _5 = __builtin_adjust_trampoline (&FRAME.3.test);
>   _6 = (logical(kind=4) (*) (void)) _5;
>   test.1_1 = _6;
>   test.2 = test.1_1;
>   test_description = new_test_description (&test.2);
>   test_description ={v} {CLOBBER(eos)};
>   return;
> 
> .. so is, indeed, using a trampoline to call via a pointer.
> 
> ==
> 
> However on both Linux and Darwin that I tested on, this works exactly as
> expected (the stack is made executable by the trampoline machinery) and the
> test case executes fine.
> 
> Please could folks who saw an issue;
> 1. repeat the tests with the same conditions as above
> 2. report their platform results

% gfcx -o z y.f90 -fdump-tree-optimized && ./z
/usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires executable stack (because
the .note.GNU-stack section is executable)

Looking at the dump, I see the same thing
   :
  FRAME.3.FRAME_BASE.PARENT = 0B;
  __builtin_init_trampoline (&FRAME.3.test, test, &FRAME.3);
  _5 = __builtin_adjust_trampoline (&FRAME.3.test);
  _6 = (logical(kind=4) (*) (void)) _5;
  test.1_1 = _6;
  test.2 = test.1_1;
  test_description = new_test_description (&test.2);
  test_description ={v} {CLOBBER(eos)};
  return;

If I add -save-temps to the command line, the last few lines of z-y.s is

% tail z-y.s 
options.0.1:
.long   10308
.long   16383
.long   0
.long   0
.long   1
.long   0
.long   31
.ident  "GCC: (GNU) 15.0.0 20241024 (experimental)"
.section.note.GNU-stack,"x",@progbits

[Bug target/117449] [15 Regression] ICE in gen_reg_rtx on aarch64 via aarch64_emit_opt_vec_rotate

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Fixed, thanks for the testcase.

[Bug c/117289] gcc.dg/debug/ctf/ctf-function-pointers-2.c failure with -std=gnu23

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

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

--- Comment #5 from David Faust  ---
For BTF this is OK.  The duplication with -std=gnu23 is not ideal, obviously,
since it causes unnecessary bloat.  But the resulting BTF information is still
correct, if not "optimal".

[Bug fortran/115070] [13 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[13/14 Regression] ICE  |[13 Regression] ICE using
   |using IEEE_ARITHMETIC in a  |IEEE_ARITHMETIC in a
   |derived type method with|derived type method with
   |class, intent(out)  |class, intent(out)

--- Comment #13 from Paul Thomas  ---
Had to do the 13-branch patch by hand and so am regtesting. As soon as it is
done, I will commit and push.

Paul

[Bug target/117449] [15 Regression] ICE in gen_reg_rtx on aarch64 via aarch64_emit_opt_vec_rotate

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:161e246cf32f1298400aa3c1d86110490a3cd0ce

commit r15-4963-g161e246cf32f1298400aa3c1d86110490a3cd0ce
Author: Kyrylo Tkachov 
Date:   Tue Nov 5 05:10:22 2024 -0800

PR target/117449: Restrict vector rotate match and split to pre-reload

The vector rotate splitter has some logic to deal with post-reload
splitting
but not all cases in aarch64_emit_opt_vec_rotate are post-reload-safe.
In particular the ROTATE+XOR expansion for TARGET_SHA3 can create RTL that
can later be simplified to a simple ROTATE post-reload, which would then
match the insn again and try to split it.
So do a clean split pre-reload and avoid going down this path post-reload
by restricting the insn_and_split to can_create_pseudo_p ().

Bootstrapped and tested on aarch64-none-linux.

Signed-off-by: Kyrylo Tkachov 
gcc/

PR target/117449
* config/aarch64/aarch64-simd.md (*aarch64_simd_rotate_imm):
Match only when can_create_pseudo_p ().
* config/aarch64/aarch64.cc (aarch64_emit_opt_vec_rotate): Assume
can_create_pseudo_p ().

gcc/testsuite/

PR target/117449
* gcc.c-torture/compile/pr117449.c: New test.

[Bug fortran/115348] [13 Regression] -fcheck=recursion issue with intent(out) derived type argument without components with default value

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[13/14 Regression]  |[13 Regression]
   |-fcheck=recursion issue |-fcheck=recursion issue
   |with intent(out) derived|with intent(out) derived
   |type argument without   |type argument without
   |components with default |components with default
   |value   |value

--- Comment #7 from Paul Thomas  ---
Had to do the 13-branch patch by hand and so am regtesting. As soon as it is
done, I will commit and push.

Paul

[Bug c++/117446] attribute thought to be the template parameter pack

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Rejects valid code on   |attribute thought to be the
   |template parameter packs|template parameter pack
   |not expanded with '...' |
 Ever confirmed|0   |1
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-05

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

[Bug fortran/117434] [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

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

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

--- Comment #9 from Iain Sandoe  ---
(In reply to kargls from comment #8)
> (In reply to Iain Sandoe from comment #7)
> 

> /usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires executable stack
> (because the .note.GNU-stack section is executable)

FAOD - does this actually prevent the executable from running - or is it that
your platform is (correctly) pointing out that executable stack can be
considered a security risk?

Perhaps your static linker has some option that would prevent that warning, is
the man-page visible online?

[Bug tree-optimization/117448] mod is not optimized to cond with subtraction with known (small) ranges

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |NEW

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

There might be another bug asking for something similar.

[Bug tree-optimization/117448] mod is not optimized to cond with subtraction with known (small) ranges

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc failed to optimize  |mod is not optimized to
   |dividing to subtracting |cond with subtraction with
   |with simple assumption  |known (small) ranges
   Severity|normal  |enhancement
   Keywords||missed-optimization

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

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

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

--- Comment #14 from Jonathan Wakely  ---
We're assuming that an iterator's reference type can be converted to the
key_type. This doesn't compile on trunk:

#include 

struct K {
  explicit K(int) noexcept { }
  bool operator==(const K&) const { return true; }
};

template<> struct std::hash {
  auto operator()(const K&) const { return 0ul; }
};

int i[1];
std::unordered_set s(i, i+1);


This fails for similar reasons:

#include 

struct K {
  explicit K(int) noexcept { }
  bool operator==(const K&) const { return true; }
};

template<> struct std::hash {
  auto operator()(const K&) const { return 0ul; }
};

const std::pair p[2]{{1,2}, {3,4}};
std::unordered_map m(p, p+2);


This fails because of a missing specialization for const rvalues:

#include 
#include 

struct Pair
{
  explicit operator std::pair() const&& { return {1, 2}; }
};

Pair p2[1];
std::unordered_map um(std::make_move_iterator(p2),
std::make_move_iterator(p2+1));


Finally, the _ConvertToValueType<_Select1st, T> specialization needs to handle
all value categories of std::pair arguments.

[Bug c++/116634] [14 Regression] constexpr string arrays dont compile in gcc 14.x but works for gcc 13 and earlier.

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
And 14.3.

[Bug c++/116634] [14 Regression] constexpr string arrays dont compile in gcc 14.x but works for gcc 13 and earlier.

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

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

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

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

commit r14-10887-gce25ca4da198ebc269d41ee6a9ac880ae8f67ad6
Author: Jason Merrill 
Date:   Mon Nov 4 17:48:46 2024 -0500

c++: allow array mem-init with -fpermissive [PR116634]

We've accidentally accepted this forever (at least as far back as 4.7), but
it's always been ill-formed; this was PR59465.  And we didn't accept it for
scalar types.  But rather than switch to a hard error for this code, let's
give a permerror so affected code can continue to work with -fpermissive.

PR c++/116634

gcc/cp/ChangeLog:

* init.cc (can_init_array_with_p): Allow PR59465 case with
permerror.

gcc/testsuite/ChangeLog:

* g++.dg/diagnostic/aggr-init1.C: Expect warning with -fpermissive.
* g++.dg/init/array62.C: Adjust diagnostic.
* g++.dg/init/array63.C: Adjust diagnostic.
* g++.dg/init/array64.C: Adjust diagnostic.

(cherry picked from commit 3545aab00152ed3db1d7ce6ca4e1671dde276980)

[Bug target/117416] [15 Regression] ICE: in gen_prefetch, at config/i386/i386.md:28541 with __builtin_ia32_prefetch() by r15-4833-ge9ab41b79933d4

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #6 from Hongtao Liu  ---
Fixed.

[Bug ada/70015] missing or additional call to finalizer depending on scope hierarchy

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #4 from Eric Botcazou  ---
Presumably fixed on the mainline.

[Bug ada/89493] [12/13/14/15 Regression] Stack smashing on armv7hl

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Eric Botcazou  ---
.

[Bug c/117445] ICE: in gimple_build_assign_1, at gimple.cc:480

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||101057
   Keywords||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
This is invalid gimple now:
  i_1 = val_2(D) > 0 ? i_6 : 0;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057
[Bug 101057] [gimplefe] GIMPLE frontend issues

[Bug c++/117446] New: Rejects valid code on template parameter packs not expanded with '...'

[suyuchang at whu dot edu.cn via Gcc-bugs]

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

Bug ID: 117446
   Summary: Rejects valid code on template parameter packs not
expanded with '...'
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suyuchang at whu dot edu.cn
  Target Milestone: ---

Input：

template < typename... X1 > struct [[ X1 ]] final { } ;


Output：
:1:45: error: parameter packs not expanded with '...':
1 | template < typename... X1 > struct [[ X1 ]] final { } ;
  | ^
:1:45: note: 'X1'
Compiler returned: 1

It is rejected by Clang, but accepted by GCC.

[Bug c++/117158] [12/13/14/15 Regression] ICE with array access inside a template with a base class since r10-3793-g1a37b6d9a7e57c

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

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

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

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

commit r15-4957-gb1d92aeb8583c8d1491c97703680c5fb88ed1fe4
Author: Simon Martin 
Date:   Tue Nov 5 10:07:42 2024 +0100

c++: Defer -fstrong-eval-order processing to template instantiation time
[PR117158]

Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid code
with -std=c++17 and above

=== cut here ===
struct Base {
  unsigned int *intarray;
};
template  struct Sub : public Base {
  bool Get(int i) {
return (Base::intarray[++i] == 0);
  }
};
=== cut here ===

The problem is that from c++17 on, we use -fstrong-eval-order and need
to wrap the array access expression into a SAVE_EXPR. We do so at
template declaration time, and end up calling contains_placeholder_p
with a SCOPE_REF, that it does not handle well.

This patch fixes this by deferring the wrapping into SAVE_EXPR to
instantiation time for templates, when the SCOPE_REF will have been
turned into a COMPONENT_REF.

PR c++/117158

gcc/cp/ChangeLog:

* typeck.cc (cp_build_array_ref): Only wrap array expression
into a SAVE_EXPR at template instantiation time.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/eval-order13.C: New test.
* g++.dg/parse/crash77.C: New test.

[Bug c++/117446] Rejects valid code on template parameter packs not expanded with '...'

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Yuchang Su from comment #0)
> It is rejected by Clang, but accepted by GCC.

Is this backwards? It's rejected by GCC, and gives a warning with clang.

[Bug c++/117101] [12/13/14/15 Regression] internal compiler error: Segmentation fault for operator new

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

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

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

https://gcc.gnu.org/g:5821f5c8c89a054e34cea00e042996dfdcd7e102

commit r15-4958-g5821f5c8c89a054e34cea00e042996dfdcd7e102
Author: Simon Martin 
Date:   Tue Nov 5 10:16:39 2024 +0100

c++: Don't crash upon invalid placement new operator [PR117101]

We currently crash upon the following invalid code (notice the "void
void**" parameter)

=== cut here ===
using size_t = decltype(sizeof(int));
void *operator new(size_t, void void **p) noexcept { return p; }
int x;
void f() {
int y;
new (&y) int(x);
}
=== cut here ===

The problem is that in this case, we end up with a NULL_TREE parameter
list for the new operator because of the error, and (1) coerce_new_type
wrongly complains about the first parameter type not being size_t,
(2) std_placement_new_fn_p blindly accesses the parameter list, hence a
crash.

This patch does NOT address #1 since we can't easily distinguish between
a new operator declaration without parameters from one with erroneous
parameters (and it's not worth the risk to refactor and break things for
an error recovery issue) hence a dg-bogus in new52.C, but it does
address #2 and the ICE by simply checking the first parameter against
NULL_TREE.

It also adds a new testcase checking that we complain about new
operators with no or invalid first parameters, since we did not have
any.

PR c++/117101

gcc/cp/ChangeLog:

* init.cc (std_placement_new_fn_p): Check first_arg against
NULL_TREE.

gcc/testsuite/ChangeLog:

* g++.dg/init/new52.C: New test.
* g++.dg/init/new53.C: New test.

[Bug c++/117101] [12/13/14/15 Regression] internal compiler error: Segmentation fault for operator new

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #4 from Simon Martin  ---
Fixed in GCC 15.

[Bug c++/117447] New: ICE in BPF GCC-trunk segmentation fault

[suyuchang at whu dot edu.cn via Gcc-bugs]

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

Bug ID: 117447
   Summary: ICE in BPF GCC-trunk segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suyuchang at whu dot edu.cn
  Target Milestone: ---

Inuput:

template < typename X1 > struct [ [ X2 :: X2 ( ) ... ] ] X3 { } ;

See Compiler Explorer:https://godbolt.org/z/8E1jY6vnY

Output:

:1:58: warning: 'X2::X2' scoped attribute directive ignored
[-Wattributes]
1 | template < typename X1 > struct [ [ X2 :: X2 ( ) ... ] ] X3 { } ;
  |  ^~
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_TYPE   | bpf_collect_enum_info
:1:65: internal compiler error: Segmentation fault
1 | template < typename X1 > struct [ [ X2 :: X2 ( ) ... ] ] X3 { } ;
  | ^
0x206ddad diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x208349e internal_error(char const*, ...)
???:0
0x1d9838e ctfc_get_strtab_len(ctf_container*, int)
???:0
0x17cb79a btf_ext_output
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

BPF GCC 13.3.0 compiles this code ok, but crash in BPF GCC-trunk.

[Bug tree-optimization/117448] New: gcc failed to optimize dividing to subtracting with simple assumption

[xiaohuba2021 at 163 dot com via Gcc-bugs]

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

Bug ID: 117448
   Summary: gcc failed to optimize dividing to subtracting with
simple assumption
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiaohuba2021 at 163 dot com
  Target Milestone: ---

The following code:

```
constexpr unsigned int mod = 998244353;
unsigned int add(unsigned int x, unsigned int y) {
[[assume(x < mod)]];
[[assume(y < mod)]];
return (x + y) % mod;
}
```

could be optimized to simply sum up x and y, and then subtract mod if
(x+y)>=mod. In fact, clang does such optimization even if -O2 is enabled.
However, it seems gcc failed to recognize that, and generated a bunch of
instructions to simulate dividing by multiplying and subtracting, even with -O3
enabled.

Godbolt link: https://godbolt.org/z/bn5avY8n3

g++ version:
```
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20241105/configure
--prefix=/opt/compiler-explorer/gcc-build/staging
--enable-libstdcxx-backtrace=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,objc,obj-c++,go,d,rust,m2 --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc-ad1f112980040ba7bb8b8d0b9273268d4d710c9e-binutils-2.42
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241105 (experimental)
(Compiler-Explorer-Build-gcc-ad1f112980040ba7bb8b8d0b9273268d4d710c9e-binutils-2.42)
 
```

[Bug c++/117129] [14/15 Regression] internal compiler error: Segmentation fault at gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int)

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

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

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

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

commit r15-4959-gf31b72b75ef7cde61469c774162db7b1cc4c3d03
Author: Simon Martin 
Date:   Tue Nov 5 10:44:34 2024 +0100

c++: Fix crash during NRV optimization with invalid input [PR117099,
PR117129]

PR117099 and PR117129 are ICEs upon invalid code that happen when NRVO
is activated, and both due to the fact that we don't consistently set
current_function_return_value to error_mark_node upon error in
finish_return_expr.

This patch fixes this inconsistency which fixes both cases since we skip
calling finalize_nrv when current_function_return_value is
error_mark_node.

PR c++/117099
PR c++/117129

gcc/cp/ChangeLog:

* typeck.cc (check_return_expr): Upon error, set
current_function_return_value to error_mark_node.

gcc/testsuite/ChangeLog:

* g++.dg/parse/crash78.C: New test.
* g++.dg/parse/crash78a.C: New test.
* g++.dg/parse/crash79.C: New test.

[Bug c++/117099] [14/15 Regression] internal compiler error: Segmentation fault in finalize_nrv(tree_node*, tree_node*)

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

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

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

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

commit r15-4959-gf31b72b75ef7cde61469c774162db7b1cc4c3d03
Author: Simon Martin 
Date:   Tue Nov 5 10:44:34 2024 +0100

c++: Fix crash during NRV optimization with invalid input [PR117099,
PR117129]

PR117099 and PR117129 are ICEs upon invalid code that happen when NRVO
is activated, and both due to the fact that we don't consistently set
current_function_return_value to error_mark_node upon error in
finish_return_expr.

This patch fixes this inconsistency which fixes both cases since we skip
calling finalize_nrv when current_function_return_value is
error_mark_node.

PR c++/117099
PR c++/117129

gcc/cp/ChangeLog:

* typeck.cc (check_return_expr): Upon error, set
current_function_return_value to error_mark_node.

gcc/testsuite/ChangeLog:

* g++.dg/parse/crash78.C: New test.
* g++.dg/parse/crash78a.C: New test.
* g++.dg/parse/crash79.C: New test.

[Bug tree-optimization/117439] [12/13/14/15 Regression] ICE in encode_tree_to_bitpos

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 59540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59540&action=edit
gcc15-pr117439-2.patch

Patch which honors the existing param on store merging region size.

[Bug fortran/117434] [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

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

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

--- Comment #7 from Iain Sandoe  ---
OK, so trying to understand if there is still an issue with trampolines ( as
noted before, AFAIU gfortran has been using trampolines for a very long time,
so one might expect to have seen fallout before ).

1. test conditions
  - the test case gfortran-reproducer.f90  from comment #1
  - Paul's patch from comment # 6 applied
  - optimisations O0 and O1

2. platforms 
  - x86_64-darwin, x86_64-linux

3. output checked
  - `-fdump-tree-optimized`
  - checked that the built program runs without producing any error or output.

4. observations (on x86_64-linux, so folks can reproduce on the compile farm
etc)

  - as Richi expected, when the optimisation level is >= O1 actually the whole
test is optimised away and we just get:

__attribute__((externally_visible))
integer(kind=4) main (integer(kind=4) argc, character(kind=1) * * argv)
{
  static integer(kind=4) options.0[7] = {10308, 16383, 0, 1, 1, 0, 31};

   [local count: 1073741824]:
  _gfortran_set_args (argc_2(D), argv_3(D));
  _gfortran_set_options (7, &options.0[0]);
  return 0;

}


  - however, for O0 we get a MAIN__ function which contains:
   :
  FRAME.3.FRAME_BASE.PARENT = 0B;
  __builtin_init_trampoline (&FRAME.3.test, test, &FRAME.3);
  _5 = __builtin_adjust_trampoline (&FRAME.3.test);
  _6 = (logical(kind=4) (*) (void)) _5;
  test.1_1 = _6;
  test.2 = test.1_1;
  test_description = new_test_description (&test.2);
  test_description ={v} {CLOBBER(eos)};
  return;

.. so is, indeed, using a trampoline to call via a pointer.

==

However on both Linux and Darwin that I tested on, this works exactly as
expected (the stack is made executable by the trampoline machinery) and the
test case executes fine.

Please could folks who saw an issue;
1. repeat the tests with the same conditions as above
2. report their platform results

[Bug fortran/116388] [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
(In reply to Tomáš Trnka from comment #3)
> (In reply to Paul Thomas from comment #2)
> > Do you want to apply the fix or shall I do the honours?
> 
> I'd love to do it, but I don't have commit access. So if I understand it
> correctly, I would have to send a patch to the mailing list and have someone
> else (you?) apply it for me. I wouldn't mind doing that to learn the
> procedure, but I don't want to waste your time (or anyone else's). So just
> please pick the way that's easiest for you.

I can easily do the job but I will credit you. I am taking the PR for the sake
of the audit trail.

Regards

Paul

[Bug c/117451] Miscompile with -00/1/2 and -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Keywords||wrong-code
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
Another -fstack-reuse= issue .

[Bug target/116623] [15 regression] regressions on arm-linux-gnueabihf since r15-1619-g3b9b8d6cfdf593

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Torbjorn Svensson :

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

commit r15-4966-ge152a734337a06ed085c2e6700f21cda9ca7ad17
Author: Torbjörn SVENSSON 
Date:   Sat Oct 19 18:08:01 2024 +0200

testsuite: arm: Relax register selection [PR116623]

Since r15-1619-g3b9b8d6cfdf, test5 and test8 fails due to that "ip"
might be used and r3 might be moved to another register for later
dereference.

gcc/testsuite/ChangeLog:

PR testsuite/116623
* gcc.target/arm/mve/dlstp-compile-asm-2.c: Align test5 and
test8 with changes in r15-1619-g3b9b8d6cfdf.

Signed-off-by: Torbjörn SVENSSON 

[Bug middle-end/117453] New: Miscompile with -O3 and -O0/1/2

[yunboni at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 117453
   Summary: Miscompile with -O3 and -O0/1/2
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

When compiled with -O0/1/2, its output is 0. With -O3, it's 4. 

It can be fixed with -fstack-reuse=none. 

```c
int printf(const char *, ...);
int a[6];
int b, j, o;
char c;
char d[11];
char *e;
short f, g;
short *h = &f;
int main() {
  char l[7];
  int i = 0;
  for (; i < 7; i++) {
{
  char n[10];
  int k = 15;
  char *m = n;
  e = d;
  while (k)
*e++ = k /= 10;
  while (e != d)
*m++ = *--e;
  *m++ = '\0';
  j = m - n - 1;
}
l[j] = 4;
  }
  g = l[2];
  *h = g;
  printf("%d\n", f);
  for (; b; o++) {
b = c;
if (c)
  b = a[b];
  }
}
```

Details can be found here: https://godbolt.org/z/Pqzr9rbno

[Bug middle-end/117453] Miscompile with -O3 and -O0/1/2

[yunboni at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #1 from Yunbo Ni  ---
I'm not sure if it is a duplicate case.

[Bug c/117445] ICE: in gimple_build_assign_1, at gimple.cc:480

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:3621d2ac22b75b154c2964c0db84b58be427f3a8

commit r15-4964-g3621d2ac22b75b154c2964c0db84b58be427f3a8
Author: Andrew Pinski 
Date:   Mon Nov 4 23:42:29 2024 -0800

c: gimplefe: Only allow an identifier before ? [PR117445]

Since r13-707-g68e0063397ba82, COND_EXPR/VEC_COND_EXPR has not
allowed a comparison as the first operand but the gimple front-end
was not updated for this change and you would error out later on.
An assert was added with r15-4791-gb60031e8f9f8fe which meant an ICE
would happen from the gimple FE.
This removes support for parsing of the `?:` expressions except for an
identifier.

Bootstrapped and tested on x86_64-linux-gnu.

gcc/c/ChangeLog:

PR c/117445
* gimple-parser.cc (c_parser_gimple_statement): Remove
support for comparisons before the querry (`?`) token.

Signed-off-by: Andrew Pinski 

[Bug c/117445] ICE: in gimple_build_assign_1, at gimple.cc:480

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed.

[Bug c++/117450] [DR1753] Allow ~decltype

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

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

--- Comment #1 from Andrew Pinski  ---
This is a dup ...

[Bug c++/117450] [DR1753] Allow ~decltype

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

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

--- Comment #2 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #1)
> This is a dup ...

Of?  I went through all the PRs with "decltype" in their title and didn't find
it.

[Bug fortran/117434] [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #10 from kargls at comcast dot net ---
(In reply to Iain Sandoe from comment #9)
> (In reply to kargls from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> > 
> 
> > /usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires executable stack
> > (because the .note.GNU-stack section is executable)
> 
> FAOD - does this actually prevent the executable from running - or is it
> that your platform is (correctly) pointing out that executable stack can be
> considered a security risk?
> 
> Perhaps your static linker has some option that would prevent that warning,
> is the man-page visible online?

The compiled executable still runs of my FreeBSD system.  I have

% which ld
/usr/local/bin/ld
% ld --version
GNU ld (GNU Binutils) 2.40

Looking at ld.info, I see a '-z execstack' option.

% gfcx -o z -z execstack y.f90
% ./z

No warning appears.  I also find

% gfcx -o z -z noexecstack -save-temps y.f90
% ./z

produces no warning and the compiled executable still run.

I suppose the question then comes down to where does the

.section.note.GNU-stack,"x",@progbits

come from in the z-y.s save-temps file.

[Bug middle-end/117451] [14/15 Regression] Miscompile with -00/1/2 and -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Miscompile with -00/1/2 and |[14/15 Regression]
   |-O3 |Miscompile with -00/1/2 and
   ||-O3
  Component|c   |middle-end
   Target Milestone|--- |14.3

[Bug fortran/117434] [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #12 from kargls at comcast dot net ---
(In reply to Iain Sandoe from comment #11)
> (In reply to kargls from comment #10)
> > I suppose the question then comes down to where does the
> > 
> > .section.note.GNU-stack,"x",@progbits
> > 
> > come from in the z-y.s save-temps file.
> 
> There's nothing unexpected here.
> 
> It comes from the requirements of the trampoline - which is used to call a
> nested function via a function pointer.
> 
> What (the GCC default) edition of the nested function support does is to
> build a small piece of executable code on the stack that is written from a
> template (but includes the runtime-variable addresses required to call the
> target function).
> 
> For some platforms use of executable stack is warned (what you see) and for
> some it's forbidden (e.g. arm64 Darwin).  In the case that we have a warning
> we can choose to filter it or suppress it.
> 
> If you consider that the warning should be treated as significant, then
> there's an alternate implementation for the trampoline which places the
> executable fragment on the heap (we can then regulate when that heap page is
> writeable to be mutually exclusive with when it's executable) - which
> provides a measure more of security than the blanket enable on the stack. 
> To use this means implementing a couple of builtin functions in libgcc and
> then dealing with enabling it.  I don't know exactly what would be required
> for *BSD .. but it's probably not wildly different from Linux or Darwin -
> and we've implemented it on both of those.

Thanks for the explanation.  This looks like something that would
need to be coordinated with FreeBSD toolchain developers.  The
default linker on FreeBSD is /usr/bin/ld, which is a symlink to 
ld.lld.

% ld.lld --version
LLD 18.1.6 (FreeBSD llvmorg-18.1.6-0-g1118c2e05e67-150) (compatible with
GNU linkers)

Its manual page also shows the -z option.  So, for now, users can
use the option suppress the warning.

[Bug middle-end/117453] [14/15 Regression] Miscompile with -O3 and -O0/1/2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|Miscompile with -O3 and |[14/15 Regression]
   |-O0/1/2 |Miscompile with -O3 and
   ||-O0/1/2
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Blocks||111843
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |14.3
   Last reconfirmed||2024-11-05

--- Comment #2 from Andrew Pinski  ---
Partition 1: size 10 align 1
n   l

It is fixed with my patch; that means the underlying issue is the same. Dup is
doing heavily lifting.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111843
[Bug 111843] [meta-bug] wrong-code due to -fstack-reuse=/clobbers

[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags

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

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

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

[Bug middle-end/117451] [14/15 Regression] Miscompile with -00/1/2 and -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
So this is a dup of bug 117426.

What is happening is sccp is rewriting some code to avoid undefined signed
integers but then that does not get optimized away in some cases.

-fno-tree-scev-cprop avoids the bug too.

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

[Bug middle-end/111843] [meta-bug] wrong-code due to -fstack-reuse=/clobbers

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

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

Bug 117451 Summary: [14/15 Regression] Miscompile with -00/1/2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117451

   What|Removed |Added

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

[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags

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

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

--- Comment #6 from Andrew Pinski  ---
What is happening is sccp is rewriting some code to avoid undefined signed
integers but then that does not get optimized away in some cases.

[Bug middle-end/117453] [14/15 Regression] Miscompile with -O3 and -O0/1/2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
So this is a dup of bug 117426.

What is happening is sccp is rewriting some code to avoid undefined signed
integers but then that does not get optimized away in some cases.

-fno-tree-scev-cprop avoids the bug too.

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

[Bug middle-end/111843] [meta-bug] wrong-code due to -fstack-reuse=/clobbers

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

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

Bug 117453 Summary: [14/15 Regression] Miscompile with -O3 and -O0/1/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117453

   What|Removed |Added

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

[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags

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

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

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

[Bug middle-end/117426] [14/15 Regression] Miscompile with different optimization flags

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> What is happening is sccp is rewriting some code to avoid undefined signed
> integers but then that does not get optimized away in some cases.

Note -fno-tree-scev-cprop avoids the bug too.

[Bug c++/117454] New: Template parameter hidden by base class name

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

Bug ID: 117454
   Summary: Template parameter hidden by base class name
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Darrell.Wright at gmail dot com
  Target Milestone: ---

There should be a warning when a template parameter name is hidden by a base
classes usage of it.  e.g

```
struct Base {
int Value = 42;
};

template 
struct Derived : Base {
int v = Value;
};

static_assert( Derived<66>{}.v == 66 );
```
Will fail to compile, the intent is clear.  This happens with any name it seems

```
#include 

struct Base {
using Type = int;
};

template 
struct Derived : Base {
Type field;
};

static_assert( std::is_same_v{}.field), double> );
```

However, if the Base is a dependent type the behaviour is reversed.  The user
fix is to change the template param name, but I think compilers should have a
warning for this here as the code is probably broken

[Bug c++/117454] Template parameter hidden by base class name

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
I thought -Wshadow would warn but it does not ...

[Bug c++/117454] Template parameter hidden by base class name

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Darrell Wright  ---
Thanks, yeah, I forgot to add that, I did try something like -Wall -Wextra
-pedantic -pedantic-errors -Wshadow -O1

[Bug c++/117450] New: [DR1753] Allow ~decltype

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

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

Bug ID: 117450
   Summary: [DR1753] Allow ~decltype
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

```
using T = int;

void
f (T n)
{
  n.~decltype(n)();
}
```

should probably be OK since .

[Bug c/101057] [gimplefe] GIMPLE frontend issues

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

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

Bug 117445 Summary: ICE: in gimple_build_assign_1, at gimple.cc:480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117445

   What|Removed |Added

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

[Bug fortran/117434] [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

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

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

--- Comment #11 from Iain Sandoe  ---
(In reply to kargls from comment #10)
> (In reply to Iain Sandoe from comment #9)
> > (In reply to kargls from comment #8)
> > > (In reply to Iain Sandoe from comment #7)
> > > 
> > 
> > > /usr/local/bin/ld: warning: /tmp/ccVWAwWh.o: requires executable stack
> > > (because the .note.GNU-stack section is executable)
> > 
> > FAOD - does this actually prevent the executable from running - or is it
> > that your platform is (correctly) pointing out that executable stack can be
> > considered a security risk?
> > 
> > Perhaps your static linker has some option that would prevent that warning,
> > is the man-page visible online?
> 
> The compiled executable still runs of my FreeBSD system.  I have
> 
> % which ld
> /usr/local/bin/ld
> % ld --version
> GNU ld (GNU Binutils) 2.40
> 
> Looking at ld.info, I see a '-z execstack' option.
> 
> % gfcx -o z -z execstack y.f90
> % ./z
> 
> No warning appears.  I also find
> 
> % gfcx -o z -z noexecstack -save-temps y.f90
> % ./z
> 
> produces no warning and the compiled executable still run.

OK So we have a way forward to add specs to suppress the warning if/when we
would want to do it.


> I suppose the question then comes down to where does the
> 
> .section.note.GNU-stack,"x",@progbits
> 
> come from in the z-y.s save-temps file.

There's nothing unexpected here.

It comes from the requirements of the trampoline - which is used to call a
nested function via a function pointer.

What (the GCC default) edition of the nested function support does is to build
a small piece of executable code on the stack that is written from a template
(but includes the runtime-variable addresses required to call the target
function).

For some platforms use of executable stack is warned (what you see) and for
some it's forbidden (e.g. arm64 Darwin).  In the case that we have a warning we
can choose to filter it or suppress it.

If you consider that the warning should be treated as significant, then there's
an alternate implementation for the trampoline which places the executable
fragment on the heap (we can then regulate when that heap page is writeable to
be mutually exclusive with when it's executable) - which provides a measure
more of security than the blanket enable on the stack.  To use this means
implementing a couple of builtin functions in libgcc and then dealing with
enabling it.  I don't know exactly what would be required for *BSD .. but it's
probably not wildly different from Linux or Darwin - and we've implemented it
on both of those.

[Bug c/117451] New: Miscompile with -00/1/2 and -O3

[yunboni at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 117451
   Summary: Miscompile with -00/1/2 and -O3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

When I compiled this code with O0/1/2 flag, its output is 94394. But with -O3,
it's 28858:

```c
int printf(const char *, ...);
char a;
int b, d, e, f;
char c[11];
int *l = &e;
int m(int p, char *p2) {
  char *g, *h = p2;
  if (p == 0)
;
  else {
g = c;
while (p) {
  *g++ = '0' + p % 10;
  p /= 10;
}
while (g != c)
  *h++ = *--g;
  }
  *h++ = '\0';
  return h - p2 - 1;
}
int q(int p) {
  char n[10];
  int o = m(p, n);
  return o;
}
int main() {
  int i, j, k;
  int r[3];
  for (; q(15) + f < 3; f++)
r[f] = 94394;
  for (; d <= 2; d++)
*l = r[0];
  i = 0;
  printf("%d\n", e);
  for (; i < 3; i++) {
j = 0;
for (; j < 2; j++) {
  k = 0;
  for (; k < 4; k++)
if (b)
  printf(&a);
}
j = 0;
for (; j < 8; j++)
  if (b)
printf(&a);
  }
}
```

Details can be found here: https://godbolt.org/z/8rvdq5osE

[Bug c++/117450] [DR1753] Allow ~decltype

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This is a dup ...
> 
> Of?  I went through all the PRs with "decltype" in their title and didn't
> find it.

PR 77815 .

[Bug target/117452] New: ICE: in patch_jump_insn, at cfgrtl.cc:1303 with -Ofast -mavx10.2 and __bf16

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117452
   Summary: ICE: in patch_jump_insn, at cfgrtl.cc:1303 with -Ofast
-mavx10.2 and __bf16
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Ofast -mavx10.2 testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303
9 | }
  | ^
0x2c9f89e internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0xe85439 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1696
0x766002 patch_jump_insn
/repo/gcc-trunk/gcc/cfgrtl.cc:1303
0x1058b22 redirect_branch_edge
/repo/gcc-trunk/gcc/cfgrtl.cc:1330
0x1059112 rtl_redirect_edge_and_branch
/repo/gcc-trunk/gcc/cfgrtl.cc:1463
0x1042559 redirect_edge_and_branch(edge_def*, basic_block_def*)
/repo/gcc-trunk/gcc/cfghooks.cc:392
0x29a5734 try_forward_edges
/repo/gcc-trunk/gcc/cfgcleanup.cc:561
0x29a8ab3 try_optimize_cfg
/repo/gcc-trunk/gcc/cfgcleanup.cc:2931
0x29a8ab3 cleanup_cfg(int)
/repo/gcc-trunk/gcc/cfgcleanup.cc:3143
0x103f400 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:7071
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug c++/117158] [12/13/14/15 Regression] ICE with array access inside a template with a base class since r10-3793-g1a37b6d9a7e57c

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Simon Martin
:

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

commit r12-10804-g5fdd38d576c20d5a337b5c7d14108981d0751434
Author: Simon Martin 
Date:   Tue Nov 5 10:07:42 2024 +0100

c++: Defer -fstrong-eval-order processing to template instantiation time
[PR117158]

Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid code
with -std=c++17 and above

=== cut here ===
struct Base {
  unsigned int *intarray;
};
template  struct Sub : public Base {
  bool Get(int i) {
return (Base::intarray[++i] == 0);
  }
};
=== cut here ===

The problem is that from c++17 on, we use -fstrong-eval-order and need
to wrap the array access expression into a SAVE_EXPR. We do so at
template declaration time, and end up calling contains_placeholder_p
with a SCOPE_REF, that it does not handle well.

This patch fixes this by deferring the wrapping into SAVE_EXPR to
instantiation time for templates, when the SCOPE_REF will have been
turned into a COMPONENT_REF.

PR c++/117158

gcc/cp/ChangeLog:

* typeck.cc (cp_build_array_ref): Only wrap array expression
into a SAVE_EXPR at template instantiation time.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/eval-order13.C: New test.
* g++.dg/parse/crash77.C: New test.

(cherry picked from commit b1d92aeb8583c8d1491c97703680c5fb88ed1fe4)

[Bug sanitizer/92589] heuristic to avoid flexible array members too liberal

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

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

--- Comment #9 from Kees Cook  ---
With -fstrict-flex-arrays=3 this problem goes away. Closing the bug.

[Bug c++/69698] [meta-bug] flexible array members

[kees at outflux dot net via Gcc-bugs]

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

Bug 92589 Summary: heuristic to avoid flexible array members too liberal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589

   What|Removed |Added

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

[Bug c++/117454] Template parameter hidden by base class name

[Darrell.Wright at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Darrell Wright  ---
#include 

struct Base {
using Type = int;
};

template 
struct Derived : Base {
Type field;
};

static_assert( std::is_same_v{}.field), double> ); 

I think this should warn too, the intent is clear and the user hopefully gets a
conversion warning/error.

[Bug c++/105828] [meta-bug] bogus/missing -Wshadow

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |NEW

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

[Bug c++/117454] Template parameter hidden by base class name

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug fortran/115070] [13 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #15 from Paul Thomas  ---
Fixed on all three affected branches.

Thanks for the report.

Paul

[Bug middle-end/117456] ICE: in expand_expr_real_2, at expr.cc:10567 with __builtin_stdc_rotate_left() on bitfield or _BitInt() of non-mode size

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

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

--- Comment #2 from Andrew Pinski  ---
The assert after all:
  gcc_assert (VECTOR_MODE_P (TYPE_MODE (type))
  || type_has_mode_precision_p (type));
  /* fall through */

[Bug middle-end/117456] ICE: in expand_expr_real_2, at expr.cc:10567 with __builtin_stdc_rotate_left() on bitfield or _BitInt() of non-mode size

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-05
 Ever confirmed|0   |1
Summary|ICE: in expand_expr_real_2, |ICE: in expand_expr_real_2,
   |at expr.cc:10567 with   |at expr.cc:10567 with
   |__builtin_stdc_rotate_left( |__builtin_stdc_rotate_left(
   |) on bitfield or _BitInt()  |) on bitfield or _BitInt()
   ||of non-mode size
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
Confirmed. The middle-end does not know how to handle [LR]ROTATE_EXPR for
!type_has_mode_precision_p types. We have a check in simplify_rotate about this
already:
  /* Only create rotates in complete modes.  Other cases are not
 expanded properly.  */
  if (!INTEGRAL_TYPE_P (rtype)
  || !type_has_mode_precision_p (rtype))
return false;


I wonder if we should have a check in tree-cfg.cc in verify_gimple for this too
to catch it before expand.

[Bug target/117460] New: riscv64 backend emits large relocations due to loop strength reduction

[aurelien at aurel32 dot net via Gcc-bugs]

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

Bug ID: 117460
   Summary: riscv64 backend emits large relocations due to loop
strength reduction
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

The following code, extracted from lziprecover 1.25~pre1, and compiled with -O2
-mcmodel=medany causes the riscv backend to emit out of range relocation due to
loop strength reduction, whcih then cause issues at link time:


#include 
#include 

bool foo(const char *const arg) {
const char *const target = "foo";
if (arg[0] == target[0]) {
for (int i = 1; i < INT_MAX; ++i) {
if (arg[i] == 0) return true;
if (arg[i] != target[i]) break;
}
}
return false;
}

See how both side of the loop, 1 and INT_MAX, end up in the generated code:

.L9:
addia0,a0,1
lla a5,.LC0+1
lla a2,.LC0+2147483647
j   .L3


(Thanks to Jessica Clarke for helping understanding the issue)

[Bug middle-end/117459] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 with __builtin_assoc_barrier() on _BitInt(255)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-05
 Status|UNCONFIRMED |NEW

[Bug middle-end/117459] ICE: in lower_stmt, at gimple-lower-bitint.cc:5714 with __builtin_assoc_barrier() on _BitInt(255)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu
   ||aarch64*-*-*
   Host|x86_64-pc-linux-gnu |

--- Comment #1 from Andrew Pinski  ---
Confirmed. I wonder if we should ignore __builtin_assoc_barrier/PAREN_EXPR for
ANY_INTEGRAL_TYPE.

[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

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

[Bug target/117460] riscv64 backend emits large relocations due to loop strength reduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug fortran/117455] New: ld warning about executable stack, follows from PR 117434

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

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

Bug ID: 117455
   Summary: ld warning about executable stack, follows from PR
117434
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

When compiling the test case from PR117434 here:

module julienne_test_description_m
  implicit none

  abstract interface
logical function test_function_i()
end function
  end interface

  type test_description_t
procedure(test_function_i), pointer, nopass :: test_function_
  end type

contains

  type(test_description_t) function new_test_description(test_function)
procedure(test_function_i), intent(in), pointer :: test_function
new_test_description%test_function_ => test_function
  end function

end module

  use julienne_test_description_m
  implicit none
  type(test_description_t) test_description

  test_description = new_test_description(test)

contains

  logical function test()
test = .true.
  end function

end

Tests here on x86-64-linux-gnu, Fedora 40.

Using the patch from 117434 applied the resulting executable runs with no
error. An warning occurs from ld when compiling:

$ gfc test1.f90 
/usr/bin/ld: warning: /tmp/ccHdNOP8.o: requires executable stack (because the
.note.GNU-stack section is executable)
$ gfc -g test1.f90 
/usr/bin/ld: warning: /tmp/ccxn0UoQ.o: requires executable stack (because the
.note.GNU-stack section is executable)
$ ./a.out

$ gfc -O test1.f90 
$ gfc test1.f90 
/usr/bin/ld: warning: /tmp/ccB9TQqp.o: requires executable stack (because the
.note.GNU-stack section is executable)

$ gfc -O0 test1.f90 
/usr/bin/ld: warning: /tmp/cc84FpAG.o: requires executable stack (because the
.note.GNU-stack section is executable)

Evidently there is some difference between -O and -O0

[Bug c++/101463] [12/13/14 Regression] Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call

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

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

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

https://gcc.gnu.org/g:124f2f62e01c6f110279608ad09e0f1d378e4899

commit r14-10890-g124f2f62e01c6f110279608ad09e0f1d378e4899
Author: Patrick Palka 
Date:   Tue Nov 5 15:18:26 2024 -0500

c++: reference variable as default targ [PR101463]

Here during default template argument substitution we wrongly consider
the (substituted) default arguments v and vt as value-dependent
which ultimately leads to deduction failure for the calls.

The bogus value_dependent_expression_p result aside, I noticed
type_unification_real during default targ substitution keeps track of
whether all previous targs are known and non-dependent, as is the case
for these calls.  And in such cases it should be safe to avoid checking
dependence of the substituted default targ and just assume it's not.
This patch implements this optimization for GCC 14, which lets us accept
both testcases by sidestepping the value_dependent_expression_p issue
altogether.  (Note that for GCC 15 we fixed this differently, see
r15-3038-g5348e3cb9bc99d.)

PR c++/101463

gcc/cp/ChangeLog:

* pt.cc (type_unification_real): Avoid checking dependence of
a substituted default template argument if we can assume it's
non-dependent.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/nontype6.C: New test.
* g++.dg/cpp1z/nontype6a.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/101463] [12/13 Regression] Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] Using |[12/13 Regression] Using a
   |a constexpr variable|constexpr variable template
   |template specialization as  |specialization as default
   |default argument for|argument for non-type
   |non-type template parameter |template parameter of
   |of reference type leads gcc |reference type leads gcc to
   |to reject function call |reject function call

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14.3 and 15 so far.

[Bug rtl-optimization/117456] New: ICE: in expand_expr_real_2, at expr.cc:10567 with __builtin_stdc_rotate_left() on bitfield or _BitInt()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117456
   Summary: ICE: in expand_expr_real_2, at expr.cc:10567 with
__builtin_stdc_rotate_left() on bitfield or _BitInt()
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:8:10: internal compiler error: in expand_expr_real_2, at
expr.cc:10567
8 |   return __builtin_stdc_rotate_left (b.u, 1);
  |  ^~
0x2c9f89e internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0xe85439 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1696
0x795447 expand_expr_real_2(separate_ops const*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.cc:10567
0x1179ff3 expand_expr_real_gassign(gassign*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:11146
0x1036b49 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:4047
0x1036b49 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4111
0x103d15e expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6167
0x103ee47 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6906
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug fortran/117442] [15 Regression] Cannot build libgfortran with enable-gather-detailed-mem-stats after r15-4760-g0b73e9382ab51c

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r15-4969-g8c4184682d1cdfc43296f9550a48eaadb7501bbd
Author: David Malcolm 
Date:   Tue Nov 5 18:30:39 2024 -0500

fortran: dynamically allocate error_buffer [PR117442]

PR fortran/117442 reports a crash on exit of f951 when configured
with --enable-gather-detailed-mem-stats.

The crash happens if any diagnostics were ever buffered into
error_buffer.  The root cause is that error_buffer is statically
allocated and thus has a non-trivial destructor called at exit.
If error_buffer's diagnostic_buffer ever buffered anything, then
a diagnostic_per_format_buffer will have been created for the
buffer per-output-sink, and the destructors for these call
into the mem-stats subsystem, which has already beeen cleaned up.

The simplest fix is to allocate error_buffer on the heap, rather
that statically, which fixes the crash.

There's a comment about error_buffer:

  /* pp_error_buffer is statically allocated.  This simplifies memory
 management when using gfc_push/pop_error. */

added by Manu in r6-1748-g5862c189c2c3c2 while fixing PR fortran/66528.
The comment appears to be out of date.  I've tested maxerrors.f90 under
valgrind, and it's clean with the patch.

gcc/fortran/ChangeLog:
PR fortran/117442
* error.cc (error_buffer): Convert to a pointer so it can be
heap-allocated.
(gfc_error_now): Update for error_buffer being heap-allocated.
(gfc_clear_error): Likewise.
(gfc_error_flag_test): Likewise.
(gfc_error_check): Likewise.
(gfc_push_error): Likewise.
(gfc_pop_error): Likewise.
(gfc_diagnostics_init): Allocate error_buffer on the heap, rather
than statically.
(gfc_diagnostics_finish): Delete error_buffer.

Signed-off-by: David Malcolm 

[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r15-4969-g8c4184682d1cdfc43296f9550a48eaadb7501bbd
Author: David Malcolm 
Date:   Tue Nov 5 18:30:39 2024 -0500

fortran: dynamically allocate error_buffer [PR117442]

PR fortran/117442 reports a crash on exit of f951 when configured
with --enable-gather-detailed-mem-stats.

The crash happens if any diagnostics were ever buffered into
error_buffer.  The root cause is that error_buffer is statically
allocated and thus has a non-trivial destructor called at exit.
If error_buffer's diagnostic_buffer ever buffered anything, then
a diagnostic_per_format_buffer will have been created for the
buffer per-output-sink, and the destructors for these call
into the mem-stats subsystem, which has already beeen cleaned up.

The simplest fix is to allocate error_buffer on the heap, rather
that statically, which fixes the crash.

There's a comment about error_buffer:

  /* pp_error_buffer is statically allocated.  This simplifies memory
 management when using gfc_push/pop_error. */

added by Manu in r6-1748-g5862c189c2c3c2 while fixing PR fortran/66528.
The comment appears to be out of date.  I've tested maxerrors.f90 under
valgrind, and it's clean with the patch.

gcc/fortran/ChangeLog:
PR fortran/117442
* error.cc (error_buffer): Convert to a pointer so it can be
heap-allocated.
(gfc_error_now): Update for error_buffer being heap-allocated.
(gfc_clear_error): Likewise.
(gfc_error_flag_test): Likewise.
(gfc_error_check): Likewise.
(gfc_push_error): Likewise.
(gfc_pop_error): Likewise.
(gfc_diagnostics_init): Allocate error_buffer on the heap, rather
than statically.
(gfc_diagnostics_finish): Delete error_buffer.

Signed-off-by: David Malcolm 

[Bug fortran/117442] [15 Regression] Cannot build libgfortran with enable-gather-detailed-mem-stats after r15-4760-g0b73e9382ab51c

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Sorry about the regression.  Should be fixed by the above patch.