[Bug fortran/119157] ice in gfc_enforce_clean_symbol_state, at fortran/symbol.cc:4459

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

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

--- Comment #5 from Thomas Koenig  ---
Reduced test case:

MODULE lmdif_module
   CONTAINS
  SUBROUTINE fdjac2 (fcn, m, n, x, fvec, fjac, ldfjac, iflag,   &
  epsfcn, wa)
  END SUBROUTINE fdjac2
  SUBROUTINE lmdif (fcn, m, n, x, fvec, ftol, xtol, gtol, maxfev,   &
  ipvt, qtf, wa1, wa2, wa3, wa4)
  EXTERNAL fcn
  DOUBLEPRECISION actred, delta, dirder, epsmch, fnorm, fnorm1, &
  sum, temp, temp1, temp2, xnorm, zero
  IF (nprint.gt.0) call fcn (m, n, x, fvec, iflag)
  END SUBROUTINE lmdif
END MODULE

[Bug fortran/119049] Procedures are mishandled in -fc-prototypes-external

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Koenig  ---
Fixed.

[Bug analyzer/119169] New: [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 119169
   Summary: [[gnu::nonnull_if_nonzero]] False negative of
-Wanalyzer-possible-null-argument with nonzero integer
constant expression
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

The most basic code that should trigger a -Wanalyzer-possible-null-argument
diagnostic with [[gnu::nonnull]], doesn't.  For comparison, similar
[[gnu::nonnull]] code does diagnose.


alx@devuan:~/tmp$ cat nonzero.c | grep -Tn ^
  1:#include 
  2:
  3:[[gnu::nonnull]]
  4:void f(void *);
  5:[[gnu::nonnull_if_nonzero(1, 2)]]
  6:void g(void *, int);
  7:
  8:int
  9:main(void)
 10:{
 11:void  *p;
 12:
 13:p = malloc(1);
 14:f(p);  // -Wanalyzer-possible-null-argument
 15:free(p);
 16:
 17:p = malloc(1);
 18:g(p, 1);
 19:free(p);
 20:}
alx@devuan:~/tmp$ gcc-15 -Wall -Wextra -fanalyzer -O3 -S nonzero.c 
nonzero.c: In function ‘main’:
nonzero.c:14:9: warning: use of possibly-NULL ‘p’ where non-null expected
[CWE-690] [-Wanalyzer-possible-null-argument]
   14 | f(p);  // -Wanalyzer-possible-null-argument
  | ^~~~
  ‘main’: events 1-2
   13 | p = malloc(1);
  | ^
  | |
  | (1) this call could return NULL
   14 | f(p);  // -Wanalyzer-possible-null-argument
  |  
  | |
  | (2) ⚠️  argument 1 (‘p’) from (1) could be NULL where non-null
expected
nonzero.c:4:6: note: argument 1 of ‘f’ must be non-null
4 | void f(void *);
  |  ^
alx@devuan:~/tmp$ sed -i 14s,^,//, nonzero.c 
alx@devuan:~/tmp$ gcc-15 -Wall -Wextra -fanalyzer -O3 -S nonzero.c 
alx@devuan:~/tmp$

[Bug analyzer/119169] [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
(In reply to Alejandro Colomar from comment #0)
> The most basic code that should trigger a -Wanalyzer-possible-null-argument
> diagnostic with [[gnu::nonnull]], doesn't.

Here I obviously meant [[gnu::nonnull_if_nonzero]].

[Bug analyzer/119169] [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

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

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

--- Comment #3 from Jakub Jelinek  ---
What gcc are you using?
With current trunk I get
~/src/gcc/obj26/gcc/xgcc -B ~/src/gcc/obj26/gcc/ -fanalyzer pr119169.c -isystem
include/ -S
pr119169.c: In function ‘main’:
pr119169.c:11:3: warning: use of possibly-NULL ‘p’ where non-null expected
[CWE-690] [-Wanalyzer-possible-null-argument]
   11 |   f (p);  // -Wanalyzer-possible-null-argument
  |   ^
  ‘main’: events 1-2
   10 |   p = malloc (1);
  |   ^~
  |   |
  |   (1) this call could return NULL
   11 |   f (p);  // -Wanalyzer-possible-null-argument
  |   ~
  |   |
  |   (2) ⚠️  argument 1 (‘p’) from (1) could be NULL where non-null
expected
pr119169.c:3:23: note: argument 1 of ‘f’ must be non-null
3 | [[gnu::nonnull]] void f (void *);
  |   ^
pr119169.c:15:3: warning: use of possibly-NULL ‘p’ where non-null expected
[CWE-690] [-Wanalyzer-possible-null-argument]
   15 |   g (p, 1);
  |   ^~~~
  ‘main’: events 1-3
   10 |   p = malloc (1);
  |   ^~
  |   |
  |   (1) this call could return NULL
..
   14 |   p = malloc (1);
  |   ~~
  |   |
  |   (2) this call could return NULL
   15 |   g (p, 1);
  |   
  |   |
  |   (3) ⚠️  argument 1 (‘p’) from (2) could be NULL where non-null
expected
pr119169.c:4:40: note: argument 1 of ‘g’ must be non-null
4 | [[gnu::nonnull_if_nonzero(1, 2)]] void g (void *, int);
  |^

[Bug fortran/119074] Mismatched arguments for external dummy argument not caught

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed.

[Bug fortran/119157] [15 Regression] ice in gfc_enforce_clean_symbol_state, at fortran/symbol.cc:4459

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Fixed.

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #2 from Alejandro Colomar  ---
(In reply to Andrew Pinski from comment #1)
> Suspended until this is approved by the C committee for the names.

Any comments on the feature itself?  It would be interesting to present a paper
that has already been reviewed, at least to some degree, by candidate
implementors.

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Alejandro Colomar from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Suspended until this is approved by the C committee for the names.
> 
> Any comments on the feature itself?  It would be interesting to present a
> paper that has already been reviewed, at least to some degree, by candidate
> implementors.

No comments from me; but I suspect others will but they are more likely address
it via WG14 rather than here.

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #4 from Alejandro Colomar  ---
(In reply to Andrew Pinski from comment #3)
> No comments from me; but I suspect others will but they are more likely
> address it via WG14 rather than here.

Thanks!  I've already requested an N number for the paper, so I'll present it
there soon.

[Bug tree-optimization/119166] [15 regression] ICE: SIGSEGV in get_load_store_type (tree-vect-stmts.cc:2711) with -O2 --param=vect-force-slp=0

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE: SIGSEGV in |[15 regression] ICE:
   |get_load_store_type |SIGSEGV in
   |(tree-vect-stmts.cc:2711)   |get_load_store_type
   |with -O2|(tree-vect-stmts.cc:2711)
   |--param=vect-force-slp=0|with -O2
   ||--param=vect-force-slp=0
   Target Milestone|--- |15.0

--- Comment #1 from Sam James  ---
This worked for me yesterday at r15-7875-gc207dcf393b864 and fails now with
r15-7908-g613f8ddbe3d7da.

[Bug middle-end/118457] OpenMP: refactor/move dispatch construct handling to get rid of "sorry"

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r15-7911-g44b1d52e2f4db57849ca54b63c52a687294b1793
Author: Sandra Loosemore 
Date:   Sun Mar 9 01:50:19 2025 +

OpenMP: Integrate dynamic selectors with dispatch argument handling
[PR118457]

Support for dynamic selectors in "declare variant" was developed in
parallel with support for the adjust_args/append_args clauses and the
dispatch construct; they collided in a bad way.  This patch fixes the
"sorry" for calls that need both by removing the adjust_args/append_args
code from gimplify_call_expr and invoking it from the new variant
substitution code instead.  It's handled as a tree -> tree transformation
rather than tree -> gimple because eventually this code may end up being
invoked from the front ends instead of the gimplifier (see PR115076).

gcc/ChangeLog
PR middle-end/118457
* gimplify.cc (modify_call_for_omp_dispatch): New, containing
code split from gimplify_call_expr and modified to emit tree
instead of gimple.  Remove the error for falling through to a call
to the base function.
(expand_variant_call_expr): New, split from
gimplify_variant_call_expr.
Call modify_call_for_omp_dispatch on calls to
variants in a dispatch construct context.
(gimplify_variant_call_expr): Make it call expand_variant_call_expr
to do the actual work.
(gimplify_call_expr): Remove sorry for calls involving both
dynamic/late selectors and adjust_args/append_args, and adjust
for new interface.  Move adjust_args/append_args code to
modify_call_for_omp_dispatch.
(gimplify_omp_dispatch): Add some comments.

gcc/testsuite/ChangeLog
PR middle-end/118457
* c-c++-common/gomp/adjust-args-6.c: Remove xfails and adjust
expected output.
* c-c++-common/gomp/append-args-5.c: Adjust expected output.
* c-c++-common/gomp/append-args-dynamic.c: New.
* c-c++-common/gomp/dispatch-11.c: Adjust expected output.
* gfortran.dg/gomp/dispatch-11.f90: Likewise.

[Bug middle-end/118457] OpenMP: refactor/move dispatch construct handling to get rid of "sorry"

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from sandra at gcc dot gnu.org ---
This is fixed now.

[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'

[ulinl--- via Gcc-bugs]

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

--- Comment #5 from Uwe Lohmann  ---
The code compilation with the option -mint8 is different.

Compilation without -mint8
(avr-gcc -Os -fwhole-program -mrelax -Wall -Wextra --save-temps -mmcu=avr25
-DF_CPU=100 main.c -o main.elf)

cutout of attachment: main.elf-main.s_without_-mint8

main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(24999)
ldi r25,hi8(24999)
1:  sbiw r24,1
brne 1b
rjmp .
nop
ldi r24,0
ldi r25,0
/* epilogue start */
ret


Compilation with -mint8
(avr-gcc -mint8 -Os -fwhole-program -mrelax -Wall -Wextra --save-temps
-mmcu=avr25 -DF_CPU=100 main.c -o main.elf)

cutout of attachment: main.elf-main.s_with_-mint8

main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(-96)
ldi r25,lo8(-122)
rcall __builtin_avr_delay_cycles
ldi r24,0
/* epilogue start */
ret

The same avr-gcc; the only difference is the option -mint8.

The avr-gcc was built with:
../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++,lto \
--disable-nls --disable-libssp --with-dwarf2

Why the compilation with the avr-gcc results in the different outputs?

[Bug libgcc/119151] [13/14/15 Regression] unwind-dw2-btree maintains separators wrong

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #60682|0   |1
is obsolete||

--- Comment #8 from Jakub Jelinek  ---
Created attachment 60685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60685&action=edit
gcc15-pr119151.patch

Updated patch with a testcase (so far just for the if (fence < base + size - 1)
btree_insert hunk, will need to find the right sequence of registers +
deregisters to trigger the second case.

[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'

[ulinl--- via Gcc-bugs]

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

--- Comment #3 from Uwe Lohmann  ---
Created attachment 60683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60683&action=edit
main.elf-main.s_without_-mint8

[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'

[ulinl--- via Gcc-bugs]

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

--- Comment #4 from Uwe Lohmann  ---
Created attachment 60684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60684&action=edit
main.elf-main.s_with_-mint8

[Bug target/119114] [14/15 regression] RISC-V: miscompile at -O3 since r14-4077-g86451305d8b

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

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

--- Comment #18 from Andrew Pinski  ---
(In reply to Robin Dapp from comment #17)
> > No you got it wrong.
> > _121 will either be -1 or 0. _11 should be -1 or 0 too.
> > So the question is what was the VEC_EXTRACT doing the right thing? Is it
> > 0/-1 or 0/1? 
> 
> I literally mentioned VEC_EXTRACT in the message directly below as well as
> specified that it's the sequence, not the negate...  But thanks for
> confirming.
> 
> And we are creating the vector to extract from directly in the expander so a
> sign extend won't help.  We'd need to
> 
>   rtx ones = gen_const_vec_duplicate (qimode, GEN_INT (-1));
> 
> in the BI expander.  But that breaks pr114668.c.  Need to think about it
> some more.

This is why I mentioned that maybe vec_extractbi's setting operand maybe
should be a BI subreg of QI. So you still get 0/1 in the QI and then that will
be sign extended (or zero extended) by the middle-end.

Something like:
```
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 92e6942b523..c484e9f3c70 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -1451,14 +1451,16 @@ (define_expand "vec_extractqi"

 ;; Same for a BImode but still return a QImode.
 (define_expand "vec_extractbi"
-  [(set (match_operand:QI0 "register_operand")
- (vec_select:QI
+  [(set (match_operand:BI0 "register_operand")
+ (vec_select:BI
(match_operand:VB_VLS 1 "register_operand")
(parallel
 [(match_operand  2 "nonmemory_operand")])))]
   "TARGET_VECTOR"
 {
-  emit_insn (gen_vec_extractqi (operands[0], operands[1], operands[2]));
+  rtl qir = gen_reg (QImode);
+  emit_insn (gen_vec_extractqi (qir, operands[1], operands[2]));
+  emit_move_insn (operands[0], gen_lowpart (BImode, qir));
   DONE;
 })

```

Note I didn't try this at all and I am not 100% sure BImode will work as a
subreg of QImode though.

[Bug fortran/119157] [15 Regression] ice in gfc_enforce_clean_symbol_state, at fortran/symbol.cc:4459

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Thomas Koenig :

https://gcc.gnu.org/g:90d9cdfa82d9a8d63e35d928e335719a495c79e3

commit r15-7909-g90d9cdfa82d9a8d63e35d928e335719a495c79e3
Author: Thomas Koenig 
Date:   Sat Mar 8 16:13:41 2025 +0100

Fix regression with -Wexternal-argument-mismatch.

The attached patch fixes an ICE regresseion where undo state was not
handled properly when generating formal from actual arguments, which
occurred under certain conditions with the newly introduced
-Wexternal-argument-mismatch option.

The fix is simple: When we are generating these symbols, we no
longer need to undo anything, so we can just remove them.
I had considered adding an extra optional argument, but decided
against it on code clarity grounds.

While looking at the code, I also saw that a member of gfc_symbol
introduced with my patch should be a bitfield of width 1.

gcc/fortran/ChangeLog:

PR fortran/119157
* gfortran.h (gfc_symbol): Make ext_dummy_arglist_mismatch a
one-bit bitfield
(gfc_pop_undo_symbol): Declare prototype.
* symbol.cc (gfc_pop_undo_symbol): New function.
* interface.cc (gfc_get_formal_from_actual_arglist): Call it
for artificially introduced formal variables.

gcc/testsuite/ChangeLog:

PR fortran/119157
* gfortran.dg/interface_57.f90: New test.

[Bug fortran/119136] Printing result of function that prints itself hangs

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement
 CC||tkoenig at gcc dot gnu.org

[Bug analyzer/119169] [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
I suspect your GCC is too old and lacks r15-7682-g206cb6c10589be. Please always
include the version in reports.

[Bug analyzer/119169] [[gnu::nonnull_if_nonzero]] False negative of -Wanalyzer-possible-null-argument with nonzero integer constant expression

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #4 from Alejandro Colomar  ---
(In reply to Sam James from comment #2)
> I suspect your GCC is too old and lacks r15-7682-g206cb6c10589be. Please
> always include the version in reports.

Hmmm, that's good news.  Thanks!  And sorry!


$ dpkg -l gcc-15 | tail -n1
ii  gcc-15 15-20250114-1 amd64GNU C compiler

[Bug c/119170] New: Add operators _Widthof, _Minof, _Maxof

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 119170
   Summary: Add operators _Widthof, _Minof, _Maxof
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

Hi,

I'm going to submit a proposal to the C Committee to add these three operators
with their obvious meaning.
We could maybe implement them as `__builtin_widthof` (with a trailing `__`
maybe?  maybe without `builtin_`?), `__builtin_minof`, `__builtin_maxof` for
now, and then present that as prior art.  I've already shown a draft to the
committee, and nobody has sent any messages opposing, and instead, I've seen
two members already be in favor.

The proposal is below.  Also, here's a link to my git repo where I keep track
of the proposal revisions:


Cheers,
Alex

---

Name
alx-0002r1 - Add operators _Widthof, _Minof, _Maxof

Principles
-   Codify existing practice to address evident deficiencies.

Category
New operators.

Author
Alejandro Colomar 

Cc: Martin Uecker 

History


r0 (2025-03-08):
-  Initial draft.

r1 (2025-03-08):
-  Fix typos.
-  Add link to git repository in History.

Description
Many projects need to invent their own macros for getting
information about a type.  Basic ones are WIDTHOF(), MAXOF(),
and MINOF(), which get the width of a type, the maximum value of
a type, and the minimum value of a type, respectively.

Here are my own implementations:

#define WIDTHOF(x)  (sizeof(x) * CHAR_BIT)
#define SMAXOF(T)   ((T) (T) 1 << (WIDTHOF(T) - 2)) - 1) << 1) +
1))
#define UMAXOF(T)   ((T) -1)
#define IS_SIGNED(x)  ((typeof(x)) -1 < 1)
#define MAXOF(T)((T) (IS_SIGNED(T) ? SMAXOF(T) : UMAXOF(T))
#define MINOF(T)((T) ~type_max(T))

As can be seen from my implementations, they are hard to write
correctly, and review.  Also, now that we have bit-precise
integers, one may want to get these to work with them, which
would make it even harder to implement them.

Also, since these are used more often in macros, we have the
added problem of macros expanding arguments more than once
(sometimes way more than once; sometimes resulting in macro
 expansions in the order of megabytes of text).

If these three were keywords, true operators, the compiler would
evaluate arguments exactly once, and would return the right
value, even for bit-precise integers.

Since these macros are typically used with type names --not
expressions--, this proposal suggests only allowing a type name
as the operand.  It is left as a matter of QoI if compilers want
to provide support for unary-expressions as with sizeof.

Proposed wording
Based on N3467.

6.4.2  Keywords
Add _Widthof, _Minof, _Maxof.

6.5.4.1  Unary operators :: General
@@ Syntax, p1, unary-expression
 alignof ( type-name )
+_Widthof ( type-name )
+_Minof ( type-name )
+_Maxof ( type-name )

6.5.4.5  :: The sizeof, _Lengthof, and alignof operators
@@ Title
-The sizeof, _Lengthof, and alignof operators
+The sizeof, _Lengthof, alignof, _Widthof, _Minof, and _Minof operators

@@ Constraints, append to p1
+The _Widthof, _Minof, and _Maxof operatorsbuiltin_
+shall be applied to a parenthesized integer type.

@@ Semantics, new p after p5
+The _Widthof operator yields the width (in bits) of its operand type.
+The operand is not evaluated,
+and the result is an integer constant expression.

@@ Semantics, new p after p5
+The _Minof and _Maxof operators yield
+the minimum and maximum value, respectively,
+that can be represented by the type of the operand type.
+The operand is not evaluated,
+and the result is an integer constant expression.

6.6.1  Constant expressions :: General
@@ Semantics, p8
 alignof expressions,
+_Widthof expressions,
+_Minof expressions,
+_Maxof expressions,
 and floating,
...
 _Lengthof operator,
-or alignof operator.
+alignof operator,
+_Widthof operator,
+_Minor operator,
+or _Maxof operator.

Update footnote 115?

@@ p10
 whose results are integer constant expressions,
-and alignof expressions.
+alignof expressions,
+_Widthof expressions,
+_Minof expressions,
  

[Bug fortran/119078] Abstract bind(c) interface should not be a global entity

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-08
 Ever confirmed|0   |1
   Keywords|needs-stdcheck  |
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Thomas Koenig  ---
I have not found anything in the standard which says this should
be illegal.

[Bug c/119170] Add operators _Widthof, _Minof, _Maxof

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2025-03-08
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Suspended until this is approved by the C committee for the names.

[Bug rtl-optimization/119171] New: [15 Regression] error: ‘asm’ operand has impossible constraints or there are not enough registers

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 119171
   Summary: [15 Regression] error: ‘asm’ operand has impossible
constraints or there are not enough registers
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, r15-7900-g622968990beee7 gave:

[hjl@gnu-tgl-3 pr119083]$ cat x.i
long current_stack_pointer;
void perf_ibs_event_update(void *);
void perf_ibs_handle_irq(void *perf_ibs)
{
  asm("" : "=D"(current_stack_pointer) : "D"(0));
  perf_ibs_event_update(perf_ibs);
}
[hjl@gnu-tgl-3 pr119083]$ make
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -S
x.i
x.i: In function ‘perf_ibs_handle_irq’:
x.i:5:3: error: ‘asm’ operand has impossible constraints or there are not
enough registers
5 |   asm("" : "=D"(current_stack_pointer) : "D"(0));
  |   ^~~
make: *** [Makefile:42: x.s] Error 1
[hjl@gnu-tgl-3 pr119083]$

[Bug rtl-optimization/119171] [15 Regression] error: ‘asm’ operand has impossible constraints or there are not enough registers

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Never mind

[Bug rtl-optimization/119171] [15 Regression] error: ‘asm’ operand has impossible constraints or there are not enough registers

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

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

--- Comment #2 from Andrew Pinski  ---
I can't reproduce it with r15-7902-ge8c2f3a427a96a


I tried
`-O2 -g0`
`-O2 -fPIE`
`-O2 -fstack-protector-all`
`-O2 -fPIE -fstack-protector-all`
`-O2 -m32`
`-O2 -fPIE -fstack-protector-all -m32`

[Bug tree-optimization/118922] [12/13/14/15 regression] Miscompile at -O2/3

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

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

--- Comment #20 from Andrew Pinski  ---
So the issue is empty_or_with_defined_p is true but the middle_bb has a phi in
it.
And that is the fix rather previous patch here.

[Bug tree-optimization/118922] [12/13/14/15 regression] Miscompile at -O2/3

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

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

--- Comment #21 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #20)
> So the issue is empty_or_with_defined_p is true but the middle_bb has a phi
> in it.
> And that is the fix rather previous patch here.

Note before r12-5300 the phi node detection would not be needed as equal would
be false, while maybe_equal_p  would be true, the check for
single_non_singleton_phi_for_edges would be false and the phi on the middle bb
would be unused so it would be safe to remove. 

Changing the definition of empty_or_with_defined_p to say no phi nodes for the
middle bb, might cause some missed optimization but that number is going to be
small as a different pass before should have removed the unused phi nodes in
the first place.

[Bug fortran/119078] Abstract bind(c) interface should not be a global entity

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

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

--- Comment #3 from Thomas Koenig  ---
And a dummy argument should not be global, either.

[Bug tree-optimization/118922] [12/13/14/15 regression] Miscompile at -O2/3

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

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

--- Comment #22 from Andrew Pinski  ---
Created attachment 60688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60688&action=edit
Fix which I am testing

[Bug testsuite/118597] [15 Regression] gcc.dg/vect/vect-fncall-mask.c fails since r15-6945-gea1deefe54ea1c

[vvinayag at arm dot com via Gcc-bugs]

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

vvinayag at arm dot com changed:

   What|Removed |Added

 CC||vvinayag at arm dot com

--- Comment #6 from vvinayag at arm dot com ---
(In reply to Thiago Jung Bauermann from comment #1)
> Our CI bisected it to commit r15-6945-gea1deefe54ea1c .
> 
> https://linaro.atlassian.net/browse/GNU-1503
> 
> It also detected that spec2k6 433.milc with -Os increased in size by 4% from
> 98540 to 102636 bytes.

These regressions in vect-fncall-mask.c are also present in the gcc-14 branch.
However, they seem to be passing in trunk now.

[Bug testsuite/118597] [15 Regression] gcc.dg/vect/vect-fncall-mask.c fails since r15-6945-gea1deefe54ea1c

[vvinayag at arm dot com via Gcc-bugs]

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

--- Comment #7 from vvinayag at arm dot com ---
These regressions in vect-fncall-mask.c are also present in gcc-14.
However they seem to be passing in trunk now.

[Bug fortran/119157] [15 Regression] ice in gfc_enforce_clean_symbol_state, at fortran/symbol.cc:4459

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

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm

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

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

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

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

commit r15-7906-gb360d4aafc1356386313c7392f7444b3fc356681
Author: Jason Merrill 
Date:   Thu Mar 6 12:39:36 2025 -0500

c++/modules: purview of explicit instantiations [PR114630]

When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
purview set based on the current value of module_kind.

This is unideal, however, as the modules code will then treat these
instantiations as reachable and cause large swathes of the GMF to be
emitted into the module CMI, despite no code in the actual module
purview referencing it.

This patch fixes this by setting DECL_MODULE_PURVIEW_P as appropriate when
we see an explicit instantiation, and adjusting module_kind accordingly
during deferred instantiation, meaning that GMF entities won't be counted
as reachable unless referenced by an actually reachable entity.

Note that purviewness and attachment etc. is generally only determined
by the base template: this is purely for determining whether an
explicit instantiation is in the module purview and hence whether it
should be streamed out.  See the comment on 'set_instantiating_module'.

Incidentally, since the "xtreme" testcases are deliberately large (and this
commit adds another one), let's make sure we only run them once.

PR c++/114630
PR c++/114795

gcc/cp/ChangeLog:

* pt.cc (reopen_tinst_level): Set or clear MK_PURVIEW.
(mark_decl_instantiated): Call set_instantiating_module.
(instantiate_pending_templates): Save and restore module_kind so
it isn't affected by reopen_tinst_level.

gcc/testsuite/ChangeLog:

* g++.dg/modules/modules.exp: Run xtreme tests once.
* g++.dg/modules/gmf-3.C: New test.
* g++.dg/modules/gmf-4.C: New test.
* g++.dg/modules/gmf-xtreme.C: New test.

Signed-off-by: Nathaniel Shead 
Co-authored-by: Nathaniel Shead 

[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot

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

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

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

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

commit r15-7906-gb360d4aafc1356386313c7392f7444b3fc356681
Author: Jason Merrill 
Date:   Thu Mar 6 12:39:36 2025 -0500

c++/modules: purview of explicit instantiations [PR114630]

When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
purview set based on the current value of module_kind.

This is unideal, however, as the modules code will then treat these
instantiations as reachable and cause large swathes of the GMF to be
emitted into the module CMI, despite no code in the actual module
purview referencing it.

This patch fixes this by setting DECL_MODULE_PURVIEW_P as appropriate when
we see an explicit instantiation, and adjusting module_kind accordingly
during deferred instantiation, meaning that GMF entities won't be counted
as reachable unless referenced by an actually reachable entity.

Note that purviewness and attachment etc. is generally only determined
by the base template: this is purely for determining whether an
explicit instantiation is in the module purview and hence whether it
should be streamed out.  See the comment on 'set_instantiating_module'.

Incidentally, since the "xtreme" testcases are deliberately large (and this
commit adds another one), let's make sure we only run them once.

PR c++/114630
PR c++/114795

gcc/cp/ChangeLog:

* pt.cc (reopen_tinst_level): Set or clear MK_PURVIEW.
(mark_decl_instantiated): Call set_instantiating_module.
(instantiate_pending_templates): Save and restore module_kind so
it isn't affected by reopen_tinst_level.

gcc/testsuite/ChangeLog:

* g++.dg/modules/modules.exp: Run xtreme tests once.
* g++.dg/modules/gmf-3.C: New test.
* g++.dg/modules/gmf-4.C: New test.
* g++.dg/modules/gmf-xtreme.C: New test.

Signed-off-by: Nathaniel Shead 
Co-authored-by: Nathaniel Shead 

[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'

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

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

--- Comment #6 from Georg-Johann Lay  ---
Still 2 issues:

* Your are configuring the compiler in a way not supported by GCC (see my note
above).

* Pre-processed files are still missing. You can get the i files with
-save-temps -g3.

With -g3, the i will show macro definitions, so maybe avr-libc is doing
something strange with __HAS_DELAY_CYCLES or __builtin_avr_delay_cycles.

Also notice that -mint8 is not supported in avr-libc except for stdint.h and
avr/pgmspace.h, so presumably you should report this against avr-libc.

I still cannot reproduce this in avr-gcc v5.4.0, v8, v11, v12, v13, v14, v15
(current trunk).

So what version of avr-libc are you using?  And are you configuring avr-libc
with avr-gcc v14.2 (otherwise you'll get garbage).

And are ou sure that in /usr/local/avr there are no remains of a previously
installed toolchain?

[Bug libgcc/119151] [13/14/15 Regression] unwind-dw2-btree maintains separators wrong

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

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

--- Comment #7 from Jakub Jelinek  ---
BTW, even if we had the size information on btree_remove, we could just
increase the separator during walk to base + size - 1 from base - 1.  But until
it reaches the leaf node, it doesn't know what the first existing entry after
it is, because the separator should be adjusted to that next's entry's base -
1.

Anyway, I worried a little about this increase of separators to base + size - 1
in case the next inner entry has separator lower than that, but I'd hope that
should never happen, as btree_remove shouldn't retain empty leafs nor empty
inner nodes at any level and btree_merge_node should aggressively merge with
adjacent node, or merge into parent, or move some entries to the left or right.

[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #6 from Jonathan Wakely  ---
We could add a pedwarn so users are made aware it's an extension. But that
might require significant changes to handling of NSDMIs to detect that
substitution fails because of the NSDMI (just guessing, I have no idea how we
handle them).

I've added the 'accepts-invalid' keyword, but since this is deliberate maybe it
should be 'diagnostic' instead.

[Bug tree-optimization/118922] [12/13/14/15 regression] Miscompile at -O2/3

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

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

--- Comment #19 from Andrew Pinski  ---
So looking into this further, this can only show up with loops and loops where
there is only one variable around it (and no load/stores either).

This is why:
```
  __BB(5):
  if (h_6 != 0)
goto __BB7;
  else
goto __BB6;

  __BB(6):
  h_6 = __PHI (__BB4: 0, __BB5: 1);
  goto __BB7;

  __BB(7):
  f_8 = __PHI (__BB5: 0, __BB6: h_6);
  _9 = f_8 ^ 1;
  _10 = a;
  _11 = _9 + _10;
  if (_11 != _Literal (int) -117)
goto __BB5;
  else
goto __BB8;
```

structure is impossible without a back-edge which BB7->BB5 is the back edge.

This also explains why it has only been seen with fuzziers and code in the wild
too.

Note I had been trying to create one where we could error out instead of
causing a timeout if the code is miscompiled but there is no way because of the
constraint of having one only PHI node for BB7 too.

As an aside my gimple testcase does not hit if we add startwith("phiopt2")
either because a pass that you can't disable decided to split a critial edge
and cleanup cfg is not called.

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

[andrew--- via Gcc-bugs]

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

--- Comment #31 from Andrew Clayton  ---
Thanks everyone, looking forward to putting this to use!

[Bug libgcc/119151] [13/14/15 Regression] unwind-dw2-btree maintains separators wrong

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #60685|0   |1
is obsolete||

--- Comment #9 from Jakub Jelinek  ---
Created attachment 60686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60686&action=edit
gcc15-pr119151.patch

Adjusted testcase which fails also if the second hunk in the patch is removed,
so tests both spots.

[Bug middle-end/119167] New: gimple testcase with startwith does not always get the same CFG as what was provided with

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

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

Bug ID: 119167
   Summary: gimple testcase with startwith does not always get the
same CFG as what was provided with
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 101057
  Target Milestone: ---

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

Take the attached testcase, we don't get the exact CFG structure as it is
supplied in phiopt2.

What we get is:
```
   :
  if (h_6 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  goto ; [100.00%]

   :

   :
  # h_6 = PHI <0(4), 1(9)>

   :
  # f_8 = PHI <0(10), h_6(6)>
```
Which looks like the critial edges were split.

This makes it harder to debug phiopt and other passes which need the exact same
CFG input that is done in the gimple testcase.

Note I don't mind if this is closed as won't fix but I am recording it so I can
point to it later on if needed.


Referenced Bugs:

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

[Bug target/119168] [15 Regression] 5% 477.dealII slowdown since r15-7605-gc5752c1f01316a

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

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

--- Comment #1 from Andrew Pinski  ---
This looks noisy benchmark to me ...

[Bug rtl-optimization/119168] New: [15 Regression] 5% 477.dealII slowdown since r15-7605-gc5752c1f01316a

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

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

Bug ID: 119168
   Summary: [15 Regression] 5% 477.dealII slowdown since
r15-7605-gc5752c1f01316a
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=291.140.0

there was a 5% exec time slowdown of the 477.dealII SPEC 2006 benchmark when
run with -O2 -march=native on an AMD Zen2 machine.
I bisected it to r15-7605-gc5752c1f01316a

commit c5752c1f01316ac26ec9cf8d171d68aea420a158
Author: Richard Sandiford 
Date:   Tue Feb 18 11:00:57 2025 +

late-combine: Tighten register class check [PR108840]

gcc.target/aarch64/pr108840.c has failed since r15-268-g9dbff9c05520
(which means that I really ought to have looked at it earlier).

The test wants us to fold an SImode AND into all shifts that use it.
This is something that late-combine is supposed to do, but:

(1) the pre-RA pass chickened out because of a register pressure check

(2) the post-RA pass can't handle it, because the shift uses are in
QImode and the sets are in SImode

Both are things that would be good to fix.  But (1) is particularly
silly.  The constraints on the AND have "rk" for the destination
(so allowing the stack pointer) and "r" for the first source.
Including the stack pointer made the destination seem more permissive
than the source.

The intention was instead to check whether there are any
*allocatable* registers in the destination class that aren't
present in the source.

That's enough for all tests but the last one.  The last one still
fails because combine merges the final shift with the move into
the hard return register, giving an arithmetic instruction with
a hard register destination.  Pre-RA late-combine currently punts
on those, again due to register pressure concerns.  That too is
something I'd like to relax, but not for GCC 15.  In the interim,
the best thing seems to be to disable combine for the test.

gcc/
PR rtl-optimization/108840
* late-combine.cc (late_combine::check_register_pressure):
Take only allocatable registers into account when checking
the permissiveness of register classes.

gcc/testsuite/
PR rtl-optimization/108840
* gcc.target/aarch64/pr108840.c: Run at -O2 but disable combine.

 gcc/late-combine.cc | 10 --
 gcc/testsuite/gcc.target/aarch64/pr108840.c |  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)


Btw, this benchmark has sped up a bit recently.  That was between

r15-7772-gdfdbad87aeb2de
r15-7895-gb191e8bdecf881

Maybe that was because of r15-7852-ge836d80374aa03a?  Anyway, now the benchmark
is almost at the same speed as with GCC 14.  See comparison with GCC 14 here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1051.140.0&plot.9=291.140.0&;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug rtl-optimization/119168] [15 Regression] 5% 477.dealII slowdown since r15-7605-gc5752c1f01316a

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

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

Filip Kastl  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/119077] gcc option -mint8 leads to undefined reference to `__builtin_avr_delay_cycles'

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

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

--- Comment #7 from Georg-Johann Lay  ---
...I can reproduce it with the following test case and v13:

#include 

extern void __builtin_avr_delay_cycles (uint32_t);

#include 

int main(void)
{
_delay_ms(100);
}

So the likely cause is that AVR-LibC used prototypes for built-ins, which you
should not do.  This was fixed in
https://github.com/avrdudes/avr-libc/commit/5e6f28bd436e6f9749ecc5bc47f9035f1c1e7423

[Bug libgcc/119151] [13/14/15 Regression] unwind-dw2-btree maintains separators wrong

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

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 60682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60682&action=edit
gcc15-pr119151.patch

I agree with your analysis and as I tried to write in the comment, I think it
can't be updated during btree_remove unless we walk the tree back to parent
(perhaps through recursion), so insertion seems to be the only spot this can be
fixed up.
I think we shouldn't fix the parent slot's separator in btree_insert though,
just the current slot's and fix up the parent slot's in btree_split_inner
as done in the attached patch.
So far tested just with your reproducer and I'm afraid I don't have any JIT
around which could stress test it, I think pretty much everything in GCC
testsuite just uses the .eh_frame_hdr based registration at least on targets
I'm routinely testing.

[Bug fortran/119157] [15 Regression] ice in gfc_enforce_clean_symbol_state, at fortran/symbol.cc:4459

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

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|ice in  |[15 Regression] ice in
   |gfc_enforce_clean_symbol_st |gfc_enforce_clean_symbol_st
   |ate, at |ate, at
   |fortran/symbol.cc:4459  |fortran/symbol.cc:4459
   Target Milestone|--- |15.0
   Keywords|needs-bisection,|ice-on-valid-code
   |needs-reduction |

--- Comment #6 from Thomas Koenig  ---
Further reduced:

MODULE lmdif_module
  implicit none
   CONTAINS
  SUBROUTINE lmdif (fcn, m)
EXTERNAL fcn
integer m
call fcn (m)
  END SUBROUTINE lmdif
END MODULE

[Bug c/67301] Documentation not too clear about using names for operands of inline-asm

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug sanitizer/56682] -fsanitize documentation

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0