[Bug target/113857] fmov should be used to zero the upper bits of the vector register

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Trying 10 -> 11:
   10: r104:V4SF=const_vector
   11: r104:V4SF=vec_merge(vec_duplicate(r107:SF),r104:V4SF,0x1)
  REG_DEAD r107:SF
Failed to match this instruction:
(set (reg:V4SF 104 [ _2 ])
(vec_merge:V4SF (vec_duplicate:V4SF (reg:SF 107 [ a ]))
(const_vector:V4SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x4
])
(const_int 1 [0x1])))


Same as PR 113858 and PR 117092.

[Bug target/113857] fmov should be used to zero the upper bits of the vector register

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/117092] [15 regression] gcc.target/aarch64/pr109072_1.c check-function-bodies s16x4_2 fail since r15-4235-gbcccc3221b838e

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||113858

--- Comment #3 from Andrew Pinski  ---
So we get:
Trying 6 -> 13:
6: r104:V4HI=const_vector
   13: v0:V4HI=vec_merge(vec_duplicate(x0:HI),r104:V4HI,0x1)
  REG_DEAD x0:HI
  REG_DEAD r104:V4HI
Failed to match this instruction:
(set (reg/i:V4HI 32 v0)
(vec_merge:V4HI (vec_duplicate:V4HI (reg:HI 0 x0 [ x ]))
(const_vector:V4HI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1])))


The pattern in
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676106.html could be
extended to handle vec_duplicate here too. 

Both PR 113857 and bug 113858 has this same pattern.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113858
[Bug 113858] `ldr s0/h0/b0` should be used to zero extend into the full
register

[Bug libstdc++/115218] The conversion constructor of concat_view::iterator always default-constructs variant

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #2 from 康桓瑋  ---
(In reply to Patrick Palka from comment #1)
> Does this also mean the iterator's default ctor needs a
> default_initializable<_Vs...[0]> constraint?

The variant constructor already has such a constraint.

[Bug target/118936] [15 Regression] ICE in ix86_finalize_stack_frame_flags, at config/i386/i386.cc:8683

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Summary|[15 Regression]ICE in   |[15 Regression] ICE in
   |ix86_finalize_stack_frame_f |ix86_finalize_stack_frame_f
   |lags, at|lags, at
   |config/i386/i386.cc:8683|config/i386/i386.cc:8683

--- Comment #2 from Andrew Pinski  ---
This is a very very recent regression even. Feb 14th build didn't fail.

[Bug target/118935] Segmentation fault in 'libgomp.fortran/rwlock_1.f90' when compiling libgfortran with '-O0'

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Is this a target or a libgfortran bug, then?

[Bug c++/118920] ICE when importing memory and filesystem and a module-compiled system header importing memory

[f.b.brokken at rug dot nl via Gcc-bugs]

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

--- Comment #2 from Frank B. Brokken  ---
Dear pinskia at gcc dot gnu.org, you wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118920
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>See Also||https://gcc.gnu.org/bugzill
>||a/show_bug.cgi?id=104433
> 
> --- Comment #1 from Andrew Pinski  ---
> Can you try -fno-checking. I suspect this might be just a checking ICE which
> might not show up with release checking.

Interesting! If I specify -fno-checking no error is reported. So your
suggestion works. Certainly something for me to keep in mind. Do you think
that -fno-checking is only temporary needed or do you advise to use it when
errors like the 'canonical types differ...' error are reported by the
compiler? 

Thanks for your feedback :-)

Cheers,

[Bug c/118936] New: ICE in ix86_finalize_stack_frame_flags, at config/i386/i386.cc:8683

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

Bug ID: 118936
   Summary: ICE in ix86_finalize_stack_frame_flags, at
config/i386/i386.cc:8683
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 19373742 at buaa dot edu.cn
  Target Milestone: ---

Created attachment 60530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60530&action=edit
The preprocessed file

***
OS and Platform:
Ubuntu 20.04.4 LTS
***
GCC Release:
Using built-in specs.
COLLECT_GCC=./gcc-releases/bin/gcc
COLLECT_LTO_WRAPPER=/home/gcc-releases/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/gcc-releases/ --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250216 (experimental) (GCC) 
***
Command Lines:
# gcc  -O3 -fno-omit-frame-pointer -fno-toplevel-reorder a.c
***
during RTL pass: pro_and_epilogue
a.c: In function ‘func_40’:
a.c:1109:1: internal compiler error: in ix86_finalize_stack_frame_flags, at
config/i386/i386.cc:8683
 1109 | }
  | ^
0x25e720f internal_error(char const*, ...)
../.././gcc/diagnostic-global-context.cc:517
0xa202b5 fancy_abort(char const*, int, char const*)
../.././gcc/diagnostic.cc:1722
0x94c387 ix86_finalize_stack_frame_flags
../.././gcc/config/i386/i386.cc:8683
0x15a6480 ix86_expand_epilogue(int)
../.././gcc/config/i386/i386.cc:9984
0x1e0d0af gen_epilogue()
../.././gcc/config/i386/i386.md:20813
0x158edd5 target_gen_epilogue
../.././gcc/config/i386/i386.md:20311
0xd918a6 make_epilogue_seq
../.././gcc/function.cc:6029
0xd9199b thread_prologue_and_epilogue_insns()
../.././gcc/function.cc:6111
0xd92142 rest_of_handle_thread_prologue_and_epilogue
../.././gcc/function.cc:6627
0xd92142 execute
../.././gcc/function.cc:6713
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q (or without -quiet passed to cc1plus)

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Nate Eldredge from comment #6)
> After some brief digging, it seems like the problem is that
> `cxx_printable_name_internal` can be called recursively by `lang_decl_name'
> (via `announce_function').  This is bad because, with its static ring
> buffer, it's not reentrant.  In particular, at the site of the call to
> `lang_decl_name`
> (https://github.com/gcc-mirror/gcc/blame/
> 427386042f056a2910882bf0c632b4db68c52bbb/gcc/cp/tree.cc#L2770), the ring
> buffer is in an inconsistent state, as one of its entries has just been
> freed but not marked as invalid.  So a recursive call may think that entry
> is valid, and decide to free it again to make room for a new one.

In normal running there should be tsubst should NOT be called from
cxx_printable_name_internal . So the problem is NOT the ring buffer but rather
the call before hand.

[Bug c/118936] ICE in ix86_finalize_stack_frame_flags, at config/i386/i386.cc:8683

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 60531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60531&action=edit
The compiler output

[Bug target/115478] [15 Regression] gcc.target/aarch64/bitint-args.c fails since r15-1120-g2277f987979445

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r15-7615-gea3ebe48150d2109845f2c4622ebff182f618d97
Author: Xi Ruoyao 
Date:   Mon Feb 10 23:39:24 2025 +0800

LoongArch: Accept ADD, IOR or XOR when combining objects with no bits in
common [PR115478]

Since r15-1120, multi-word shifts/rotates produces PLUS instead of IOR.
It's generally a good thing (allowing to use our alsl instruction or
similar instrunction on other architectures), but it's preventing us
from using bytepick.  For example, if we shift a __int128 by 16 bits,
the higher word can be produced via a single bytepick.d instruction with
immediate 2, but we got:

srli.d  $r12,$r4,48
slli.d  $r5,$r5,16
slli.d  $r4,$r4,16
add.d   $r5,$r12,$r5
jr  $r1

This wasn't work with GCC 14, but after r15-6490 it's supposed to work
if IOR was used instead of PLUS.

To fix this, add a code iterator to match IOR, XOR, and PLUS and use it
instead of just IOR if we know the operands have no overlapping bits.

gcc/ChangeLog:

PR target/115478
* config/loongarch/loongarch.md (any_or_plus): New
define_code_iterator.
(bstrins__for_ior_mask): Use any_or_plus instead of ior.
(bytepick_w_): Likewise.
(bytepick_d_): Likewise.
(bytepick_d__rev): Likewise.

gcc/testsuite/ChangeLog:

PR target/115478
* gcc.target/loongarch/bytepick_shift_128.c: New test.

[Bug target/116594] [meta-bug] xtheadvector brokeness

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

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

Jin Ma  changed:

   What|Removed |Added

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

--- Comment #5 from Jin Ma  ---
Close

[Bug target/118935] New: Segmentation fault in 'libgomp.fortran/rwlock_1.f90' when compiling libgfortran with '-O0'

[chenglulu at loongson dot cn via Gcc-bugs]

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

Bug ID: 118935
   Summary: Segmentation fault in 'libgomp.fortran/rwlock_1.f90'
when compiling libgfortran with '-O0'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chenglulu at loongson dot cn
  Target Milestone: ---

When compiling libgfortran with the "-O0" option, using the compiled
libgfortran library to test 'libgomp.fortran/rwlock_1.f90' results in random
errors during the test.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xfffce8c86f in ???
#1  0x0 in ???

[Bug middle-end/113525] [12/13/14/15 Regression] GCC does not recognize "-fdump-rtl-sibling" command line option

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

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

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

https://gcc.gnu.org/g:3e93035fcc9247928b58443e37fbf844278b7ac7

commit r15-7614-g3e93035fcc9247928b58443e37fbf844278b7ac7
Author: Jeff Law 
Date:   Tue Feb 18 19:45:29 2025 -0700

[PR middle-end/113525] Drop obsolete options from documentation

The sibling and unshare passes were dropped as distinct passes 10+ years
ago.
Docs weren't ever updated.  This just removes them; given their age I don't
think we need to keep them around any longer.

PR middle-end/113525

gcc/
* doc/invoke.texi (dump-rtl-sibling): Drop documentation for pass
removed long ago.
(dump-rtl-unshare): Likewise.

[Bug target/118935] Segmentation fault in 'libgomp.fortran/rwlock_1.f90' when compiling libgfortran with '-O0'

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---
Upon debugging, it was discovered that if the '-O0' option is used to compile
the `find_file0` function in `libgfortran/io/unix.c`, random errors occur.
However, if the `find_file0` function is compiled with the '-O1' option, no
random errors arise.

The erroneous code is as follows:
libgfortran/io/unix.c
```
static gfc_unit *
find_file0 (gfc_unit *u, FIND_FILE0_DECL)
{
 ..
#ifdef HAVE_WORKING_STAT
  if (u->s != NULL)  // The input I provided next was: At this point, when
making the judgment, u->s is not NULL.
{
  unix_stream *s = (unix_stream *) (u->s);   
  if (st[0].st_dev == s->st_dev && st[0].st_ino == s->st_ino) // But here
it is NULL，u->s has been modified.
return u;
}
```
The corresponding LoongArch assembly code here is as follows.
```
ld.d$r12,$r3,8
ld.d$r12,$r12,8
beqz$r12,.L4   // Here, $r12 is not NULL.
ld.d$r12,$r3,8
ld.d$r12,$r12,8  // However, when reloaded, it has already become
NULL. 
st.d$r12,$r3,24
ldptr.d $r12,$r3,0
ldptr.d $r13,$r12,0
ld.d$r12,$r3,24
ld.d$r12,$r12,72
```

[Bug target/118935] Segmentation fault in 'libgomp.fortran/rwlock_1.f90' when compiling libgfortran with '-O0'

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #2 from chenglulu  ---
However, based on the code logic, I believe that the linked list `unit_root` in
the `find_file0` function should not be modified. I'm not sure if my
understanding is correct.
```
/* find_file()-- Take the current filename and see if there is a unit
   that has the file already open.  Returns a pointer to the unit if so. */

gfc_unit *
find_file (const char *file, gfc_charlen_type file_len)
{
  ..
  RDLOCK (&unit_rwlock);
retry:
  u = find_file0 (unit_root, FIND_FILE0_ARGS);
  if (u != NULL)
{
  /* Fast path.  */
  if (! __gthread_mutex_trylock (&u->lock))
{
  /* assert (u->closed == 0); */
  RWUNLOCK (&unit_rwlock);
  goto done;
}

  inc_waiting_locked (u);
}
  RWUNLOCK (&unit_rwlock);

```

[Bug other/118919] asan instrumented gcc: heap-use-after free in gcc/diagnostic-format-sarif.cc

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-02-18
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this.

The issue also shows up for me by running under valgrind; am taking a look...

[Bug target/113858] `ldr s0/h0/b0` should be used to zero extend into the full register

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

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

--- Comment #2 from Andrew Pinski  ---
(set (reg:V4HI 105 [ _4 ])
(vec_merge:V4HI (vec_duplicate:V4HI (reg:HI 106 [ *a_3(D) ]))
(const_vector:V4HI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1])))

[Bug target/118934] New: RISC-V: ICE: output_operand: invalid expression as operand

[anton at ozlabs dot org via Gcc-bugs]

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

Bug ID: 118934
   Summary: RISC-V: ICE: output_operand: invalid expression as
operand
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at ozlabs dot org
CC: kito.cheng at gmail dot com
  Target Milestone: ---

We are hitting an ICE when trying to build 521.wrf_r in cpu2017:

internal compiler error: output_operand: invalid expression as operand
0x314e986 internal_error(char const*, ...)
source/gcc/gcc/diagnostic-global-context.cc:517
0x106d9c5 output_operand_lossage(char const*, ...)
source/gcc/gcc/final.cc:3196
0x106e3b7 output_asm_insn(char const*, rtx_def**)
source/gcc/gcc/final.cc:3530
0x1071e23 output_asm_insn(char const*, rtx_def**)
source/gcc/gcc/final.cc:3427
0x1071e23 final_scan_insn_1
source/gcc/gcc/final.cc:2846
0x10722ff final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
source/gcc/gcc/final.cc:2892
0x10723ec final_1
source/gcc/gcc/final.cc:1983

Looking closer, gcc is calling output_addr_const() from output_asm_insn() with
a %nN template and rtx_code = LT which is not handled.

It made me suspect the recent change in the RISC-V backend where the %N
modifier was changed to %n. Is there a reason we are re-using a generic
modifier (%nN)?

Backing these three patches out fixes the issue:

fcbb8456a58ba073d4d5b10fcb9057b6e9a100db ("RISC-V: Add new constraint R for
register even-odd pairs")
2a22db391d1819f6068aa43e63632b350a0b4bec ("RISC-V: Implment N modifier for
printing the register number rather than the register name")
192790e994c9e15949e694e0a52010001b291611 ("RISC-V: Rename internal operand
modifier N to n")

[Bug target/117092] [15 regression] gcc.target/aarch64/pr109072_1.c check-function-bodies s16x4_2 fail since r15-4235-gbcccc3221b838e

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug target/78633] [12/13/14/15 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #31 from Jeffrey A. Law  ---
The actual bug was fixed long ago.

[Bug target/66358] [12/13/14/15 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #34 from Jeffrey A. Law  ---
Latent or possibly fixed.  Unclear.

[Bug target/65162] [12 Regression][SH] Redundant tests when storing bswapped T bit result in unaligned mem

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[12/13/14/15|[12 Regression][SH]
   |Regression][SH] Redundant   |Redundant tests when
   |tests when storing bswapped |storing bswapped T bit
   |T bit result in unaligned   |result in unaligned mem
   |mem |

--- Comment #16 from Jeffrey A. Law  ---
Adjusting regression markers.  It looks like this was effectively resolved in
the gcc-13 era.

[Bug rtl-optimization/56451] [12/13/14 regression] Wrong code for gcc.c-torture/execute/941015-1.c on SH

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[12/13/14/15 regression]|[12/13/14 regression] Wrong
   |Wrong code for  |code for
   |gcc.c-torture/execute/94101 |gcc.c-torture/execute/94101
   |5-1.c on SH |5-1.c on SH

--- Comment #22 from Jeffrey A. Law  ---
Test passes on the trunk, probably for a long time, but I'm not going to chase
it down.  Adjusting regression marker.

[Bug target/118892] [14/15 Regression] ICE (segfault) in rebuild_jump_labels on aarch64-linux-gnu since r14-5289

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

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

--- Comment #11 from Tamar Christina  ---
(In reply to Richard Sandiford from comment #10)
> (In reply to Tamar Christina from comment #9)
> > I swear that was something that was fixed.  But in any case, the simplest
> > fix is to force it into a reg again indeed.
> > 
> > I'm slightly worried that this then relies on the intermediate copy being
> > removed but such is life.
> This sounds like you're planning to use force_reg, but I agree with Andrew

No I wasn't. 

> that the patch in comment 6 is the right fix.  That will only create a new
> register if one is needed to satisfy subreg semantics.  The normal case will
> still avoid a temporary.

Yeah, but see, the thing is when this copysign patch was made you made me
change the subreg semantics to relax it.

My concern was simply that by forcing a new register here we're again back to,
at for this case, relying on reload to remove the mov. This wasn't a reliable
approach before because combine inserts those annoying moves that it doesn't
clean up.

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q (or without -quiet passed to cc1plus)

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #6 from Nate Eldredge  ---
After some brief digging, it seems like the problem is that
`cxx_printable_name_internal` can be called recursively by `lang_decl_name'
(via `announce_function').  This is bad because, with its static ring buffer,
it's not reentrant.  In particular, at the site of the call to `lang_decl_name`
(https://github.com/gcc-mirror/gcc/blame/427386042f056a2910882bf0c632b4db68c52bbb/gcc/cp/tree.cc#L2770),
the ring buffer is in an inconsistent state, as one of its entries has just
been freed but not marked as invalid.  So a recursive call may think that entry
is valid, and decide to free it again to make room for a new one.

The ring buffer design seems problematic under the circumstances.  Is caching
the printable name really an important optimization?  If so, then maybe a less
primitive caching structure, with more sensible lifetime management, would be
appropriate.

[Bug c++/118920] ICE when importing memory and filesystem and a module-compiled system header importing memory

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Frank B. Brokken from comment #2)
> Interesting! If I specify -fno-checking no error is reported. So your
> suggestion works. Certainly something for me to keep in mind. Do you think
> that -fno-checking is only temporary needed or do you advise to use it when
> errors like the 'canonical types differ...' error are reported by the
> compiler? 

It is a workaround for the trunk compiler. For a released GCC, the default
--enable-checking option is release while for the trunk compiler the default is
yes. I was trying to unblock you if you were blocked with this specific
internal compiler error (ICE).

[Bug c++/118923] New: Wrong code generated for member function pointer call in range-for loop

[kacper.slominski72 at gmail dot com via Gcc-bugs]

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

Bug ID: 118923
   Summary: Wrong code generated for member function pointer call
in range-for loop
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kacper.slominski72 at gmail dot com
  Target Milestone: ---

The following code, when compiled with `-O3 -std=c++23` for x86_64, produces
wrong assembly that unconditionally causes a call to NULL.

#include 

struct Workspace {
std::vector previousRestrictedMoveArea();
std::vector restrictedMoveArea();
bool inRearrange() {
return m_inRearrange;
}

bool m_inRearrange = false;

static Workspace _self;
};

inline Workspace *workspace() {
return &Workspace::_self;
}

void foo() {
auto moveAreaFunc = workspace()->inRearrange() ?
&Workspace::previousRestrictedMoveArea :
&Workspace::restrictedMoveArea;

for (const int &r : (workspace()->*moveAreaFunc)()) {
}
}


Bad fragment of the generated assembly:
leaq_ZN9Workspace5_selfE(%rip), %rsi
xorl%eax, %eax
movq%rsp, %rdi
call*%rax


Originally found in KWin, then reduced from there.

[Bug debug/118221] gdb and objdump referencing functions that do not exist in binary

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

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

--- Comment #10 from Richard Earnshaw  ---
Fixing this properly would require rewriting all of GCC's dwarf output code so
that each function in a separate section had its own debug data (and perhaps
using section groups to describe the relationships).  Then, when a function is
eliminated during linking, its debug data could be discarded as well.

That's a lot of work though, with very few users who would really benefit.

A quick-and-dirty hack would be to have an option to the linker to tell it to
point the dead debug info to a different address, somewhere that isn't mapped
into the program; though gdb might need to be taught what that address is as
well.

[Bug other/118802] [15 regression] Bootstrap comparison failure on libphobos/libdruntime/core/internal/gc/impl/conservative/gc.o

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

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

--- Comment #11 from Sam James  ---
```
--- stage2-gc.d.010t.omplower   2025-02-18 17:37:52.789497648 +
+++ stage3-gc.d.010t.omplower   2025-02-18 17:38:00.421354601 +
@@ -5910,7 +5910,7 @@



-;; Function __xtoHash
(_D4core8internal2gc4impl12conservativeQw3Gcx9__xtoHashFNbNeKxSQCiQCgQCaQCaQByQCjQBoZm,
funcdef_no=124, decl_uid=3393, cgraph_uid=339, symbol_order=338)
+;; Function __xtoHash
(_D4core8internal2gc4impl12conservativeQw3Gcx9__xtoHashFNbNeKxSQCiQCgQCaQCaQByQCjQBoZm,
funcdef_no=124, decl_uid=3394, cgraph_uid=339, symbol_order=338)

 __attribute__((weak))
 ulong __xtoHash (const struct Gcx & p)
@@ -6274,7 +6274,7 @@



-;; Function __xopEquals
(_D4core8internal2gc4impl12conservativeQw3Gcx11__xopEqualsMxFKxSQCjQChQCbQCbQBzQCkQBpZb,
funcdef_no=123, decl_uid=3394, cgraph_uid=340, symbol_order=339)
+;; Function __xopEquals
(_D4core8internal2gc4impl12conservativeQw3Gcx11__xopEqualsMxFKxSQCjQChQCbQCbQBzQCkQBpZb,
funcdef_no=123, decl_uid=3395, cgraph_uid=340, symbol_order=339)

 __attribute__((weak))
 bool __xopEquals (const struct Gcx & this, const struct Gcx & p)
@@ -6539,7 +6539,7 @@



-;; Function __fieldDtor
(_D4core8internal2gc4impl12conservativeQw3Gcx11__fieldDtorMFNbNiZv,
funcdef_no=122, decl_uid=3395, cgraph_uid=341, symbol_order=340)
+;; Function __fieldDtor
(_D4core8internal2gc4impl12conservativeQw3Gcx11__fieldDtorMFNbNiZv,
funcdef_no=122, decl_uid=3396, cgraph_uid=341, symbol_order=340)

 __attribute__((weak))
 void __fieldDtor (struct Gcx & this)
```

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias

--- Comment #4 from Andrew Pinski  ---
But DSE removes the stores:
```
  Deleted dead store: # .MEM_26 = VDEF <.MEM_11>
typesD.4024[2] = 2;

  Deleted dead store: # .MEM_11 = VDEF <.MEM_24>
typesD.4024[1] = 1;

  Deleted dead store: # .MEM_24 = VDEF <.MEM_3>
typesD.4024[0] = 0;
```

Manually doing these stores are not removed though. So maybe there is oddity of
how SRA adds these assignments.
  # VUSE <.MEM_5(D)>
  SR.4_7 = *.LC0D_4043[0l];
  # VUSE <.MEM_5(D)>
  SR.5_8 = *.LC0D_4043[1l];
  # VUSE <.MEM_5(D)>
  SR.6_9 = *.LC0D_4043[2l];
...

  # .MEM_24 = VDEF <.MEM_3>
  typesD_4024[0l] = SR.4_7;
  # .MEM_11 = VDEF <.MEM_24>
  typesD_4024[1l] = SR.5_8;
  # .MEM_26 = VDEF <.MEM_11>
  typesD_4024[2l] = SR.6_9;

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #4 from Nate Eldredge  ---
Note for testing that the compiler doesn't crash when compiling only
bits/std.cc, or when a-std.ii and a-foo.ii are concatenated into a single file.
 It seems to be important that they are passed as separate files on the command
line.

I should also point out that the compiler is configured with --enable-checking.

[Bug target/118925] New: Comparison of the copy of a volatile register variable instead of the (register) variable

[ulinl--- via Gcc-bugs]

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

Bug ID: 118925
   Summary: Comparison of the copy of a volatile register variable
instead of the (register) variable
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ul...@t-online.de
  Target Milestone: ---

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

There is a circular buffer with 2 indices. The indices are modified in a ISR.
The circular buffer is empty if the both indices are equal.

uint8_t RxBuf[16];
volatile uint8_t RxHead;
volatile uint8_t RxTail;

   ...

while( RxHead == RxTail );  // wait until new char is in buffer (by ISR)


Works as expected as long as at least one index is not bound to a register <
r8.

For example: 
register volatile uint8_t RxHead asm ("r6");
register volatile uint8_t RxHead asm ("r7");

In this case:
while( RxHead == RxTail );

is compiled to the following code:

 :
   0:   96 2d   mov r25, r6
   2:   87 2d   mov r24, r7

0004 <.L2>:
   4:   98 17   cp  r25, r24
   6:   f1 f3   breq.-4 ; 0x4 <.L2>


The volatile register variable is copied to a temporary register (r25 or r24)
and only the temporary register is compared. If the ISR changes the indices (r6
or r7), this is not recognized.

This only applies to registers < r8. The same compiled with r8, r9 results:

 :
   0:   89 14   cp  r8, r9
   2:   f1 f3   breq.-4 ; 0x0 


GCC version and build flags:
$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/local/avr/lib/gcc/avr/14.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/14.2.0/lto-wrapper
Target: avr
Configured with: ../configure --prefix=/usr/local/avr --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.2.0 (GCC)

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

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

  Known to work||9.5.0
Summary|Wrong code at -O2 and above |[12/13/14/15 regression]
   |leading to uninitialized|Wrong code at -O2 and above
   |accesses on |leading to uninitialized
   |aarch64-linux-gnu   |accesses on
   ||aarch64-linux-gnu
  Known to fail||10.2.0

--- Comment #1 from Sam James  ---
On godbolt, 9.5 works, 10.2 fails.

[Bug sarif-replay/118926] New: sarif-replay doesn't output notifications

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

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

Bug ID: 118926
   Summary: sarif-replay doesn't output notifications
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: SARIF
  Severity: normal
  Priority: P3
 Component: sarif-replay
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

sarif-replay with the output from the plugin.exp crash tests emits empty
output.

The files in question have e.g. this in the invocation:

"toolExecutionNotifications": [{"locations": [{"physicalLocation":
{"artifactLocation": {"uri":
"/home/david/coding/gcc-newgit-more-taint/src/gcc/testsuite/gcc.dg/plugin/crash-test-ice-in-header.h"},
"region":
{"startLine": 5,
  
"startColumn": 3,
  
"endColumn": 16},
   
"contextRegion": {"startLine": 5,
   
  "snippet": {"text": "  inject_ice ();\n"}}},
   "logicalLocations": [{"name":
"test_inject_ice",

"fullyQualifiedName": "test_inject_ice",

"decoratedName": "test_inject_ice",
 "kind":
"function"}]}],
"message": {"text": "I'm sorry Dave, I'm afraid
I can't do that"},
"level": "error",
"properties": {"gcc/backtrace": {"frames":
[{"pc": "0x7f5679ec2362",

"function": "pass_crash_test::execute(function*)",

"filename":
"/home/david/coding/gcc-newgit-more-taint/src/gcc/testsuite/gcc.dg/plugin/crash_test_plugin.cc",

"lineno": 98}]}}}],


Presumably sarif-replay should do *something* for toolExecutionsNotifications
or toolConfigurationNotifications.

[Bug c++/118921] C++ frontend does not update CPP defined on GCC pragma optimize

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/48026] #pragma optimize ignored for C++ for preprocessor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Gwenole Beauchesne from comment #5)
> Created attachment 56811 [details]
> Proposed patch against trunk
> 
> Here is a proposed patch against trunk, which includes a fix for PR
> preprocessor/87299 (#pragma GCC target).

I came up with this patch independently but I will submit your patch as it has
testcases.

[Bug c++/48026] #pragma optimize ignored for C++ for preprocessor

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

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

[Bug c++/118927] New: "double free detected in tcache 2" with import std and -Q

[nate at thatsmathematics dot com via Gcc-bugs]

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

Bug ID: 118927
   Summary: "double free detected in tcache 2" with import std and
-Q
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nate at thatsmathematics dot com
  Target Milestone: ---

Created attachment 60523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60523&action=edit
Main source file foo.cc

I was trying to use gcc 15 trunk (commit 101e3101e) on arm64 gentoo (vm on
Apple M3) to compile the following code from a recent article by Stroustrup
(https://cacm.acm.org/blogcacm/21st-century-c/):

import std;  // make all of the standard library available
using namespace std;

int main()   // print unique lines from input

{unordered_map m;  // hash table
  for (string line; getline (cin,line); )
  if (m[line]++ == 0)
  cout<https://stackoverflow.com/questions/76154680/how-to-use-module-std-with-gcc, I
used

g++ -Q -std=c++20 -fmodules -fsearch-include-path bits/std.cc foo.cc

The compile fails with "free(): double free detected in tcache 2" and the
following backtrace:

0x259e35b internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x12a617b crash_signal
../../gcc/toplev.cc:322
0xb54343 cxx_printable_name_internal
../../gcc/cp/tree.cc:2768
0x12a6a3f announce_function(tree_node*)
../../gcc/toplev.cc:230
0x8ddd03 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.cc:18590
0x9feb17 maybe_clone_body(tree_node*)
../../gcc/cp/optimize.cc:585
0x9a8f87 post_load_processing
../../gcc/cp/module.cc:18834
0x9d81ef lazy_load_pendings(tree_node*)
../../gcc/cp/module.cc:20769
0xabd3a7 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
../../gcc/cp/pt.cc:10241
0xac04cf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:16549
0xac08bf tsubst_entering_scope
../../gcc/cp/pt.cc:10095
0xac08bf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:17092
0x93ea8f dump_template_bindings
../../gcc/cp/error.cc:596
0x933b6f dump_function_decl
../../gcc/cp/error.cc:1982
0x93fb27 decl_as_string(tree_node*, int)
../../gcc/cp/error.cc:3334
0x93fb27 lang_decl_name(tree_node*, int, bool)
../../gcc/cp/error.cc:3369
0xb5435b cxx_printable_name_internal
../../gcc/cp/tree.cc:2770
0x12a6a3f announce_function(tree_node*)
../../gcc/toplev.cc:230
0x8ddd03 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/cp/decl.cc:18590
0x9feb17 maybe_clone_body(tree_node*)
../../gcc/cp/optimize.cc:585

When -Q is omitted, the program compiles and runs correctly.

g++ -v output:

Using built-in specs.
COLLECT_GCC=/home/nate/do-not-backup/gcc-inst/bin/g++
COLLECT_LTO_WRAPPER=/home/nate/do-not-backup/gcc-inst/libexec/gcc/aarch64-unknown-linux-gnu/15.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../configure --enable-checking --enable-languages=c++
--prefix=/home/nate/do-not-backup/gcc-inst
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250218 (experimental) (GCC)

[Bug c++/118928] New: [15 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:8694

[larsbj at gullik dot org via Gcc-bugs]

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

Bug ID: 118928
   Summary: [15 Regression] ICE in cxx_eval_constant_expression,
at cp/constexpr.cc:8694
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsbj at gullik dot org
  Target Milestone: ---

Created attachment 60524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60524&action=edit
Preporossessed test file - reduced with cvise

g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc-15/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc/gcc-15
--enable-checking=release --enable-languages=c,c++,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250218 (experimental) (GCC)

Unreduced testcase works fine with GCC14. With test case it ends up in
parsing errors. GCC15 ends up with same backtrace with unreduced and
reduced testcase.

Compiler invocation and backtrace:

g++ -O testcase.ii  -c
testcase.ii: In constructor ‘constexpr std()’:
testcase.ii:15:8: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.cc:8694
   15 | struct {
  |^
0x224147f internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x7d18bd fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1722
0x78916d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8694
0x816077 cxx_eval_conditional_expression
../../gcc/gcc/cp/constexpr.cc:4024
0x816077 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8309
0x8151b2 cxx_eval_statement_list
../../gcc/gcc/cp/constexpr.cc:7119
0x8151b2 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8615
0x81498c cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8369
0x81665f cxx_eval_indirect_ref
../../gcc/gcc/cp/constexpr.cc:6038
0x81665f cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8092
0x81498c cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8369
0x816722 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:7935
0x81531b cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8099
0x81498c cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8369
0x81c34a cxx_eval_bare_aggregate
../../gcc/gcc/cp/constexpr.cc:5450
0x814923 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8326
0x816722 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:7935
0x81146a cxx_bind_parameters_in_call
../../gcc/gcc/cp/constexpr.cc:1907
0x81146a cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.cc:3059
0x8143d4 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:7809

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #1 from Nate Eldredge  ---
Created attachment 60525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60525&action=edit
Preprocessor output for foo.cc

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #2 from Nate Eldredge  ---
Created attachment 60526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60526&action=edit
Preprocessor output for std.cc

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #3 from Nate Eldredge  ---
Created attachment 60527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60527&action=edit
stderr output from compilation

[Bug c++/114913] "verify_gimple failed" due to addition of two constexpr strings

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095

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

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

--- Comment #17 from Vladimir Makarov  ---
The bug seems like wrong repeated interaction hard reg live range splitting and
inheritance.  I'll try to make a patch and hope to fix it on this week.

[Bug fortran/118932] Testcase gfortran.dg/binding_label_tests_34.f90 needs standard checking

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #0)
> I think then testcase as is conflicts with the current standard, which says
> about binding labels:

I think I wanted to say: "the intention of the testcase is to check that
gfortran rejects the testcase, but the testcase likely is consistent with
the current standard, ..."

[Bug c++/118928] [15 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:8694

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Last reconfirmed||2025-02-18
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r15-6052.

[Bug sarif-replay/118926] sarif-replay doesn't output notifications

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

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

--- Comment #1 from David Malcolm  ---
Example of such a .sarif file can be seen at
https://github.com/davidmalcolm/sarif-examples/blob/main/valid/2.1.0/gcc/3.20.21-ice.sarif
(and the other "ice" files)

[Bug c++/110822] ICE on constexpr initialized with non-constant expression also accepts-invalid

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug other/118802] [15 regression] Bootstrap comparison failure on libphobos/libdruntime/core/internal/gc/impl/conservative/gc.o

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

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

--- Comment #8 from Sam James  ---
At least I can reproduce it consistently with:
```
cd
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime

# build stage2 gc
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage2-gcc/gdc
-B/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage2-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/../lib/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
-isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -fversion=Shared
-Wall -frelease -ffunction-sections -fdata-sections -fcf-protection -mshstk
-fversion=CET -O2 -g -m32 -m32 -fpreview=dip1000 -fpreview=fieldwise
-fpreview=dtorfields -nostdinc -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime
-I . -I$(pwd) -c
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime/core/internal/gc/impl/conservative/gc.d
 -fPIC -fversion=Shared -o /tmp/stage2-gc.o -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage2-x86_64-pc-linux-gnu/libphobos/libdruntime/

# build stage3 gc
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage3-gcc/gdc
-B/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage3-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/../lib/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
-isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -fversion=Shared
-Wall -frelease -ffunction-sections -fdata-sections -fcf-protection -mshstk
-fversion=CET -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-nostdinc -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime
-I . -I$(pwd) -c
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime/core/internal/gc/impl/conservative/gc.d
 -fPIC -fversion=Shared -o /tmp/stage3-gc.o -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage3-x86_64-pc-linux-gnu/libphobos/libdruntime/

# cmp
# cmp /tmp/stage2-gc.o /tmp/stage3-gc.o ; echo $?
/tmp/stage2-gc.o /tmp/stage3-gc.o differ: char 41, line 1
1
```

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |12.5

[Bug c++/118928] [15 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.cc:8694

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P2  |P1

[Bug sarif-replay/118929] sarif-replay doesn't support multithreaded paths

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

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

--- Comment #1 from David Malcolm  ---
For reference, GCC 15 prints the diagnostic textually like this when generating
that sarif file (via a test plugin):

diagnostic-test-paths-multithreaded-inline-events.c:17:3: warning: deadlock due
to inconsistent lock acquisition order
   17 |   acquire_lock_a (); /* { dg-warning "deadlock due to inconsistent lock
acquisition order" } */
  |   ^
Thread: 'Thread 1'
  'foo': event 1
|
|9 | {
|  | ^
|  | |
|  | (1) entering 'foo'
|
+--> 'foo': event 2
   |
   |   10 |   acquire_lock_a ();
   |  |   ^
   |  |   |
   |  |   (2) lock a is now held by thread 1
   |

Thread: 'Thread 2'
  'bar': event 3
|
|   15 | {
|  | ^
|  | |
|  | (3) entering 'bar'
|
+--> 'bar': event 4
   |
   |   16 |   acquire_lock_b ();
   |  |   ^
   |  |   |
   |  |   (4) lock b is now held by thread 2
   |

Thread: 'Thread 1'
 'foo': event 5
   |
   |   11 |   acquire_lock_b ();
   |  |   ^
   |  |   |
   |  |   (5) deadlocked due to waiting for lock b in thread 1
(acquired by thread 2 at (4))...
   |

Thread: 'Thread 2'
 'bar': event 6
   |
   |   17 |   acquire_lock_a (); /* { dg-warning "deadlock due to
inconsistent lock acquisition order" } */
   |  |   ^
   |  |   |
   |  |   (6) ...whilst waiting for lock a in thread 2 (acquired by
thread 1 at (2))
   |

[Bug other/118802] [15 regression] Bootstrap comparison failure on libphobos/libdruntime/core/internal/gc/impl/conservative/gc.o

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

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

--- Comment #9 from Sam James  ---
wtf?

```
--- stage2-gc.d.006t.original   2025-02-18 17:30:33.525730918 +
+++ stage3-gc.d.006t.original   2025-02-18 17:30:42.471563243 +
@@ -26,12 +26,12 @@
 {
   struct ConservativeGC * gc;

-  gc = (struct ConservativeGC *) __builtin_malloc (16);
+  gc = (struct ConservativeGC *) __builtin_malloc (32);
   if (gc == 0B)
 {
   onOutOfMemoryError (0B, {.length=135,
.ptr="/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime/core/internal/gc/impl/conservative/gc.d"},
145);
 }
-  return  = SAVE_EXPR  != 0B ? (struct GC *) (SAVE_EXPR
 + 8) : 0B;
+  return  = SAVE_EXPR  != 0B ? (struct GC *) (SAVE_EXPR
 + 16) : 0B;
 }
[...]
```

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-02-18
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Alex Coplan from comment #2)
> A bisect points to r10-917-g3b47da42de621c6c3bf7d2f9245df989aa7eb5a1 :
> 
> commit 3b47da42de621c6c3bf7d2f9245df989aa7eb5a1
> Author: Martin Jambor 
> Date:   Thu Jun 6 17:31:20 2019
> 
> Make SRA re-construct orginal memory accesses when easy

So what SRA does seems reasonible.

[Bug sarif-replay/118929] New: sarif-replay doesn't support multithreaded paths

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

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

Bug ID: 118929
   Summary: sarif-replay doesn't support multithreaded paths
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sarif-replay
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Trying it with:
 
https://github.com/davidmalcolm/sarif-examples/blob/main/valid/2.1.0/gcc/3.36-diagnostic-test-paths-multithreaded.sarif

$ sarif-replay valid/2.1.0/gcc/3.36-diagnostic-test-paths-multithreaded.sarif
/home/david/coding/work/src/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-multithreaded-sarif.c:16:3:
warning: deadlock due to inconsistent lock acquisition order [warning]
   16 |   acquire_lock_a ();
  |   ^~

The multithreaded codeFlow is not displayed.

[Bug other/118802] [15 regression] Bootstrap comparison failure on libphobos/libdruntime/core/internal/gc/impl/conservative/gc.o

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

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

--- Comment #10 from Sam James  ---
(I pasted the wrong command and used the wrong one in script.)

At least I can reproduce it consistently with:
```
cd
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime

# build stage2 gc
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage2-gcc/gdc
-B/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage2-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/../lib/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
-isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -fversion=Shared
-Wall -frelease -ffunction-sections -fdata-sections -fcf-protection -mshstk
-fversion=CET -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-nostdinc -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime
-I . -I$(pwd) -c
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime/core/internal/gc/impl/conservative/gc.d
 -fPIC -fversion=Shared -o /tmp/stage2-gc.o -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage2-x86_64-pc-linux-gnu/libphobos/libdruntime/
-fdump-tree-all

# build stage3 gc
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage3-gcc/gdc
-B/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage3-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/../lib/
-B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
-isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -fversion=Shared
-Wall -frelease -ffunction-sections -fdata-sections -fcf-protection -mshstk
-fversion=CET -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-nostdinc -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime
-I . -I$(pwd) -c
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./libphobos/libdruntime/core/internal/gc/impl/conservative/gc.d
 -fPIC -fversion=Shared -o /tmp/stage3-gc.o -I
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/build/stage3-x86_64-pc-linux-gnu/libphobos/libdruntime/
-fdump-tree-all

cmp /tmp/stage2-gc.o /tmp/stage3-gc.o ; echo $?
```

[Bug c++/118193] [12/13/14/15 regression] [C++17+] ICE: in verify_ctor_sanity, at cp/constexpr.cc:5362 since r13-1901-g9efe4e153d9949

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

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

--- Comment #4 from Marek Polacek  ---
No longer ICEs since r15-7209.

[Bug c++/118923] [15 regression] Wrong code generated for member function pointer call in range-for loop

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jakub at gcc dot gnu.org,
   ||sjames at gcc dot gnu.org
Summary|Wrong code generated for|[15 regression] Wrong code
   |member function pointer |generated for member
   |call in range-for loop  |function pointer call in
   ||range-for loop
   Target Milestone|--- |15.0

--- Comment #1 from Sam James  ---
jakub, could you take a look?

Smells like r15-7426-g35d40b56eb6e7a and r15-7502-g26baa2c09b39ab.

[Bug tree-optimization/118924] New: Wrong code leading to uninitialized accesses on aarch64-linux-gnu

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

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

Bug ID: 118924
   Summary: Wrong code leading to uninitialized accesses on
aarch64-linux-gnu
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following testcase is miscompiled on the trunk with -O2 and above, on
aarch64-linux-gnu:

$ cat small.cc
template  struct Vector {
  int m_data[Size];
  Vector(int, int, int) {}
};
enum class E { POINTS, LINES, TRIANGLES };

__attribute__((noipa))
void getName(E type) {
  static E check = E::POINTS;
  if (type == check)
check = (E)((int)check + 1);
  else
__builtin_abort ();
}

int main() {
  int arr[]{0, 1, 2};
  for (auto dim : arr) {
Vector<3> localInvs(1, 1, 1);
localInvs.m_data[dim] = 8;
  }
  E types[] = {E::POINTS, E::LINES, E::TRIANGLES};
  for (auto primType : types)
getName(primType);
}
$ g++ small.cc
$ ./a.out
$ g++ -O small.cc
$ ./a.out
$ g++ -O2 small.cc
$ ./a.out
Aborted

at -O1 we have the following in the optimized gimple for main:

   [local count: 268435458]:
  types[0] = 0;
  types[1] = 1;
  types[2] = 2;
  ivtmp.19_24 = (unsigned long) &types;
  _16 = ivtmp.19_24 + 12;

   [local count: 805306368]:
  # ivtmp.19_15 = PHI 
  _23 = (void *) ivtmp.19_15;
  primType_8 = MEM[(E *)_23];
  getName (primType_8);

but at -O2 we have:

   [local count: 268435456]:
  ivtmp.21_15 = (unsigned long) &types;
  _10 = ivtmp.21_15 + 12;

   [local count: 805306368]:
  # ivtmp.21_12 = PHI 
  _13 = (void *) ivtmp.21_12;
  primType_7 = MEM[(E *)_13];
  getName (primType_7);

i.e. at -O2 the initialization of the types array gets (incorrectly) optimized
out.  This can be verified by running valgrind on the binary compiled at -O2,
which prints the following:

==1918879== Conditional jump or move depends on uninitialised value(s)
==1918879==at 0x4006AC: getName(E) (in /path/to/a.out)
==1918879==by 0x40055B: main (in /path/to/a.out)

The problem seems to go at least as far back as GCC 11, but may be older.

[Bug testsuite/116986] FAIL: gcc.dg/torture/pr115387-2.c -O0 (test for excess errors)

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Fixed.

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu

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

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

--- Comment #2 from Alex Coplan  ---
A bisect points to r10-917-g3b47da42de621c6c3bf7d2f9245df989aa7eb5a1 :

commit 3b47da42de621c6c3bf7d2f9245df989aa7eb5a1
Author: Martin Jambor 
Date:   Thu Jun 6 17:31:20 2019

Make SRA re-construct orginal memory accesses when easy

[Bug c++/118923] [15 regression] Wrong code generated for member function pointer call in range-for loop

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=118856
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-02-18
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Seems to have started with r15-7508 "c++: -frange-for-ext-temps and reused
temps [PR118856]".

Reduced runtime testcase:

struct A {
int x[3];
int* begin() { return x; }
int* end() { return x+3; }
};

struct Workspace {
A previousRestrictedMoveArea() { return {1,2,3}; }
A restrictedMoveArea() { return {1,2,3}; }
bool inRearrange() {
return m_inRearrange;
}

bool m_inRearrange = false;

static Workspace _self;
};

Workspace Workspace::_self;

inline Workspace *workspace() {
return &Workspace::_self;
}

void foo() {
auto moveAreaFunc = workspace()->inRearrange() ?
&Workspace::previousRestrictedMoveArea :
&Workspace::restrictedMoveArea;

for (const int &r : (workspace()->*moveAreaFunc)()) {
}
}

int main() {
foo();
}

[Bug c++/118927] "double free detected in tcache 2" with import std and -Q

[nate at thatsmathematics dot com via Gcc-bugs]

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

--- Comment #5 from Nate Eldredge  ---
Oh, it's actually triggered by the compilation of a-foo.ii itself, but the
gcm.cache has to have previously been created.

The gcm.cache is too large to post as an attachment, but I can share it another
way if it's needed.

[Bug fortran/115781] Error with passing array of derived type

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle  ---
We are always trying to help people. I am not sure yet who may be the right
person to hit this one. We will have to see if someone will chime in.

[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 60528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60528&action=edit
testcase which can be compiled with both the C and C++ front-end

This testcase fails when compiled with the C++ front-end but works with the C
front-end. I am not sure why though. Because SRA does the same thing with the
IR coming out from both front-ends.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 118193 Summary: [12/13/14/15 regression] [C++17+] ICE: in 
verify_ctor_sanity, at cp/constexpr.cc:5362 since r13-1901-g9efe4e153d9949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118193

   What|Removed |Added

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

[Bug c++/118193] [12/13/14/15 regression] [C++17+] ICE: in verify_ctor_sanity, at cp/constexpr.cc:5362 since r13-1901-g9efe4e153d9949

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
The testcases look similar, so closing this.

[Bug rtl-optimization/118925] Comparison of the copy of a volatile register variable instead of the (register) variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
I am not 100% sure if NOT moving the register move from the loop is not
invalid.

[Bug target/118912] [15 Regression] gcc.target/aarch64/pr108840.c fails since r15-268

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed by r15-7605-gc5752c1f01316ac26ec9cf8d171d68aea420a158 .

[Bug libstdc++/115218] The conversion constructor of concat_view::iterator always default-constructs variant

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2025-02-18

--- Comment #1 from Patrick Palka  ---
Does this also mean the iterator's default ctor needs a
default_initializable<_Vs...[0]> constraint?

[Bug target/117270] [15 Regression] 9% exec time slowdown of 538.imagick_r on aarch64

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #7 from Tamar Christina  ---
(In reply to Filip Kastl from comment #6)
> Are you sure this is fixed?  On our machine the slowdown didn't go away. 
> See the graph
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=585.507.0.
> 
> Maybe the weird codegen wasn't the cause of the slowdown?

It was at the time, but now it's moved.

With the patch by Richard half the bad instructions are gone, however
part of the regression seems to be now, like the lbm regression that sched1 was
turned off.

-fsched-insn recovers 4% of the regression after this change.  Considering this
and the lbm regression I think we should turn sched1 back on at -Ofast for GCC
15.  It does seem to help fma scheduling.

The remaining part of the regression is that while the spills are less. there
is still unneeded spills! with the scheduler turned back on it becomes clearer:

ldp q27, q30, [x7]
ldp q31, q29, [x7, #32]
add x7, x7, #0x40
mov v0.16b, v27.16b
mov v1.16b, v30.16b
stp q30, q31, [sp, #160]
stp q31, q29, [sp, #192]
ldr q31, [sp, #224]
ldp q26, q27, [sp, #192]
ldp q25, q20, [x9, #-16]
tbl v29.16b, {v0.16b, v1.16b}, v31.16b
ldp q30, q31, [sp, #160]
ldp q22, q21, [x9, #-48

v30, v27, v31 and v29 are loaded. The original value of v30 and v27 copied to
get them in sequential registers for the TBL (as we did before), but then they
are also spilled and v31 is spilled twice.

q31 and 29 are spilled just to be immediately reloaded as q26 and q27.

which are fed into a permute

tbl v30.16b, {v30.16b, v31.16b}, v8.16b
tbl v31.16b, {v26.16b, v27.16b}, v10.16b

basically... register allocation and scheduling seem to be broken

the original sequence:

ldp q26, q20, [x13]
adrp x21, 5d7000 
ldp q31, q30, [x13, #32]
add x13, x13, #0x40
mov v27.16b, v20.16b
mov v21.16b, v31.16b
tbl v29.16b, {v26.16b, v27.16b}, v0.16b
mov v26.16b, v31.16b
ldr q31, [x21, #3616]
mov v27.16b, v30.16b
tbl v30.16b, {v20.16b, v21.16b}, v1.16b
ldp q20, q19, [x14, #-16]
zip1 v25.8h, v29.8h, v24.8h
zip2 v29.8h, v29.8h, v24.8h
tbl v31.16b, {v26.16b, v27.16b}, v31.16b

has no spills here.

Re-opened, but not sure what the new commits causing this are.. would need to
reduce first.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 117270 Summary: [15 Regression] 9% exec time slowdown of 538.imagick_r on 
aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270

   What|Removed |Added

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

[Bug c++/118917] New: 'class declared private here' points to definition instead

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 118917
   Summary: 'class declared private here' points to definition
instead
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

class a {
private:
class b;
};
class a::b {};
void c(a::b&) {}


Expected:

: In function 'void c(a::b&)':
:6:11: error: 'class a::b' is private within this context
6 | void c(a::b&) {}
  |   ^
:3:11: note: declared private here
3 | class b;
  |   ^


Actual:

: In function 'void c(a::b&)':
:6:11: error: 'class a::b' is private within this context
6 | void c(a::b&) {}
  |   ^
:5:10: note: declared private here
5 | class a::b {};
  |  ^


That's the definition, not the declaration; it's not where the class is made
private.

If you remove line 5, it correctly points to the declaration on line 3.

[Bug target/118320] [14 Regression] internal compiler error: Segmentation fault in aarch64-ldp-fusion.cc

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

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

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

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

commit r15-7604-gfacdce9028060c8dc4340a38ae02fb071e16af08
Author: Alex Coplan 
Date:   Tue Feb 18 10:48:50 2025 +

pair-fusion: Tweak wording in dump message [PR118320]

As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675978.html
this tweaks the dump messasge added with the fix for PR118320 since it
doesn't
just apply to load pairs.

gcc/ChangeLog:

PR rtl-optimization/118320
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Tweak wording in
dump
message when punting on invalid use arrays.

[Bug rtl-optimization/117712] [15 regression] ICE when building x265: internal compiler error: in expand_fix, at optabs.cc:5936 since r15-2890

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Earnshaw  ---
There's some ambiguity in the manual, but it was historically the case that
FIX: did the truncation/rounding, while FIX: did the conversion to
an integral mode (with unspecified rounding).

[Bug c/118918] [12./13/14/15 Regression] Miscompile at -Os

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |12.5
  Known to work||7.5.0, 8.4.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-02-18
 Ever confirmed|0   |1
 CC||jsm28 at gcc dot gnu.org
  Known to fail||10.5.0, 11.5.0, 12.4.0,
   ||14.2.0, 15.0, 9.5.0
Summary|Miscompile at -Os   |[12./13/14/15 Regression]
   ||Miscompile at -Os

--- Comment #1 from Richard Biener  ---
Confirmed.  Somehow we lose the 'e' initializer:

  if (h != 0)
{
  {
long int D.2841[1] = {2};

e = (long int *) &<<< Unknown tree: compound_literal_expr
long int D.2841[1] = {2}; >>>;
  }
}
  else
{
  {
long int D.2842[2] = {2, 8};

e = (long int *) &<<< Unknown tree: compound_literal_expr
long int D.2842[2] = {2, 8}; >>>;
  }
}

the scope of D.2841/D.2842 are at issue here.  I do remember some change
in GCC extension behavior though, so this might be invalid.

[Bug c/118918] [12./13/14/15 Regression] Miscompile at -Os

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Richard Biener  ---
https://gcc.gnu.org/gcc-9/porting_to.html

[Bug other/118802] [15 regression] Bootstrap comparison failure on libphobos/libdruntime/core/internal/gc/impl/conservative/gc.o

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

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

Sam James  changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org
 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #7 from Sam James  ---
meh, still seeing it actually. Iain, could I trouble you to give any sort of
hint?

[Bug fortran/113997] Bogus 'Warning: Interface mismatch in global procedure' with C binding

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Thomas Koenig  ---
I checked my interpretation on the J3 standards list, and it was
confirmed by Malcolm Cohen that my interpretation is correct:

https://mailman.j3-fortran.org/pipermail/j3/2025-February/015164.html

Therefore, closing as invalid.

[Bug fortran/32630] [meta-bug] ISO C binding

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

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

Bug 113997 Summary: Bogus 'Warning: Interface mismatch in global procedure' 
with C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/56210] invalid -Warray-bounds warning

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Last reconfirmed|2013-02-05 00:00:00 |2025-2-18

--- Comment #8 from Richard Biener  ---
ANTIC_OUT[2] := {
{call_expr,addr_expr<";">,addr_expr<&key>,integer_cst<3>}@.MEM_5(D)

that's not simplifed.

We're also not trying to thread anything.

One issue is that 'key' is not promoted read-only because it's passed
to strncmp.

The other issue is that PRE phi-translation (no longer?) simplifies
references.  It did so on GCC 7 but not after (I'm sure it wouldn't have
worked there).  For cases like this this looks relevant.

Adjusted testcase to avoid the readonly issue:

#include 
#include 

void
f (void)
{
char *p = ";";
while (*p) {
static const char key[] = "abc";
if (strncmp(p, key, 3) == 0) {
p += 3;
printf("%s\n", p);
return;
}
if ((p = strchr(p, ';')) == NULL)
return;
p++;
}
}

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 56531 Summary: SLP load permutations cannot share the load between and 
inside SLP instances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56531

   What|Removed |Added

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

[Bug tree-optimization/56531] SLP load permutations cannot share the load between and inside SLP instances

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I'll mark this fixed for GCC 15, for the vast majority of cases we'll now
properly share loads.

[Bug tree-optimization/56270] [4.6 Regression] loop over array of struct float causes compiler error: segmentation fault

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

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

Bug 56531 Summary: SLP load permutations cannot share the load between and 
inside SLP instances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56531

   What|Removed |Added

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

[Bug target/117525] [15 Regression] canvas.cc:1675:1: internal compiler error: in expand_fix, at optabs.cc:5952 since r15-2890

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

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

--- Comment #19 from Richard Earnshaw  ---
I'm not convinced this is correct.  See the discussion on the patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2003-March/098380.html and the
related PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5985).

[Bug middle-end/38486] Missing warning about type punning

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #11 from Richard Biener  ---
So the IL issues have been resolved meanwhile (via MEM_REF introduction I
think), that we don't miscompile this is because we're good at DWIM here.

There's no way to diagnose the issue across function calls and generally
the -Wstrict-aliasing warning is frowned upon nowadays.

So WONTFIX.

[Bug sarif-replay/118930] sarif-replay doesn't output #include chains

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-02-18

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

[Bug sarif-replay/118930] sarif-replay doesn't output #include chains

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

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

--- Comment #2 from Andrew Pinski  ---
Oh wait never mind.

[Bug sarif-replay/118930] sarif-replay doesn't output #include chains

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

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

--- Comment #1 from Andrew Pinski  ---
I think this is a dup ...

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||13.1.0
Summary|[15 regression] Miscompile  |[13/14/15 regression]
   |at -O2/3 since r15-276  |Miscompile at -O2/3 since
   Target Milestone|15.0|13.4
  Known to work|14.2.1  |12.1.0

--- Comment #6 from Andrew Pinski  ---
My new testcase fails before richi's r15-276 since that just exposed the latent
bug.

[Bug tree-optimization/118922] [15 regression] Miscompile at -O2/3 since r15-276

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 60529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60529&action=edit
testcase that fails before

[Bug target/118931] [15 Regression] RISC-V: rv64gcv miscompile at -O[23] since r15-3228-g771256bcb9d

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||riscv
   Keywords||wrong-code
   Target Milestone|--- |15.0
Summary|[15] RISC-V: rv64gcv|[15 Regression] RISC-V:
   |miscompile at -O[23] since  |rv64gcv miscompile at
   |r15-3228-g771256bcb9d   |-O[23] since
   ||r15-3228-g771256bcb9d

[Bug c++/118920] ICE when importing memory and filesystem and a module-compiled system header importing memory

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Can you try -fno-checking. I suspect this might be just a checking ICE which
might not show up with release checking.

[Bug tree-optimization/118933] New: Missed optimization: __builtin_unreachable() does not work as expected on std::vector data compared to raw pointer and length

[nicula.iccc at gmail dot com via Gcc-bugs]

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

Bug ID: 118933
   Summary: Missed optimization: __builtin_unreachable() does not
work as expected on std::vector data compared to raw
pointer and length
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicula.iccc at gmail dot com
  Target Milestone: ---

I have the following code which calculates the sum of an array of uint8_t
values into a uint8_t accumulator:

#include 
#include 
#include 

uint8_t get_sum(const uint8_t *data, size_t len)
{
constexpr size_t U8_VALUES_PER_YMMWORD = 32;
if ((len % U8_VALUES_PER_YMMWORD) != 0 || len == 0)
__builtin_unreachable();

return std::accumulate(data, data + len, uint8_t(0));
}

They key point here is that I'm telling the compiler to assume that the entire
array can be traversed in YMM-sized chunks, and that the array is non-empty.
The compiler uses this information to generate a really compact, vectorized
loop (.L2 ... jmp .L2), which traverses the entire array YMMWORD-by-YMMWORD. No
other superfluous branches:

get_sum(unsigned char const*, unsigned long):
and rsi, -32
vpxor   xmm0, xmm0, xmm0
add rsi, rdi
.L2:
vpaddb  ymm0, ymm0, YMMWORD PTR [rdi]
add rdi, 32
cmp rdi, rsi
jne .L2
vextracti32x4   xmm1, ymm0, 0x1
vpaddb  xmm0, xmm1, xmm0
vpsrldq xmm1, xmm0, 8
vpaddb  xmm0, xmm0, xmm1
vpxor   xmm1, xmm1, xmm1
vpsadbw xmm0, xmm0, xmm1
vpextrb eax, xmm0, 0
vzeroupper
ret

The problem is that when I try to do the same thing, but with a vector,
__builtin_unreachable() has no effect. Code:

#include 
#include 
#include 
#include 

__always_inline
uint8_t get_sum_helper(const uint8_t *data, size_t len)
{
constexpr size_t U8_VALUES_PER_YMMWORD = 32;
if ((len % U8_VALUES_PER_YMMWORD) != 0 || len == 0)
__builtin_unreachable();

return std::accumulate(data, data + len, uint8_t(0));
}

uint8_t get_sum(const std::vector &vec)
{
const uint8_t *data = vec.begin().base();
const size_t   len  = vec.size();
return get_sum_helper(data, len);
}

Assembly:

get_sum(std::vector> const&):
mov r8, QWORD PTR [rdi]
mov rsi, QWORD PTR [rdi+8]
cmp rsi, r8
je  .L9
mov rdi, rsi
mov rax, r8
sub rdi, r8
lea rdx, [rdi-1]
cmp rdx, 30
jbe .L10
mov r9, rdi
vpxor   xmm0, xmm0, xmm0
and r9, -32
lea rcx, [r8+r9]
.L4:
vpaddb  ymm0, ymm0, YMMWORD PTR [rax]
add rax, 32
cmp rcx, rax
jne .L4
vextracti32x4   xmm1, ymm0, 0x1
vpxor   xmm2, xmm2, xmm2
mov rax, rcx
vpaddb  xmm0, xmm1, xmm0
vpsrldq xmm1, xmm0, 8
vpaddb  xmm1, xmm0, xmm1
vpsadbw xmm1, xmm1, xmm2
vpextrb edx, xmm1, 0
cmp rdi, r9
je  .L17
vzeroupper
.L3:
sub rdi, r9
lea rcx, [rdi-1]
cmp rcx, 14
jbe .L7
vpaddb  xmm0, xmm0, XMMWORD PTR [r8+r9]
mov rcx, rdi
and rcx, -16
vpsrldq xmm1, xmm0, 8
add rax, rcx
and edi, 15
vpaddb  xmm0, xmm0, xmm1
vpxor   xmm1, xmm1, xmm1
vpsadbw xmm0, xmm0, xmm1
vpextrb edx, xmm0, 0
je  .L1
.L7:
lea rcx, [rax+1]
add dl, BYTE PTR [rax]
cmp rsi, rcx
je  .L1
lea rcx, [rax+2]
add dl, BYTE PTR [rax+1]
cmp rsi, rcx
je  .L1
lea rcx, [rax+3]
add dl, BYTE PTR [rax+2]
cmp rsi, rcx
je  .L1
lea rcx, [rax+4]
add dl, BYTE PTR [rax+3]
cmp rsi, rcx
je  .L1
lea rcx, [rax+5]
add dl, BYTE PTR [rax+4]
cmp rsi, rcx
je  .L1
lea rcx, [rax+6]
add dl, BYTE PTR [rax+5]
cmp rsi, rcx
je  .L1
lea rcx, [rax+7]
add dl, BYTE PTR [rax+6]
cmp rsi, rcx
je  .L1
lea rcx, [rax+8]

[Bug tree-optimization/118933] Missed optimization: __builtin_unreachable() does not work as expected on std::vector data compared to raw pointer and length

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

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

--- Comment #1 from Andrew Pinski  ---
This is because `len` is vec.end() - vec.begin() where end is a pointer load.

and then `data + len` gets re-optimized to just vec.end().

And so len is no longer taken into account in std::accumulate loop.

[Bug tree-optimization/118933] Missed optimization: __builtin_unreachable() does not work as expected on std::vector data compared to raw pointer and length

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2025-02-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Basically we lose the connection is what I am saying.

I wonder if we should not re-write the loop early on to be:
`for (__SIZE_TYPE__ i = 0; i < end - begin; i++)`

And then we won't lose the connection between the 2.

But that does not help.

[Bug testsuite/116986] FAIL: gcc.dg/torture/pr115387-2.c -O0 (test for excess errors)

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

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

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

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

commit r15-7607-g8c03fbd77654713b3bc90ebada3f880f9dd06bf7
Author: John David Anglin 
Date:   Tue Feb 18 10:36:48 2025 -0500

testsuite: Include stdint.h instead of stdint-gcc.h in some tests

When use_gcc_stdint=provide, the stdint-gcc.h header is not provided.

2025-02-18  John David Anglin  

gcc/testsuite/ChangeLog:

PR testsuite/116986
* gcc.dg/crc-builtin-rev-target32.c: Include stdint.h
instead of stdint-gcc.h.
* gcc.dg/crc-builtin-rev-target64.c: Likewise.
* gcc.dg/crc-builtin-target32.c: Likewise.
* gcc.dg/crc-builtin-target64.c: Likewise.
* gcc.dg/torture/pr115387-2.c: Likewise.

[Bug target/115703] [15 Regression] rv64gcv_zvl256b miscompile since r15-1579-g792f97b44ff

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Robin Dapp :

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

commit r15-7608-g44d4a1086d965fb5280daf65c7c4a253ad6cc8a1
Author: Robin Dapp 
Date:   Thu Feb 6 14:43:17 2025 +0100

RISC-V: Fix ratio in vsetvl fuse rule [PR115703].

In PR115703 we fuse two vsetvls:

Fuse curr info since prev info compatible with it:
  prev_info: VALID (insn 438, bb 2)
Demand fields: demand_ge_sew demand_non_zero_avl
SEW=32, VLMUL=m1, RATIO=32, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(reg:DI 0 zero)
VL=(reg:DI 9 s1 [312])
  curr_info: VALID (insn 92, bb 20)
Demand fields: demand_ratio_and_ge_sew demand_avl
SEW=64, VLMUL=m1, RATIO=64, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(const_int 4 [0x4])
VL=(nil)
  prev_info after fused: VALID (insn 438, bb 2)
Demand fields: demand_ratio_and_ge_sew demand_avl
SEW=64, VLMUL=mf2, RATIO=64, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(const_int 4 [0x4])
VL=(nil).

The result is vsetvl zero, zero, e64, mf2, ta, ma.  The previous vsetvl
set vl = 4 but here we wrongly set it to vl = 2.  As all the following
vsetvls only ever change the ratio we never recover.

The issue is quite difficult to trigger because we can often
deduce the value of d at runtime.  Then very check for the value of
d will be optimized away.

The last known bad commit is r15-3458-g5326306e7d9d36.  With that commit
the output is wrong but -fno-schedule-insns makes it correct.  From the
next commit on the issue is latent.  I still added the PR's test as scan
and run check even if they don't trigger right now.  Not sure if the
run test will ever fail but well.  I verified that the
patch fixes the issue when applied on top of r15-3458-g5326306e7d9d36.

PR target/115703

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc: Use max_sew for calculating the
new LMUL.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr115703-run.c: New test.
* gcc.target/riscv/rvv/autovec/pr115703.c: New test.

[Bug tree-optimization/118910] Promote an expression equivalence to a name equivalence in DOM

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

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

--- Comment #4 from Jeffrey A. Law  ---
Richi -- I think that's been the plan of record for a while.   My general sense
is that most of what DOM is doing can be handled elsewhere.