[Bug libgomp/119570] New: FAIL: libgomp.c++/../libgomp.c-c++-common/metadirective-4.c execution test

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

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

Bug ID: 119570
   Summary: FAIL:
libgomp.c++/../libgomp.c-c++-common/metadirective-4.c
execution test
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xg++
-B/home/dave/gnu/gcc/o
bjdir64/gcc/
/home/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/../libgomp.c-c
++-common/metadirective-4.c
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./
libgomp/ -B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/.libs
-I/ho
me/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp
-I/home/dave/gnu/gcc/gcc/
libgomp/testsuite/../../include -I/home/dave/gnu/gcc/gcc/libgomp/testsuite/..
-f
message-length=0 -fdiagnostics-plain-output -fopenmp -O2 -nostdinc++
-I/home/dav
e/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/d
ave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/inc
lude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-B/home/dave/
gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/../libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/../libstdc++-v3/src/.libs
-lm -o ./metadirective-4.exe
PASS: libgomp.c++/../libgomp.c-c++-common/metadirective-4.c (test for excess
errors)
Got /home/dave/gnu/gcc/gcc/libgomp/testsuite/flock('../lock', '--exclusive') at
Tue Apr 01 07:47:13 EDT 2025 after 0 s
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/../libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/gcc:.:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libgomp/../libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
Execution timeout is: 300
spawn [open ...]
FAIL: libgomp.c++/../libgomp.c-c++-common/metadirective-4.c execution test

Similar fails:
FAIL: libgomp.c/../libgomp.c-c++-common/metadirective-4.c execution test
FAIL: libgomp.fortran/metadirective-4.f90   -O0  execution test
FAIL: libgomp.fortran/metadirective-4.f90   -O1  execution test
FAIL: libgomp.fortran/metadirective-4.f90   -O2  execution test
FAIL: libgomp.fortran/metadirective-4.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/metadirective-4.f90   -O3 -g  execution test
FAIL: libgomp.fortran/metadirective-4.f90   -Os  execution test

[Bug c/117689] enum with underying type "extension" to GNU 17 is not documented

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

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

--- Comment #2 from sandra at gcc dot gnu.org ---
More specifically, gcc accepts

enum e;
static enum e thing;
enum e { e1, e2, e3};

but rejects

enum e;
int foo (void)
{
  static enum e thing;
  return -1;
}
enum e { e1, e2, e3};

and also rejects

int foo (void)
{
  enum e;
  static enum e thing;
  enum e { e1, e2, e3};
  return -1;
}

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug rtl-optimization/119291] [12/13/14/15 regression] wrong code at -O{2,3} on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:19ba913517b5e2a001fa9c0f060a1ac74430c027

commit r15-9131-g19ba913517b5e2a001fa9c0f060a1ac74430c027
Author: Jakub Jelinek 
Date:   Tue Apr 1 16:40:55 2025 +0200

combine: Use reg_used_between_p rather than modified_between_p in two spots
[PR119291]

The following testcase is miscompiled on x86_64-linux at -O2 by the
combiner.
We have from earlier combinations
(insn 22 21 23 4 (set (reg:SI 104 [ _7 ])
(const_int 0 [0])) "pr119291.c":25:15 96 {*movsi_internal}
 (nil))
(insn 23 22 24 4 (set (reg/v:SI 117 [ e ])
(reg/v:SI 116 [ e ])) 96 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 116 [ e ])
(nil)))
(note 24 23 25 4 NOTE_INSN_DELETED)
(insn 25 24 26 4 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (neg:SI (reg:SI 104 [ _7 ]))
(const_int 0 [0])))
(set (reg/v:SI 116 [ e ])
(neg:SI (reg:SI 104 [ _7 ])))
]) "pr119291.c":26:13 977 {*negsi_2}
 (expr_list:REG_DEAD (reg:SI 104 [ _7 ])
(nil)))
(note 26 25 27 4 NOTE_INSN_DELETED)
(insn 27 26 28 4 (set (reg:DI 128 [ _9 ])
(ne:DI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr119291.c":26:13 1447 {*setcc_di_1}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
and try_combine is called on i3 25 and i2 22 (second time)
and reach the hunk being patched with simplified i3
(insn 25 24 26 4 (parallel [
(set (pc)
(pc))
(set (reg/v:SI 116 [ e ])
(const_int 0 [0]))
]) "pr119291.c":28:13 977 {*negsi_2}
 (expr_list:REG_DEAD (reg:SI 104 [ _7 ])
(nil)))
and
(insn 22 21 23 4 (set (reg:SI 104 [ _7 ])
(const_int 0 [0])) "pr119291.c":27:15 96 {*movsi_internal}
 (nil))
Now, the try_combine code there attempts to split two independent
sets in newpat by moving one of them to i2.
And among other tests it checks
!modified_between_p (SET_DEST (set1), i2, i3)
which is certainly needed, if there would be say
(set (reg/v:SI 116 [ e ]) (const_int 42 [0x2a]))
in between i2 and i3, we couldn't do that, as that set would overwrite
the value set by set1 we want to move to the i2 position.
But in this case pseudo 116 isn't set in between i2 and i3, but used
(and additionally there is a REG_DEAD note for it).

This is equally bad for the move, because while the i3 insn
and later will see the pseudo value that we set, the insn in between
which uses the value will see a different value from the one that
it should see.

As we don't check for that, in the end try_combine succeeds and
changes the IL to:
(insn 22 21 23 4 (set (reg/v:SI 116 [ e ])
(const_int 0 [0])) "pr119291.c":27:15 96 {*movsi_internal}
 (nil))
(insn 23 22 24 4 (set (reg/v:SI 117 [ e ])
(reg/v:SI 116 [ e ])) 96 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 116 [ e ])
(nil)))
(note 24 23 25 4 NOTE_INSN_DELETED)
(insn 25 24 26 4 (set (pc)
(pc)) "pr119291.c":28:13 2147483647 {NOOP_MOVE}
 (nil))
(note 26 25 27 4 NOTE_INSN_DELETED)
(insn 27 26 28 4 (set (reg:DI 128 [ _9 ])
(const_int 0 [0])) "pr119291.c":28:13 95 {*movdi_internal}
 (nil))
(note, the i3 got turned into a nop and try_combine also modified insn 27).

The following patch replaces the modified_between_p
tests with reg_used_between_p, my understanding is that
modified_between_p is a subset of reg_used_between_p, so one
doesn't need both.

Looking at this some more today, I think we should special case
set_noop_p because that can be put into i2 (except for the JUMP_P
violations), currently both modified_between_p (pc_rtx, i2, i3)
and reg_used_between_p (pc_rtx, i2, i3) returns false.
I'll post a patch incrementally for that (but that feels like
new optimization, so probably not something that should be backported).

On Tue, Apr 01, 2025 at 11:27:25AM +0200, Richard Biener wrote:
> Can we constrain SET_DEST (set1/set0) to a REG_P in combine?  Why
> does the comment talk about memory?

I was worried about making too risky changes this late in stage4
(and especially also for backports).  Most of this code is 1992-ish.
I think many of the functions are just misnamed, the reg_ in there doesn't
match what those functions do (bet they initially supported just REGs
and later on support for other kinds of expressions was added, but haven't
done git archeology to prove that).

What we know for sure is:
   && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != ZERO

[Bug target/110812] Check availability of builtins at expand time

[schwab--- via Gcc-bugs]

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

--- Comment #6 from Andreas Schwab  ---
pixman is another victim.

[Bug c++/119447] [14/15 Regression] ICE Segmentation fault with incorrect template class declaration syntax and varadic parameter since r14-9374

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

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

--- Comment #3 from Patrick Palka  ---
That approach seems reasonable to me FWIW. Alternatively maybe we could fall
back to using the dependent DECL_CONTEXT (gen_tmpl) as 'ctx' if
tsubst_entering_scope fails.

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

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

https://gcc.gnu.org/g:01acd453d89ff5e414fade2dfeeae1f652143376

commit r15-9132-g01acd453d89ff5e414fade2dfeeae1f652143376
Author: Jakub Jelinek 
Date:   Tue Apr 1 16:47:37 2025 +0200

tailc: Improve tail recursion handling [PR119493]

This is a partial step towards fixing that PR.
For musttail recursive calls which have non-is_gimple_reg_type typed
parameters, the only case we've handled was if the exact parameter
was passed through (perhaps modified, but still the same PARM_DECL).
That isn't necessary, we can copy the argument to the parameter as well
(just need to watch for the use of the parameter in later arguments,
say musttail recursive call which swaps 2 structure arguments).

The patch attempts to play safe and punts if any of the parameters are
addressable (like we do for all normal tail calls and tail recursions,
except for musttail in the posted unreviewed patch).

With this patch (at least when early inlining isn't done on not yet
optimized body) inlining should see already tail recursion optimized
body and will not have problems with SRA breaking musttail.

This version of the patch limits this for musttail tail recursions,
with intent to enable for all tail recursions in GCC 16.

2025-04-01  Jakub Jelinek  

PR tree-optimization/119493
* tree-tailcall.cc (find_tail_calls): Don't punt on tail recusion
if some arguments don't have is_gimple_reg_type, only punt if they
have non-POD types, or volatile, or addressable or (for now) it is
not a musttail call.  Set tailr_arg_needs_copy in those cases too.
(eliminate_tail_call): Copy call arguments to params if they don't
have is_gimple_reg_type, use temporaries if the argument is used
later.
(tree_optimize_tail_calls_1): Skip !is_gimple_reg_type
tailr_arg_needs_copy parameters.  Formatting fix.

* gcc.dg/pr119493-1.c: New test.

[Bug ada/119571] [15 Regression] ggc-none.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used w hen making a PIE object; recompile with -fPIE

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

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

--- Comment #1 from Matthias Klose  ---
also seen with arm64 -> alpha and s390x -> ppc64

[Bug rtl-optimization/119291] [12/13/14 regression] wrong code at -O{2,3} on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14/15 regression]|[12/13/14 regression] wrong
   |wrong code at -O{2,3} on|code at -O{2,3} on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #18 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/119383] [15 Regression] Boost 1.85 lib test failures after commit r15-8011

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

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

--- Comment #10 from Sam James  ---
Fixed.

[Bug c++/119383] [15 Regression] Boost 1.85 lib test failures after commit r15-8011

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #11 from Sam James  ---
.

[Bug c++/119564] ICE using module including boost headers

[cjangus at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Cameron Angus  ---
Created attachment 60948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60948&action=edit
Preprocessed source for module interface

[Bug c++/119564] ICE using module including boost headers

[cjangus at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Cameron Angus  ---
Yeah I realized afterwards there was a limit so I guess that is why.
Unfortunately even compressed it's a little over 1MB. Can I link to external
hosting? 

I'll try to repro on a more recent snapshot.

[Bug c++/119563] [15 Regression] internal compiler error on large enough vector initialization

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/119564] ICE using module including boost headers

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

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

--- Comment #1 from Andrew Pinski  ---
> The following repro 

Looks like it was not attached?  Maybe you need to compress it.

Also 20250223 is at least one month out of date, you can test the latest?

[Bug c++/119566] internal compiler error: in unify, at cp/pt.cc:25410

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

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

--- Comment #1 from Andrew Pinski  ---
Can you add -save-temps and provide the generated .ii file?

[Bug libstdc++/116212] [13/14 regression] -Walloc-size-larger-than warning when building 20_util/specialized_algorithms/uninitialized_move/constrained.cc with -O3

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:30d7bca6c2a3d70ecafdc4b2cf807944c736214c

commit r14-11496-g30d7bca6c2a3d70ecafdc4b2cf807944c736214c
Author: Jonathan Wakely 
Date:   Tue Apr 1 11:02:43 2025 +0100

libstdc++: Avoid bogus -Walloc-size-larger-than warning in test [PR116212]

The compiler can't tell that the vector size fits in int, so it thinks
it might overflow to a negative value, which would then be a huge
positive size_t.  In reality, the vector size never exceeds five.

There's no warning on trunk, so just change the local variable to use
type unsigned so that we get rid of the warning on the branches.

libstdc++-v3/ChangeLog:

PR libstdc++/116212
*
testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Use unsigned for vector size.

[Bug libstdc++/116212] [13/14 regression] -Walloc-size-larger-than warning when building 20_util/specialized_algorithms/uninitialized_move/constrained.cc with -O3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
This fixes it:

---
a/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc
+++
b/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc
@@ -50,7 +50,7 @@ test01(std::vector ix)
 {
   ix = saved_ix;

-  int size = ix.size();
+  unsigned size = ix.size();
   auto buffer = std::unique_ptr(new char[sizeof(T)*size]);
   std::span rx((T *)buffer.get(), size);


The compiler thinks it's possible that the vector size overflows int and gives
us a negative number, which then gives a large positive number when converted
back to size_t.

[Bug other/119569] New: FAIL: c-c++-common/gomp/append-args-1.c (internal compiler error: in modify_call_for_omp_dispatch, at gimplify.cc:3957)

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

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

Bug ID: 119569
   Summary: FAIL: c-c++-common/gomp/append-args-1.c (internal
compiler error: in modify_call_for_omp_dispatch, at
gimplify.cc:3957)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-
1.c -fdiagnostics-plain-output -fopenmp -S -o append-args-1.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:16:7:
err
or: argument 1 of 'repl0' must be of 'omp_interop_t'
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:17:64:
no
te: 'append_args' specified here
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:41:93:
er
ror: too many 'append_args' clauses
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:41:29:
er
ror: variant 'repl4' and base 'base4' have incompatible types
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:48:7:
err
or: argument 4 of 'repl5' must be of 'omp_interop_t'
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:49:64:
no
te: 'append_args' specified here
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:57:29:
er
ror: variant 'repl6' and base 'base6' have incompatible types
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c: In
funct
ion 'test':
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:82:32:
error: number of list items in 'interop' clause (2) exceeds the number of
'append_args' items (1) for 'declare variant' candidate 'repl3'
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:35:21:
note: 'declare variant' candidate 'repl3' declared here
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/append-args-1.c:83:5:
internal compiler error: in modify_call_for_omp_dispatch, at gimplify.cc:3957
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
compiler exited with status 1
FAIL: c-c++-common/gomp/append-args-1.c (internal compiler error: in
modify_call_for_omp_dispatch, at gimplify.cc:3957)

Similar fails:
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++17  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++17 (internal compiler error:
in modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++17 (test for excess errors)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++26  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++26 (internal compiler error:
in modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++26 (test for excess errors)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++98  (test for errors, line 82)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++98 (internal compiler error:
in modify_call_for_omp_dispatch, at gimplify.cc:3957)
FAIL: c-c++-common/gomp/append-args-1.c  -std=c++98 (test for excess errors)

This is probably a regression.

[Bug ipa/119318] [15 Regression] wrong code with vector arithmetics at -O2 since r15-6294-g96fb71883d438b

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

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

--- Comment #7 from Martin Jambor  ---
...and that one consists of the first and second patch in the series at
https://inbox.sourceware.org/gcc-patches/cover.1743458148.git.jamb...@gcc.gnu.org/T/#t

[Bug ipa/119318] [15 Regression] wrong code with vector arithmetics at -O2 since r15-6294-g96fb71883d438b

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

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

--- Comment #8 from Martin Jambor  ---
(In reply to Sam James from comment #6)
> Maybe add the PR119530 testcase as well? It is structurally similar, but it
> lacks vectors so may be more useful food for the fuzzers.

I have that on my TODO list, but I was already testing the patches when I
confirmed it was a duplicate.

[Bug c++/119383] [15 Regression] Boost 1.85 lib test failures after commit r15-8011

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

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

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r15-9128-ge9803f10c9f376f6d091e7ef3ad6e1c92e7c8e8c
Author: Marek Polacek 
Date:   Tue Mar 25 13:36:24 2025 -0400

c++: fix missing lifetime extension [PR119383]

Since r15-8011 cp_build_indirect_ref_1 won't do the *&TARGET_EXPR ->
TARGET_EXPR folding not to change its value category.  That fix seems
correct but it made us stop extending the lifetime in this testcase,
causing a wrong-code issue -- extend_ref_init_temps_1 did not see
through the extra *& because it doesn't use a tree walk.

This patch reverts r15-8011 and instead handles the problem in
build_over_call by calling force_lvalue in the is_really_empty_class
case as well as in the general case.

PR c++/119383

gcc/cp/ChangeLog:

* call.cc (build_over_call): Use force_lvalue to ensure op= returns
an lvalue.
* cp-tree.h (force_lvalue): Declare.
* cvt.cc (force_lvalue): New.
* typeck.cc (cp_build_indirect_ref_1): Revert r15-8011.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/temp-extend3.C: New test.

Reviewed-by: Jason Merrill 

[Bug target/119565] 13-17% regression of botan CAS128 and DES on zen4

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

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

--- Comment #1 from Andrew Pinski  ---
The only change I could see that might have any effect on that code is
r15-9047-g9c5505a35d9d71 which most likely means this is a code layout changes
due to other optimizations happening in the non-hot path.

[Bug c++/119566] New: internal compiler error: in unify, at cp/pt.cc:25410

[gessos.paul at yahoo dot gr via Gcc-bugs]

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

Bug ID: 119566
   Summary: internal compiler error: in unify, at cp/pt.cc:25410
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gessos.paul at yahoo dot gr
  Target Milestone: ---

Created attachment 60947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60947&action=edit
complete source code with many .h and only one .cpp

Source code can be or cannot be legal.
I get an ICE.

x86_64-w64-mingw32-g++.exe -std=c++26 -c test\test_dense_vector.cpp -o
test\test_dense_vector.o
x86_64-w64-mingw32-g++.exe  -o test\test_dense_vector.exe
test\test_dense_vector.o  
In file included from test\test_dense_vector.cpp:3:
src/element_map_vector_view.h: In substitution of 'template
element_map_vector_view(const T&)-> mafematics::element_map_vector_view > requires  __is_deducible (mafematics::conjugent_vector_view,
mafematics::element_map_vector_view >) [with T =
std::array, 3>]':
test\test_dense_vector.cpp:236:28:   required from here
  236 | conjugent_vector_view e{a};
  |  ^
src/element_map_vector_view.h:132:19: internal compiler error: in unify, at
cp/pt.cc:25410
  132 | constexpr element_map_vector_view(const T &v) noexcept : v{v}
{}
  |   ^~~


Which g++:

Using built-in specs.
COLLECT_GCC=e:\Software\mingw64\bin\g++
COLLECT_LTO_WRAPPER=e:/Software/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/14.2.0/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs_staging_msvcrt64/inst_gcc-14.2.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-msvcrt-posix-seh, built by Brecht Sanders, r3' --with-tune=generic
--enable-checking=release --enable-threads=posix --disable-sjlj-exceptions
--disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap
--enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath
--disable-libstdcxx-debug --disable-version-specific-runtime-libs
--disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++
--disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry
--disable-multilib --enable-ld --enable-libquadmath --enable-libada
--enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string
--enable-libgomp --enable-graphite --enable-mingw-wildcard
--enable-libstdcxx-time --enable-libstdcxx-pch
--with-mpc=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--with-mpfr=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--with-gmp=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--with-isl=/c/Prog/winlibs_staging_msvcrt/custombuilt64
--disable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit
--without-included-gettext --with-diagnostics-color=auto
--enable-clocale=generic --with-libiconv --with-system-zlib
--with-build-sysroot=/R/winlibs_staging_msvcrt64/gcc-14.2.0/build_mingw/mingw-w64
CFLAGS='-I/c/Prog/winlibs_staging_msvcrt/custombuilt64/include/libdl-win32  
-march=nocona -msahf -mtune=generic -O2 -Wno-error=format'
CXXFLAGS='-Wno-int-conversion  -march=nocona -msahf -mtune=generic -O2'
LDFLAGS='-pthread -Wl,--no-insert-timestamp -Wl,--dynamicbase
-Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware'
LD=/c/Prog/winlibs_staging_msvcrt/custombuilt64/share/binutils/bin/ld.exe
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders,
r3)

[Bug gcov-profile/119553] ICE: SIGSEGV in gcov_position (gcov-io.cc:67) with -fpath-coverage

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/119564] ICE using module including boost headers

[cjangus at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Cameron Angus  ---
Separating the attachments got me just under the limit.

[Bug middle-end/119559] [15 regression] GOMP: ICE in modify_call_for_omp_dispatch

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

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

This was an(other) 'ICE for invalid code after issuing the proper error
message' issue.

[Bug c++/119564] ICE using module including boost headers

[cjangus at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Cameron Angus  ---
Created attachment 60949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60949&action=edit
Preprocessed source for consuming TU

[Bug middle-end/119537] assume with statement expression and ("non-local") label

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

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

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

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

commit r15-9124-ga6c2248cfd4bc922378f554578ee44e6b4690f5d
Author: Jakub Jelinek 
Date:   Tue Apr 1 11:40:58 2025 +0200

gimple-low: Diagnose assume attr expressions defining labels which are used
as unary && operands outside of those [PR119537]

The following testcases ICE on invalid code which defines
labels inside of statement expressions and then uses &&label
from code outside of the statement expressions.
The C++ FE diagnoses that with a warning (not specifically for
assume attribute, genericallly about taking address of a label
outside of a statement expression so computed goto could violate
the requirement that statement expression is not entered from
outside of it through a jump into it), the C FE doesn't diagnose
anything.
Normal direct gotos to such labels are diagnosed by both C and C++.
In the assume attribute case it is actually worse than for
addresses of labels in normal statement expressions, in that case
the labels are still in the current function, so invalid program
can still jump to those (and in case of OpenMP/OpenACC where it
is also invalid and stuff is moved to a separate function, such
movement is done post cfg discovery of FORCED_LABELs and worst
case one can run into cases which fail to assemble, but I haven't
succeeded in creating ICE for that).
For assume at -O0 we'd just throw away the assume expression if
it is not a simple condition and so the label is then not defined
anywhere and we ICE during cfg pass.
The gimplify.cc hunks fix that, as we don't have FORCED_LABELs
discovery done yet, it preserves all assume expressions which contain
used user labels.
With that we ICE during IRA, which is upset about an indirect jump
to a label which doesn't exist.
So, the gimple-low.cc hunks add diagnostics of the problem, it gathers
uids of all the user used labels inside of the assume expressions (usually
none) and if it finds any, walks the IL to find uses of those from outside
of those expressions now outlined into separate magic functions.

2025-04-01  Jakub Jelinek  

PR middle-end/119537
* gimplify.cc (find_used_user_labels): New function.
(gimplify_call_expr): Don't remove complex assume expression at -O0
if it defines any user labels.
* gimple-low.cc: Include diagnostic-core.h.
(assume_labels): New variable.
(diagnose_assume_labels): New function.
(lower_function_body): Call it via walk_gimple_seq if assume_labels
is non-NULL, then BITMAP_FREE assume_labels.
(find_assumption_locals_r): Record in assume_labels uids of user
labels defined in assume attribute expressions.

* c-c++-common/pr119537-1.c: New test.
* c-c++-common/pr119537-2.c: New test.

[Bug gcov-profile/119535] v2: musttail vs -fprofile-generate

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

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

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

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

commit r15-9126-gb8de7704428dfe008d195d8da95d6772153b0cc7
Author: Jakub Jelinek 
Date:   Tue Apr 1 11:45:16 2025 +0200

profile: Another profiling musttail call fix [PR119535]

As the following testcase shows, EDGE_FAKE edges from musttail calls to
EXIT aren't the only edges we should ignore, we need to ignore also
edges created by the splitting of blocks for the EDGE_FAKE creation that
point from the musttail calls to the fallthrough block, which typically
does
the return or with PHIs for the return value.

2025-04-01  Jakub Jelinek  

PR gcov-profile/119535
* profile.cc (branch_prob): Ignore any edges from bbs ending with
musttail call, rather than only EDGE_FAKE edges from those to EXIT.

* c-c++-common/pr119535.c: New test.

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

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

https://gcc.gnu.org/g:02409a145946ca0d4f502f43fc3cc20de8b3dea1

commit r15-9125-g02409a145946ca0d4f502f43fc3cc20de8b3dea1
Author: Jakub Jelinek 
Date:   Tue Apr 1 11:43:16 2025 +0200

tailr: Punt on tail recursions that would break musttail [PR119493]

While working on the previous tailc patch, I've noticed the following
problem.
The testcase below fails, because we decide to tail recursion optimize
the call, but tail recursion (as documented in tree-tailcall.cc) needs to
add some result multiplication and/or addition if any tail recursion uses
accumulator, which is added right before the return.
So, if there are musttail non-recurive calls in the function, successful
tail recursion optimization will mean we'll later error on the musttail
calls.  musttail recursive calls are ok, those would be tail recursion
optimized.

So, the following patch punts on all tail recursion optimizations if it
needs accumulators (add and/or mult) if there is at least one non-recursive
musttail call.

2025-04-01  Jakub Jelinek  

PR tree-optimization/119493
* tree-tailcall.cc (tree_optimize_tail_calls_1): Ignore tail
recursion
candidates which need accumulators if there is at least one
musttail
non-recursive call.

* gcc.dg/pr119493-2.c: New test.

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to 康桓瑋 from comment #9)
> Still need casting the return difference type from __mindist, I think?

Ah yes, we need to cast it back to the type of the first argument.

So maybe __mindist isn't actually worth it, and it would be simpler to do:

if (auto __d = __olast - __ofirst; __d < __n)
  __n = static_cast>(__d);

I think the integer-class type requirements guarantee we can do __d < __n
directly, without explicit conversions. Only the assignment to __n needs an
explicit conversion.

[Bug c/119568] [avr] ICE: in find_widening_optab_handler_and_mode, at optabs-query.cc:498

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

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

--- Comment #1 from Georg-Johann Lay  ---
So the ICE occurs with checking enabled, and otherwise it goes into hog mode:

gcc_checking_assert (GET_MODE_CLASS (from_mode) == GET_MODE_CLASS (to_mode)
 && from_mode < to_mode);

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #11 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to 康桓瑋 from comment #9)
> > Still need casting the return difference type from __mindist, I think?
> 
> Ah yes, we need to cast it back to the type of the first argument.
> 
> So maybe __mindist isn't actually worth it, and it would be simpler to do:
> 
>   if (auto __d = __olast - __ofirst; __d < __n)
> __n = static_cast>(__d);
> 

Agreed. Or __n = staitc_cast(__d).

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

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

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

--- Comment #5 from Robin Dapp  ---
Do you happen to have an excution test ready so I can have a look?

[Bug c++/119563] internal compiler error on vector initialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code

[Bug c++/119563] [15 Regression] internal compiler error on large enough vector initialization

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

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

--- Comment #3 from Andrew Pinski  ---
920   sub = subsubconvs[i];
921   if (sub->rank > t->rank)
(gdb) p sub
$1 = (conversion *) 0x0
(gdb) p j
$1 = 0

[Bug tree-optimization/119532] [avr] ICE: in build_minus_one_cst with _Accum/_Fract types , at tree.cc:2698

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
OK, well.  Let me queue it for backporting, it's quite low risk.  It's also low
priority for me since it's not a regression and only affects AVR and MIPS.

[Bug tree-optimization/119552] Deduplicate __divmodbitint4 calls for quotient and remainder

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |15.0
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
pass_optimize_widening_mul handles divmod, it would be natural to amend that in
some way.

[Bug target/119369] GCN: weak undefined symbols -> execution test FAIL, 'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:816335960d020eac92d49bc9cd13729afd313da7

commit r15-9122-g816335960d020eac92d49bc9cd13729afd313da7
Author: Thomas Schwinge 
Date:   Sun Mar 30 14:54:01 2025 +0200

GCN, libstdc++: '#define _GLIBCXX_USE_WEAK_REF 0' [PR119369]

This fixes a few hundreds of compilation/linking FAILs (similar to
PR69506),
where the GCN/LLVM 'ld' reported:

ld: error: relocation R_AMDGPU_REL32_LO cannot be used against symbol
'_ZGTtnam'; recompile with -fPIC
>>> defined in
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
>>> referenced by cow-stdexcept.cc:259
([...]/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
>>>  
cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*,
void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a

ld: error: relocation R_AMDGPU_REL32_HI cannot be used against symbol
'_ZGTtnam'; recompile with -fPIC
>>> defined in
[...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a(cow-stdexcept.o)
>>> referenced by cow-stdexcept.cc:259
([...]/source-gcc/libstdc++-v3/src/c++11/cow-stdexcept.cc:259)
>>>  
cow-stdexcept.o:(_txnal_cow_string_C1_for_exceptions(void*, char const*,
void*)) in archive [...]/amdgcn-amdhsa/./libstdc++-v3/src/.libs/libstdc++.a

[...]

..., which is:

$ c++filt _ZGTtnam
transaction clone for operator new[](unsigned long)

..., and similarly for other libitm symbols.

However, the affected test cases, if applicable, then run into execution
test
FAILs, due to PR119369
"GCN: weak undefined symbols -> execution test FAIL,
'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'".

PR target/119369
libstdc++-v3/
* config/cpu/gcn/cpu_defines.h: New.
* configure.host [GCN] (cpu_defines_dir): Point to it.

[Bug target/119369] GCN: weak undefined symbols -> execution test FAIL, 'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'

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

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

--- Comment #8 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r15-9123-g2f58d8ac03911063d6a8887a2bee7b4e25ac1871
Author: Thomas Schwinge 
Date:   Mon Mar 31 09:55:14 2025 +0200

GCN: Don't emit weak undefined symbols [PR119369]

This resolves all instances of PR119369
"GCN: weak undefined symbols -> execution test FAIL,
'HSA_STATUS_ERROR_VARIABLE_UNDEFINED'";
for all affected test cases, the execution test status progresses FAIL ->
PASS.

This however also causes a small number of (expected) regressions, very
similar
to GCC/nvptx:

[-PASS:-]{+FAIL:+} g++.dg/abi/pure-virtual1.C  -std=c++17 (test for
excess errors)
[-PASS:-]{+FAIL:+} g++.dg/abi/pure-virtual1.C  -std=c++26 (test for
excess errors)
[-PASS:-]{+FAIL:+} g++.dg/abi/pure-virtual1.C  -std=c++98 (test for
excess errors)

[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++11  scan-assembler
.weak[ \t]*_?_ZTH11derived_obj
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++11  scan-assembler
.weak[ \t]*_?_ZTH13container_obj
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++11  scan-assembler
.weak[ \t]*_?_ZTH8base_obj
PASS: g++.dg/cpp0x/pr84497.C  -std=c++11 (test for excess errors)
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++17  scan-assembler
.weak[ \t]*_?_ZTH11derived_obj
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++17  scan-assembler
.weak[ \t]*_?_ZTH13container_obj
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++17  scan-assembler
.weak[ \t]*_?_ZTH8base_obj
PASS: g++.dg/cpp0x/pr84497.C  -std=c++17 (test for excess errors)
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++26  scan-assembler
.weak[ \t]*_?_ZTH11derived_obj
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++26  scan-assembler
.weak[ \t]*_?_ZTH13container_obj
[-PASS:-]{+FAIL:+} g++.dg/cpp0x/pr84497.C  -std=c++26  scan-assembler
.weak[ \t]*_?_ZTH8base_obj
PASS: g++.dg/cpp0x/pr84497.C  -std=c++26 (test for excess errors)

[-PASS:-]{+FAIL:+} g++.dg/ext/weak2.C  -std=gnu++17  scan-assembler
weak[^ \t]*[ \t]_?_Z3foov
PASS: g++.dg/ext/weak2.C  -std=gnu++17 (test for excess errors)
[-PASS:-]{+FAIL:+} g++.dg/ext/weak2.C  -std=gnu++26  scan-assembler
weak[^ \t]*[ \t]_?_Z3foov
PASS: g++.dg/ext/weak2.C  -std=gnu++26 (test for excess errors)
[-PASS:-]{+FAIL:+} g++.dg/ext/weak2.C  -std=gnu++98  scan-assembler
weak[^ \t]*[ \t]_?_Z3foov
PASS: g++.dg/ext/weak2.C  -std=gnu++98 (test for excess errors)

[-PASS:-]{+FAIL:+} gcc.dg/attr-weakref-1.c (test for excess errors)
[-FAIL:-]{+UNRESOLVED:+} gcc.dg/attr-weakref-1.c [-execution
test-]{+compilation failed to produce executable+}

@@ -131211,25 +131211,25 @@ PASS: gcc.dg/weak/weak-1.c scan-assembler
weak[^ \t]*[ \t]_?c
PASS: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?d
PASS: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?e
PASS: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?g
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[
\t]_?j
PASS: gcc.dg/weak/weak-1.c scan-assembler-not weak[^ \t]*[ \t]_?i

PASS: gcc.dg/weak/weak-12.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[
\t]_?foo

PASS: gcc.dg/weak/weak-15.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-15.c scan-assembler weak[^ \t]*[
\t]_?a
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-15.c scan-assembler weak[^ \t]*[
\t]_?c
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-15.c scan-assembler weak[^ \t]*[
\t]_?d
PASS: gcc.dg/weak/weak-15.c scan-assembler-not weak[^ \t]*[ \t]_?b

PASS: gcc.dg/weak/weak-16.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-16.c scan-assembler weak[^ \t]*[
\t]_?kallsyms_token_index
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-16.c scan-assembler weak[^ \t]*[
\t]_?kallsyms_token_table
PASS: gcc.dg/weak/weak-2.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[
\t]_?ffoo1a
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[
\t]_?ffoo1b
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[
\t]_?ffoo1c
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[
\t]_?ffoo1e
PASS: gcc.dg/weak/weak-2.c scan-assembler-not weak[^ \t]*[ \t]_?ffoo1d

PASS: gcc.dg/weak/weak-3.c  (test for warnings, line 58)
PASS: gcc.dg/weak/weak-3.c  (test for warnings, line 73)
PASS: gcc.dg/weak/weak-3.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[
\t]_?ffoo1a
[-PASS:-]{+FAIL:+} gcc.dg/weak/weak-3.c sc

[Bug c++/113958] support visibility attribute for typeinfo symbol

[mail at milianw dot de via Gcc-bugs]

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

Milian Wolff  changed:

   What|Removed |Added

 CC||mail at milianw dot de

--- Comment #5 from Milian Wolff  ---
If anyone implements this (please do!), then please follow the behavior of
clang which seems to have this distinction (TIL). But when you do, also add a
global compilation flag, see e.g.
https://github.com/llvm/llvm-project/issues/133905

[Bug c++/119566] internal compiler error: in unify, at cp/pt.cc:25410

[gessos.paul at yahoo dot gr via Gcc-bugs]

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

--- Comment #2 from Chameleon  ---
Created attachment 60951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60951&action=edit
file.ii

[Bug c/119173] Documentation for -Wzero-as-null-pointer-constant should move to Warning Options

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

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

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

https://gcc.gnu.org/g:182d891e13c78187f5e4f76512e03297fea0e56a

commit r15-9127-g182d891e13c78187f5e4f76512e03297fea0e56a
Author: Martin Uecker 
Date:   Sun Mar 30 13:07:24 2025 +0200

Doc: -Wzero-as-null-pointer-constant is also available for C [PR119173]

The warning -Wzero-as-null-pointer-constant is now not only supported
in C++ but also in C.  Change the documentation accordingly.

PR c/119173

gcc/ChangeLog:
* doc/invoke.texi (Warning Options): Move to general options.

[Bug c/113688] verify_type fails for compatible structs with FAM in C23, builtin-sprintf-warn-1.c and gnu23-tag-1.c with -g

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[14 regression] verify_type |verify_type fails for
   |fails for compatible|compatible structs with FAM
   |structs with FAM in C23,|in C23,
   |builtin-sprintf-warn-1.c|builtin-sprintf-warn-1.c
   |and gnu23-tag-1.c with -g   |and gnu23-tag-1.c with -g

--- Comment #12 from uecker at gcc dot gnu.org ---
fixed for 14.3

[Bug c++/119564] ICE using module including boost headers

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org

--- Comment #8 from Nathaniel Shead  ---
On current trunk I also cannot reproduce, I suspect due to the more aggressive
GMF discarding since r15-7906-gb360d4aafc1356 from looking at the source files.

But when attempting to build having reverted that commit I get a different ICE,
which appears to be the same issue as PR118904.

[Bug c/119173] Documentation for -Wzero-as-null-pointer-constant should move to Warning Options

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from uecker at gcc dot gnu.org ---
fixed.

[Bug c/114723] ICE when checking for type compatibility with structure that contains flexible array member (C23)

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

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

Bug 113688 Summary: verify_type fails for compatible structs with FAM in C23, 
builtin-sprintf-warn-1.c and gnu23-tag-1.c with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688

   What|Removed |Added

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

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So I wonder if both of the
  tree boff = size_binop (MULT_EXPR, TYPE_SIZE (idx_type),
  bitsize_int (k + elt_offset));
  tree idx
= gimple_build (&stmts, BIT_FIELD_REF, idx_type,
vec_offset, TYPE_SIZE (idx_type), boff);
and
  tree boff = size_binop (MULT_EXPR, TYPE_SIZE (idx_type),
  bitsize_int (k + elt_offset));
  tree idx
= gimple_build (&stmts, BIT_FIELD_REF, idx_type,
vec_offset, TYPE_SIZE (idx_type),
boff);
spots don't need special treatment for
VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (vec_offset))
&& SCALAR_INT_MODE_P (TYPE_MODE (TREE_TYPE (vec_offset))
but dunno what that special handling should be exactly.
VCE it to the corresponding integer type, shift right by elt_offset and mask of
least significant bit?
Are there VECTOR_BOOLEAN_TYPE_P where one element is represented by more than
one bits?

[Bug middle-end/114563] ggc_internal_alloc is slow

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

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

--- Comment #12 from Richard Biener  ---
(In reply to andi from comment #8)
> > > Needs a workload where it matters
> > 
> > PR119387 had
> > 
> >   85.81%   1500713  cc1plus  cc1plus   [.]
> > ggc_internal_alloc(un
> > 
> > for me.  Can we keep an index to freelist from allocation order to avoid
> > the linear search? 
> 
> Yes for the alloc
> 
> > Other than that the patch looks simple than I thought,
> > and it definitely resolves an algorithmic complexity issue, so even without
> > a clear workload where it matters it should be OK (during stage1, that is).
> 
> The main drawback is that the madvise patterns to the OS are worse
> because it will do it in smaller chunks. That was the reason I had
> second thoughts later.

Btw, for this, sth I also wondered before, we'd likely want to change
alloc_page when it does

#ifdef USING_MMAP
  else if (entry_size == G.pagesize)
{
  /* We want just one page.  Allocate a bunch of them and put the
 extras on the freelist.  (Can only do this optimization with
 mmap for backing store.)  */
  struct page_entry *e, *f = free_list->free_pages;
  int i, entries = GGC_QUIRE_SIZE;


to do this for entry_size < G.pagesize * GGC_QUIRE_SIZE, this should
avoid fragmenting the virtual address space.  Possibly do this only
for USING_MADVISE, not sure.

[Bug tree-optimization/119568] [avr] ICE: in find_widening_optab_handler_and_mode, at optabs-query.cc:498

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2025-04-01
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
find_widening_optab_handler_and_mode simply does not handle
op=umadd_widen_optab, to_mode=E_USAmode, from_mode=E_UHQmode

Probably the bug is upstream in the widening_mul pass which
likely looks trough the apparent widening of the _Fract arg
to the _Accum multiplication.

[Bug tree-optimization/119534] [12/13/14 Regression] ICE when building libaom-3.10.0 since r12-5392

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||15.0
Summary|[12/13/14/15 regression]|[12/13/14 Regression] ICE
   |ICE when building   |when building libaom-3.10.0
   |libaom-3.10.0 since |since r12-5392
   |r12-5392|

--- Comment #13 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
The issue gather scatter detection - we do not anticipate the non-mask use in
the address calculation for the gather:

(gdb) p gs_info
$12 = {ifn = IFN_LAST, decl = , base = , 
  offset = , scale = 8, 
  offset_dt = vect_internal_def, 
  offset_vectype = , 
  element_type = , 
  memory_type = }
(gdb) p debug_generic_expr (0x76ceaa80)
vector(8) 

it's a bit difficult to avoid this during vect_check_gather_scatter where
we look through the conversion from _Bool to unsigned int given this happens
before pattern recog.  But we can catch it easily after the fact.

[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0 since r12-5392

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-9129-gd0cc14c62ad7403afcab3c2e38851d3ab179352f
Author: Richard Biener 
Date:   Tue Apr 1 14:13:03 2025 +0200

tree-optimization/119534 - reject bogus emulated vectorized gather

The following makes sure to reject the attempts to emulate a vector
gather when the discovered index vector type is a vector mask.

PR tree-optimization/119534
* tree-vect-stmts.cc (get_load_store_type): Reject
VECTOR_BOOLEAN_TYPE_P offset vector type for emulated gathers.

* gcc.dg/vect/pr119534.c: New testcase.

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

[zhijin.zeng at spacemit dot com via Gcc-bugs]

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

--- Comment #6 from 曾治金  ---
This issue report in https://github.com/opencv/opencv/issues/26936, and I
extract it into my test case. I just check the assemble code and don't run the
test case.


But if you need to run the opencv application to fix the issue, you can do it
as follow. 
1. download opencv
```
git clone https://github.com/opencv/opencv.git
git reset --hard 46dbc57a865594a5f9141a3a3b6878764df6cc0d

```
2. apply patch
```
diff --git a/modules/core/src/convert.simd.hpp
b/modules/core/src/convert.simd.hpp
index 841cb6f684..37a0f5b929 100644
--- a/modules/core/src/convert.simd.hpp
+++ b/modules/core/src/convert.simd.hpp
@@ -109,7 +109,7 @@ cvt_( const _Ts* src, size_t sstep, _Td* dst, size_t dstep,
Size size )
 {
 int j = 0;
 // Excluding GNU in CV_SIMD_SCALABLE because of "opencv/issues/26936"
-#if (CV_SIMD || (CV_SIMD_SCALABLE && !(defined(__GNUC__) &&
!defined(__clang__))) )
+#if (CV_SIMD || (CV_SIMD_SCALABLE))
 const int VECSZ = VTraits<_Twvec>::vlanes()*2;
 for( ; j < size.width; j += VECSZ )
 {
diff --git a/modules/core/src/convert_scale.simd.hpp
b/modules/core/src/convert_scale.simd.hpp
index aa998aed71..cfdf895b2a 100644
--- a/modules/core/src/convert_scale.simd.hpp
+++ b/modules/core/src/convert_scale.simd.hpp
@@ -92,7 +92,7 @@ template inline void
 cvt_32f( const _Ts* src, size_t sstep, _Td* dst, size_t dstep,
  Size size, float a, float b )
 {
-#if (CV_SIMD || (CV_SIMD_SCALABLE && !(defined(__GNUC__) &&
!defined(__clang__))) )
+#if (CV_SIMD || (CV_SIMD_SCALABLE) )
 v_float32 va = vx_setall_f32(a), vb = vx_setall_f32(b);
 const int VECSZ = VTraits::vlanes()*2;
 #endif
@@ -103,7 +103,7 @@ cvt_32f( const _Ts* src, size_t sstep, _Td* dst, size_t
dstep,
 {
 int j = 0;
 // Excluding GNU in CV_SIMD_SCALABLE because of "opencv/issues/26936"
-#if (CV_SIMD || (CV_SIMD_SCALABLE && !(defined(__GNUC__) &&
!defined(__clang__))) )
+#if (CV_SIMD || (CV_SIMD_SCALABLE) )
 for( ; j < size.width; j += VECSZ )
 {
 if( j > size.width - VECSZ )
@@ -164,7 +164,7 @@ template inline void
 cvt_64f( const _Ts* src, size_t sstep, _Td* dst, size_t dstep,
  Size size, double a, double b )
 {
-#if (CV_SIMD_64F || (CV_SIMD_SCALABLE_64F && !(defined(__GNUC__) &&
!defined(__clang__))) )
+#if (CV_SIMD_64F || (CV_SIMD_SCALABLE_64F) )
 v_float64 va = vx_setall_f64(a), vb = vx_setall_f64(b);
 const int VECSZ = VTraits::vlanes()*2;
 #endif
@@ -175,7 +175,7 @@ cvt_64f( const _Ts* src, size_t sstep, _Td* dst, size_t
dstep,
 {
 int j = 0;
 // Excluding GNU in CV_SIMD_SCALABLE because of "opencv/issues/26936"
-#if (CV_SIMD_64F || (CV_SIMD_SCALABLE_64F && !(defined(__GNUC__) &&
!defined(__clang__))) )
+#if (CV_SIMD_64F || (CV_SIMD_SCALABLE_64F) )
 for( ; j < size.width; j += VECSZ )
 {
 if( j > size.width - VECSZ )
```
3. build
add compile flag in opencv/platforms/linux/flags-riscv64.cmake
```
--param logical-op-non-short-circuit=0
```
```
SDK_DIR=/xxx/toolchain-path

cd ${WORKSPACE}/opencv

BUILD_TYPE=Release
BUILD_DIR=latest-4x

cmake -G Ninja -B cross-build/$BUILD_DIR-gcc \
  -DCMAKE_BUILD_TYPE=$BUILD_TYPE \
  -DCMAKE_C_COMPILER=$SDK_DIR/bin/riscv64-unknown-linux-gnu-gcc \
  -DCMAKE_CXX_COMPILER=$SDK_DIR/bin/riscv64-unknown-linux-gnu-g++ \
 
-DCMAKE_TOOLCHAIN_FILE=$WORKSPACE/opencv/platforms/linux/riscv64-gcc.toolchain.cmake
\
  -DCPU_BASELINE=RVV -DCPU_BASELINE_REQUIRE=RVV -DRISCV_RVV_SCALABLE=ON
-DWITH_OPENCL=OFF .

cmake --build cross-build/$BUILD_DIR-gcc --target opencv_test_core -j10
```
4. run
```
export LD_LIBRARY_PATH=//lib
./opencv_test_core --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"
```

[Bug ada/119571] [15 Regression] ggc-none.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used w hen making a PIE object; recompile with -fPIE

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

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

--- Comment #3 from Matthias Klose  ---
https://launchpad.net/ubuntu/+source/gcc-15-cross/5ubuntu1
https://launchpad.net/ubuntu/+source/gcc-15-cross-ports/6ubuntu1

[Bug ada/119571] [15 Regression] ggc-none.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used w hen making a PIE object; recompile with -fPIE

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||build
Version|14.2.1  |15.0
   Target Milestone|--- |15.0

--- Comment #2 from Sam James  ---
Can you share the full logs? I guess it may be to do with the host-pie changes
before for PR119440.

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

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

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

Victor Do Nascimento  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #8 from Victor Do Nascimento  ---
yeah, I can confirm it seems to be a a case of overly strict pattern-matching.

Rather than separate `scan-tree-dump's for each line, if we use a single one so
that we can use regex capture groups reaching across lines, we can remove any
reference to specific SSA names so that the test will continue to pass, even in
the event of changes to the variable numbering in the dumps.

Will submit a patch that passes on gcc14 as well as 15.

Cheers

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 106185 Summary: Spurious Wstringop-overflow in std::vector::resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106185

   What|Removed |Added

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

[Bug tree-optimization/106185] Spurious Wstringop-overflow in std::vector::resize

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107087
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #2 from Jonathan Wakely  ---
These warnings were fixed by richi's r13-6905 for Bug 107087:

  tree-optimization/107087 - missed CCP after forwprop

  When forwprop simplifies the CFG the 2nd order opportunities by
  exposed degenerate PHIs are not realized.  The following improves
  this by properly tracking executable edges and thus handling this
  for non-cyclic CFGs at least.

  This avoids the bogus diagnostic reported for the testcase in this PR.

[Bug target/119572] New: [15 Regression] Recent change triggers regression on RISC-V vector test

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

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

Bug ID: 119572
   Summary: [15 Regression] Recent change triggers regression on
RISC-V vector test
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

This change:

commit 70391e3958db791edea4e877636592de47a785e7
Author: Kyrylo Tkachov 
Date:   Mon Mar 24 01:53:06 2025 -0700

PR middle-end/119442: expr.cc: Fix vec_duplicate into vector boolean modes

In this testcase GCC tries to expand a VNx4BI vector:
  vector(4)  _40;
  _39 = () _24;
  _40 = {_39, _39, _39, _39};
[ ... ]

Is triggering this failure on RISC-V:

Tests that now fail, but worked before (1 tests):

unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc:
gcc.target/riscv/rvv/autovec/pr119114.c -O3 -ftree-vectorize execution test


Neither Robin nor I have done any debugging on this, though we have a suspicion
that it's likely a target specific issue, possibly with vsetvl handling.

[Bug target/119572] [15 Regression] Recent change triggers regression on RISC-V vector test

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Priority|P3  |P1
 Target||riscv

--- Comment #1 from Jeffrey A. Law  ---
P1 until we know if it's a generic optimizer vs target issue.

[Bug c++/119563] New: internal compiler error on vector initialization

[germant at miltenyi dot com via Gcc-bugs]

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

Bug ID: 119563
   Summary: internal compiler error on vector initialization
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: germant at miltenyi dot com
  Target Milestone: ---

Created attachment 60945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60945&action=edit
Preprocessed source

g++ fails with a segmentation fault while compiling a program that contains
only the initialization of a std::vector. Further information:

Reading specs from
/home/germant/gcc/15/lib/gcc/x86_64-pc-linux-gnu/15.0.1/specs
COLLECT_GCC=/home/germant/gcc/15/bin/g++
COLLECT_LTO_WRAPPER=/home/germant/gcc/15/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-15-20250330/configure --prefix=/home/germant/gcc/15
--enable-languages=c,c++,rust --enable-shared --without-included-gettext
--enable-threads=posix --enable-multiarch --disable-werror --with-tune=generic
--without-cuda-driver --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250330 (experimental) (GCC)
>uname -a
uname -a
Linux ccptmb 5.4.0-176-generic #196-Ubuntu SMP Fri Mar 22 16:46:39 UTC 2024
x86_64 x86_64 x86_64 GNU/Linux
>g++ --save-temps -c t.cpp -o t
t.cpp:28:55: internal compiler error: Segmentation fault
   28 |   143, 142, 140, 138, 136, 136, 132, 132, 107, 105, 89};
  |   ^
0x29a9f9f internal_error(char const*, ...)
../../gcc-15-20250330/gcc/diagnostic-global-context.cc:517
0x14a50af crash_signal
../../gcc-15-20250330/gcc/toplev.cc:322
0x7f8dfbe7908f ???
   
/build/glibc-FcRMwW/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xb2f8db build_list_conv
../../gcc-15-20250330/gcc/cp/call.cc:921
0xb2f8db implicit_conversion
../../gcc-15-20250330/gcc/cp/call.cc:2197
0xb32ca8 add_function_candidate
../../gcc-15-20250330/gcc/cp/call.cc:2637
0xb34650 add_candidates
../../gcc-15-20250330/gcc/cp/call.cc:6866
0xb352de add_candidates
../../gcc-15-20250330/gcc/cp/call.cc:6678
0xb352de add_list_candidates
../../gcc-15-20250330/gcc/cp/call.cc:4314
0xb2dd0f build_user_type_conversion_1
../../gcc-15-20250330/gcc/cp/call.cc:4601
0xb2eaf4 implicit_conversion
../../gcc-15-20250330/gcc/cp/call.cc:2249
0xb2fbdf perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc-15-20250330/gcc/cp/call.cc:13979
0xbb4032 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc-15-20250330/gcc/cp/cvt.cc:951
0xc31fde expand_default_init
../../gcc-15-20250330/gcc/cp/init.cc:2175
0xc31fde expand_aggr_init_1
../../gcc-15-20250330/gcc/cp/init.cc:2361
0xc34513 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc-15-20250330/gcc/cp/init.cc:2080
0xbfb0c1 build_aggr_init_full_exprs
../../gcc-15-20250330/gcc/cp/decl.cc:7793
0xbfb0c1 check_initializer
../../gcc-15-20250330/gcc/cp/decl.cc:7958
0xbff912 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
../../gcc-15-20250330/gcc/cp/decl.cc:9201
0xd1892a cp_parser_init_declarator
../../gcc-15-20250330/gcc/cp/parser.cc:24277
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 target/119547] RISC-V: VSETVL mistakenly modified other data

[zhijin.zeng at spacemit dot com via Gcc-bugs]

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

--- Comment #3 from 曾治金  ---
Hi, it will reproduce by gcc 14.2. And in gcc upstream code, you need to add
`--param logical-op-non-short-circuit=0` flag to reproduce. This is because the
default value of LOGICAL_OP_NON_SHORT_CIRCUIT of risc-v is changed by commit
34ae3a99. However, I don't think the commit 34ae3a99 have fixed this bug and it
merely conceals this bug by modifying the CFG structure.

[Bug c++/119436] [12/13/14/15 regression] ICE in pop_local_binding, at cp/name-lookup.cc:2636 since r0-96917

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #3 from Simon Martin  ---
Working on this one.

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

[zhijin.zeng at spacemit dot com via Gcc-bugs]

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

--- Comment #7 from 曾治金  ---
(In reply to Li Pan from comment #2)
> Any information about gcc version? Seems asm layout is different from
> today's upstream. CC RISC-V relatives.
> 
>  123   │ .L41:
>  124   │ addiw   t2,t2,1
>  125   │ vsetvli a3,zero,e8,mf2,ta,ma
>  126   │ bne s0,t2,.L44
>  127   │ .L33:
>  128   │ ld  s1,64(sp)
>  129   │ .cfi_restore 9
>  130   │ ld  s2,56(sp)
>  131   │ .cfi_restore 18
>  132   │ ld  s3,48(sp)
>  133   │ .cfi_restore 19
>  134   │ ld  s4,40(sp)
>  135   │ .cfi_restore 20
>  136   │ ld  s5,32(sp)
>  137   │ .cfi_restore 21
>  138   │ ld  s6,24(sp)
>  139   │ .cfi_restore 22
>  140   │ .L31:
>  141   │ ld  s0,72(sp)
>  142   │ .cfi_restore 8
>  143   │ addisp,sp,80
>  144   │ .cfi_def_cfa_offset 0
>  145   │ jr  ra
>  146   │ .L43:
>  147   │ .cfi_def_cfa_offset 80
>  148   │ .cfi_offset 8, -8
>  149   │ .cfi_offset 9, -16
>  150   │ .cfi_offset 18, -24
>  151   │ .cfi_offset 19, -32
>  152   │ .cfi_offset 20, -40
>  153   │ .cfi_offset 21, -48
>  154   │ .cfi_offset 22, -56
>  155   │ sllis4,a4,3
>  156   │ add a5,a0,a4
>  157   │ .L11:
>  158   │ sllia7,s5,32
>  159   │ srlia7,a7,32
>  160   │ add a4,a2,s4
>  161   │ add a7,a7,a5
>  162   │ .L15:
>  163   │ lb  t1,0(a5)
>  164   │ addia5,a5,1
>  165   │ addia4,a4,8
>  166   │ fcvt.d.wfa5,t1
>  167   │ fmadd.d fa5,fa5,fa0,fa1
>  168   │ fsd fa5,-8(a4)
>  169   │ bne a5,a7,.L15
>  170   │ j   .L34

Sorry, I make a mistake. You need to add `--param
logical-op-non-short-circuit=0` to reproduce in gcc upstream code.

[Bug c++/119564] New: ICE using module including boost headers

[cjangus at gmail dot com via Gcc-bugs]

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

Bug ID: 119564
   Summary: ICE using module including boost headers
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjangus at gmail dot com
  Target Milestone: ---

The following repro is a partial reduction of original code that was using
boost.json, but at some point it became impossible to reduce further so this is
a preprocessed repro from the point I'd got it down to.

There are two translation units:
- a module interface which includes boost code into its GMF and has an empty
purview; this compiles successfully
- a regular translation unit which includes a std header, then imports the
above module; this triggers an ICE

Command lines:

g++ -fPIC -Og -g -Wall -fmodules -std=c++2b -finput-charset=UTF-8 -o
out/repro_module.a.gcm.o -c -x c++ -fpreprocessed -fdirectives-only
repro_module.a.gcm.ii
g++ -fPIC -Og -g -Wall -fmodules -std=c++2b -finput-charset=UTF-8 -o
out/repro_consumer.a.o -c -x c++ -fpreprocessed -fdirectives-only
repro_consumer.a.o.ii

Output:

/.../gcc_repro.cpp: In function ‘(static initializers for /.../gcc_repro.cpp)’:
/.../gcc_repro.cpp:4:20: internal compiler error: in
tree_node_structure_for_code, at tree.cc:603
4 | import gcc_repro_a;

System/version:

Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-latest --enable-languages=c,c++
--enable-libstdcxx-debug --enable-libstdcxx-backtrace --disable-bootstrap
--disable-multilib --disable-libvtv --disable-libssp --disable-libffi
--with-system-zlib --without-isl --with-arch_64=x86-64-v2
--with-bugurl=https://gcc.gnu.org/bugzilla
gcc version 15.0.1 20250223 (experimental) (GCC)

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pavol at rusnak dot io

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

[Bug c/117689] enum with underying type "extension" to GNU 17 is not documented

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed.

[Bug target/119578] internal compiler error when building torch-2.6.0 on aarch64-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Yes it is a dup. Even the same source.

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

[Bug c++/119578] internal compiler error when building torch-2.6.0 on aarch64-linux

[pavol at rusnak dot io via Gcc-bugs]

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

--- Comment #2 from pavol at rusnak dot io ---
Created attachment 60954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60954&action=edit
preprocessed input (zipped)

[Bug c++/119578] internal compiler error when building torch-2.6.0 on aarch64-linux

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

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

--- Comment #4 from Sam James  ---
Reducing.

[Bug c/117689] enum with underying type "extension" to GNU 17 is not documented

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

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

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

https://gcc.gnu.org/g:42b2fc3fc9c06c174ec4d2c0566f54b624bc70b5

commit r15-9137-g42b2fc3fc9c06c174ec4d2c0566f54b624bc70b5
Author: Sandra Loosemore 
Date:   Tue Apr 1 19:34:14 2025 +

Doc: Document enum with underlying type extension [PR117689]

This is a C23/C++11 feature that is supported as an extension with
earlier -std= options too, but was never previously documented.  It
interacts with the already-documented forward enum definition extension,
so I have merged discussion of the two extensions into the same section.

gcc/ChangeLog
PR c/117689
* doc/extend.texi (Incomplete Enums): Rename to
(Enum Extensions): This.  Document support for specifying the
underlying type of an enum as an extension in all earlier C
and C++ standards.  Document that a forward declaration with
underlying type is not an incomplete type, and which dialects
GCC supports that in.

[Bug target/119578] internal compiler error when building torch-2.6.0 on aarch64-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Target||aarch64
 Ever confirmed|1   |0
  Component|c++ |target

[Bug c++/119566] internal compiler error: in unify, at cp/pt.cc:25410

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda

--- Comment #4 from Andrew Pinski  ---
Looking lambda related.

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

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

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

--- Comment #54 from Alexander Monakov  ---
I think the x86_64 behavior is simply copied as-is from i386.

On i386, there was a time when Glibc wouldn't preserve eax+ecx+edx in the PLT
trampoline, but preserving those became necessary when GCC exposed -mregparm
and the corresponding function attribute.

https://sourceware.org/cgit/glibc/diff/sysdeps/i386/dl-machine.h?id=831372e7c1bb907f9f2c3d78909b15717b8ac095

It doesn't really explain to me why PLT avoidance for mcount was necessary
(cross-DSO regparm calls with unfixed Glibc would be buggy for everything, not
just mcount), and apparently the avoidance goes back even further than that, to
a.out times. So the relevance to the matter at hand is unclear.

On amd64, PLT trampolines may clobber r11 (and lazy resolution trampolines
always do). So, yeah, looks like inherited PLT avoidance plays some role now
(even if by accident).

[Bug tree-optimization/113239] [13/14 regression] After r13-6372-g822a11a1e642e0, bogus -Warray-bounds warnings in std::vector

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||13.3.0, 14.2.0
  Known to work||12.4.0, 15.0
Summary|[13/14/15 regression] After |[13/14 regression] After
   |r13-6372-g822a11a1e642e0,   |r13-6372-g822a11a1e642e0,
   |bogus -Warray-bounds|bogus -Warray-bounds
   |warnings in std::vector |warnings in std::vector

--- Comment #13 from Jonathan Wakely  ---
My bisection shows the warning went away with r15-575-gda73261ce7731b itself,
not the fix for it. Either way, it's fixed on trunk.

[Bug c++/119551] [modules] ICE when reading inline var referencing TU-local entity

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:0210bedf481a9fd248ce29650b824bcd84c3723c

commit r15-9136-g0210bedf481a9fd248ce29650b824bcd84c3723c
Author: Nathaniel Shead 
Date:   Tue Apr 1 16:36:30 2025 +1100

c++/modules: Forbid exposures of TU-local entities in inline variables
[PR119551]

An inline variable has vague linkage, and needs to be conditionally
emitted in TUs that reference it.  Unfortunately this clashes with
[basic.link] p14.2, which says that we ignore the initialisers of all
variables (including inline ones), since importers will not have access
to the referenced TU-local entities to write the definition.

This patch makes such exposures be ill-formed.  One case that continues
to work is if the exposure is part of the dynamic initialiser of an
inline variable; in such cases, the definition has been built as part of
the module interface unit anyway, and importers don't need to write it
out again, so such exposures are "harmless".

PR c++/119551

gcc/cp/ChangeLog:

* module.cc (trees_out::write_var_def): Only ignore non-inline
variable initializers.

gcc/testsuite/ChangeLog:

* g++.dg/modules/internal-5_a.C: Add cases that should be
ignored.
* g++.dg/modules/internal-5_b.C: Test these new cases, and make
the testcase more robust.
* g++.dg/modules/internal-11.C: New test.
* g++.dg/modules/internal-12_a.C: New test.
* g++.dg/modules/internal-12_b.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug target/119578] internal compiler error when building torch-2.6.0 on aarch64-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=118892

--- Comment #5 from Andrew Pinski  ---
Note PR 118892 is not fixed on the 14 branch so it might be a dup of that one.

[Bug c++/111374] Spurious -Warray-bounds warning when building std::vector (or libstdc++ bug?)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-04-01

--- Comment #1 from Jonathan Wakely  ---
It's just a false positive warning, not a libstdc++ bug.

I suspect this is fixed on trunk (by r15-4473-g3abe751ea86e34) but without a
proper testcase it's impossible to tell.

[Bug fortran/119579] New: Derived type not initialized correctly with array sections

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Bug ID: 119579
   Summary: Derived type not initialized correctly with array
sections
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vivekrao4 at yahoo dot com
  Target Milestone: ---

For the code

module dataframe_mod
  implicit none
  private
  public :: DataFrame, display, subset_stride

  type :: DataFrame
 real(kind=4), allocatable :: values(:,:)
  end type DataFrame

contains

  subroutine display(self)
class(DataFrame) :: self
integer :: i
do i = 1, UBOUND(self%values,dim=1)
   write(*,"(1x,A,I1,*(1x,f10.4))") "row: ", i, self%values(i,:)
end do
  end subroutine display

  function subset_stride(df) result(df_new)
type(DataFrame) :: df
type(DataFrame) :: df_new
!...suspect below ...
df_new = DataFrame(values  = df%values(1:8:3, :))
!...can fix this by explicitly setting result df_new
! uncomment_for_working_testcase 
!allocate(df_new%values(3,2))
!df_new%values(1,:) = [ 1.1, 1.2 ]
!df_new%values(2,:) = [ 4.1, 4.2 ]
!df_new%values(3,:) = [ 7.1, 7.2 ]
  end function subset_stride

end module dataframe_mod

program xxdataframe
  use dataframe_mod
  implicit none
  type(DataFrame) :: df, df_new
  allocate(df%values(8,2) )
   df%values(1,:) = [ 1.1, 1.2 ]
   df%values(2,:) = [ 2.1, 2.2 ]
   df%values(3,:) = [ 3.1, 3.2 ]
   df%values(4,:) = [ 4.1, 4.2 ]
   df%values(5,:) = [ 5.1, 5.2 ]
   df%values(6,:) = [ 6.1, 6.2 ]
   df%values(7,:) = [ 7.1, 7.2 ]
   df%values(8,:) = [ 8.1, 8.2 ]
  write(*,*) "display initial values of df"
   call display(df)
  write(*,*)

  df_new = subset_stride(df)
  write(*,*) "print df_new, should have rows 1, 4, 7 "
  write(*,*) "shape(df_new%values)", shape(df_new%values)
  write(*,*) "bounds of df_new%values, dim 1: ", LBOUND(df_new%values,1),
UBOUND(df_new%values,1)
  write(*,*) "bounds of df_new%values, dim 2: ", LBOUND(df_new%values,2),
UBOUND(df_new%values,2)
  call display(df_new)
end program xxdataframe

from
https://fortran-lang.discourse.group/t/derived-type-initialized-with-array-sections-giving-unexpected-results/9470/5?u=beliavsky

gfortran gives incorrect output

 display initial values of df
 row: 1 1.1000 1.2000
 row: 2 2.1000 2.2000
 row: 3 3.1000 3.2000
 row: 4 4.1000 4.2000
 row: 5 5.1000 5.2000
 row: 6 6.1000 6.2000
 row: 7 7.1000 7.2000
 row: 8 8.1000 8.2000

 print df_new, should have rows 1, 4, 7 
 shape(df_new%values)   3   2
 bounds of df_new%values, dim 1:1   3
 bounds of df_new%values, dim 2:1   2
 row: 1 1.1000 1.2000
 row: 2 2.1000 2.2000
 row: 3 3.1000 3.2000

[Bug fortran/119579] Derived type not initialized correctly with array sections

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Already reported in pr119478.

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

[Bug fortran/119478] structure constructor is using the wrong stride

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vivekrao4 at yahoo dot com

--- Comment #2 from anlauf at gcc dot gnu.org ---
*** Bug 119579 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/117063] [13/14/15 Regression] Incorrect stringop-overread warning using std::vector::insert at -O3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||14.1.0, 14.2.0, 15.0
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-01
Summary|Incorrect stringop-overread |[13/14/15 Regression]
   |warning using   |Incorrect stringop-overread
   |std::vector::insert at -O3  |warning using
   ||std::vector::insert at -O3
  Known to work||13.3.0

--- Comment #1 from Jonathan Wakely  ---
The warning started with r14-3217-g4d6132e59327e809a4d4e3

  tree-optimization/110963 - more PRE when optimizing for size

The -O2 warning went away with r15-571-g1e0ae1f52741f7e013

  tree-optimization/79958 - make DSE track multiple paths

As noted, gcc-15 still warns at -O3

[Bug ada/119571] [15 Regression] ggc-none.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used w hen making a PIE object; recompile with -fPIE

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
Yes, little doubt here.

[Bug ada/119571] [15 Regression] ggc-none.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used w hen making a PIE object; recompile with -fPIE

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Fixing.

[Bug middle-end/119577] New: RISC-V: Redundant vector IV roundtrip.

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

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

Bug ID: 119577
   Summary: RISC-V: Redundant vector IV roundtrip.
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdapp at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

Given this function (basically vect-early-break_133_pfa1.c):

#define SZ 1020

char string[SZ];

__attribute__ ((noipa))
char * find(int n, char c)
{
for (int i = 1; i < n; i++) {
if (string[i] == c)
return &string[i];
}
return 0;
}

we generate the following gimple:

   [local count: 913217421]:
  # vect_vec_iv_.7_47 = PHI <_51(8), { 1, 2, 3, ... }(4)>
  # vectp_string.8_57 = PHI  [(void
*)&string + 1B](4)>
  # ivtmp_65 = PHI 
  _67 = .SELECT_VL (ivtmp_65, POLY_INT_CST [16, 16]);
  vect__1.10_60 = .MASK_LEN_LOAD (vectp_string.8_57, 8B, { -1, ... }, _59(D),
_67, 0);
  mask_patt_15.11_61 = _54 == vect__1.10_60;
  vec_len_mask_62 = .VCOND_MASK_LEN (mask_patt_15.11_61, { -1, ... }, { 0, ...
}, _67, 0);
  if (vec_len_mask_62 != { 0, ... })
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 97691432]:
  _53 = BIT_FIELD_REF ;
  goto ; [100.00%]

   [local count: 55807731]:
  _2 = (sizetype) i_35;
  _8 = &string + _2;
  goto ; [100.00%]

   [local count: 862990464]:
  _49 = (int) _67;
  _50 = [vec_duplicate_expr] _49;
  _51 = vect_vec_iv_.7_47 + _50;
  vectp_string.8_58 = vectp_string.8_57 + _67;
  ivtmp_66 = ivtmp_65 - _67;
  if (ivtmp_66 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]

In itself that's reasonable.  However, with the function returning string + i
we need the induction variable and obtain it via vectorizable_live_operation
from 
vect_vec_iv_.7_47.

That results in the following annotated assembly:

vid.v   v2# v2 = {0, 1, ...}
vadd.vi v2,v2,1   # v2 = {1, 2, ...}
.L4:
[..]
vadd.vv v2,v2,v3  # v2 += vector length in current iter.
beq a4,zero,.L8
.L5:
vsetvli a5,a4,e8,mf4,ta,ma  # a5 = vector length in current iter
[..]
vmv.v.x v3,a5  # broadcast vector length to vector
[..]
beq a5,zero,.L4 # latch
vmv.x.s a5,v2  # move last vector length to GPR.
.L3:
add a4,a7,a5 # use last vector length
j   .L7
.L7
[..] # read string[a4] and return.

I could somehow imagine that for aarch64, i.e. without length control we need
to
keep the vector length in a vector register but for riscv it seems pretty
pointless in this example.  On top we're paying the cost of broadcasting to
vector, adding vectors in every iteration, and, once, moving back to scalar
when all of it could be done "for free" on the scalar side.

What's a reasonable way to avoid this?  Can we special case the vector IV
generation when it's only used in a simple way like here?  The above example is
simple but we're also seeing related behavior for non early-break loops. 
Sometimes we even create a new vec_series in every iteration in order to just
add it to the number of iterations.  The vec_series being a VLA operation we
can't hoist it out of the loop.

[Bug target/119572] [15 Regression] Recent change triggers regression on RISC-V vector test

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

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

Robin Dapp  changed:

   What|Removed |Added

   Priority|P1  |P3

--- Comment #3 from Robin Dapp  ---
(In reply to ktkachov from comment #2)
> Sorry about that. I expect the effect of the patch is that now the
> vec_duplicate expander in autovec.md now gets used and if that produces
> incorrect code that causes trouble.

Yeah, 99.9% sure it's an issue in our backend in the vec_duplicateVxBI
expander.  I'm testing a patch.

[Bug middle-end/119576] Please remove -Warray-bounds from -Wall

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> The Linux kernel is some what a special case and somewhat should be using
> `--param min-pagesize=0` to avoid the warnings about low fixed addresses.

That is for the s390 issue. As for the other warnings nobody filed a bug report
for them so there is no to know what is going on. maybe an assume attribute or
`if (x) __builtin_unreachable ()` is needed to fix the warning/improve the code
gen. But who knows.

[Bug middle-end/119576] Please remove -Warray-bounds from -Wall

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Arthur O'Dwyer  ---
The Linux kernel disables -Warray-bounds in GCC 9 and later (and
-Wstringop-overflow unconditionally).
https://github.com/openSUSE/kernel/blame/5be5ecdaf1e7fb1a04e6122771b432851cd2393d/init/Kconfig#L905-L924

[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling

[ardb at kernel dot org via Gcc-bugs]

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

--- Comment #53 from Ard Biesheuvel  ---
(In reply to Alexander Monakov from comment #51)
> Michael, can you give your ack/nack for Ard's proposal in comment #24 (the
> second variant, I guess keying off -m[no-]direct-extern-access doesn't make
> sense here). I think it properly addresses what you said in comment #12,
> considering how the motivation for PLT avoidance seems lost to history.
> 
> (mcount doesn't follow the usual psABI, it must preserve all registers, but
> even considering that I still fail to see why it was necessary to avoid PLT
> for it)

Are there cases where a PLT might clobber any registers? I know this is the
case on AArch64 (x16 and x17 are intended for this) but I would expect that on
x86_64 the PLT logic would rely on memory operands instead.

And if so, does that happen under a condition we can test for? I.e, use a PLT
unless -fno-plt was passed, or the condition in question holds.

[Bug c++/116841] [14 Regression] spurious -Warray-bounds=1 warning when resizing + memcpy-ing into vector

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
It will be fixed for gcc-14 once I backport the fix for PR114945

[Bug fortran/119540] [15 Regression] FAIL: gfortran.dg/reduce_1.f90 -O0 execution test

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #60936|0   |1
is obsolete||

--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 60953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60953&action=edit
Extended patch for reduce.c

This patch additionally corrects the prototypes for the character versions,
as the type of character length is gfc_charlen_type, not index_type.

[Bug tree-optimization/111415] [12/13/14 Regression] False positive array-bounds warning with -O3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||11.5.0, 15.0
Summary|False positive array-bounds |[12/13/14 Regression] False
   |warning with -O3|positive array-bounds
   ||warning with -O3
  Known to fail||12.4.0, 13.3.0, 14.2.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-01

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk by r15-4473-g3abe751ea86e34

libstdc++: Refactor std::uninitialized_{copy,fill,fill_n} algos [PR68350]

[Bug tree-optimization/108860] [12/13/14 regression] New (since gcc 12) false positive null-dereference in vector.resize

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[12/13 regression] New  |[12/13/14 regression] New
   |(since gcc 12) false|(since gcc 12) false
   |positive null-dereference   |positive null-dereference
   |in vector.resize|in vector.resize
  Known to work|14.2.1  |
  Known to fail|13.2.1  |13.3.0, 14.2.0

--- Comment #7 from Jonathan Wakely  ---
Comment 0 still fails with gcc-14

Comment 3 was fixed by Honza's r14-5679-g1d82fc2e6824bf "optimize
std::vector::push_back"

[Bug middle-end/119576] Please remove -Warray-bounds from -Wall

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Arthur O'Dwyer  ---
Will Wray points out that GCC's own codebase disables `-Warray-bounds` in
several places, including at least these places in current master:

gcc/cp/module.cc:#pragma GCC diagnostic ignored "-Warray-bounds"
gcc/fortran/simplify.cc:  GCC_DIAGNOSTIC_PUSH_IGNORED
(-Warray-bounds)
gcc/fortran/simplify.cc:  GCC_DIAGNOSTIC_PUSH_IGNORED
(-Warray-bounds)
gcc/fortran/simplify.cc:  GCC_DIAGNOSTIC_PUSH_IGNORED
(-Warray-bounds)
libgcc/config/pa/fptr.c:#pragma GCC diagnostic ignored "-Warray-bounds"
libstdc++-v3/include/bits/char_traits.h:#pragma GCC diagnostic ignored
"-Warray-bounds"
libstdc++-v3/include/experimental/bits/simd_fixed_size.h:#pragma GCC diagnostic
ignored "-Warray-bounds"
libstdc++-v3/include/experimental/bits/simd_fixed_size.h:#pragma GCC diagnostic
ignored "-Warray-bounds"

For example, the first hit in "gcc/fortran/simplify.cc":

  if (n < result->rank)
{
  /* If the nested loop is unrolled GFC_MAX_DIMENSIONS
 times, we'd warn for the last iteration, because the
 array index will have already been incremented to the
 array sizes, and we can't tell that this must make
 the test against result->rank false, because ranks
 must not exceed GFC_MAX_DIMENSIONS.  */
  GCC_DIAGNOSTIC_PUSH_IGNORED (-Warray-bounds)
  count[n]++;
  base += sstride[n];
  dest += dstride[n];
  GCC_DIAGNOSTIC_POP
}

[Bug c++/116841] [14 Regression] spurious -Warray-bounds=1 warning when resizing + memcpy-ing into vector

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

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

--- Comment #3 from Jonathan Wakely  ---
Yes it was fixed by Honza's r15-5361-gaac5c57ee16723 

Add __builtion_unreachable to vector::size(), vector::capacity()

This patch makes it clear that vector sizes and capacities are not
negative.  With recent change to ipa-fnsummary this should not affect
inlining and improves codegen of some vector manipulation functions.

[Bug tree-optimization/114945] [14/15 regression] Sporadic std::vector::resize() -Wstringop-overflow or -Warray-bounds warning with gcc 14

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

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

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

https://gcc.gnu.org/g:844eed3364309bd20cbb7d6793a16b7c6b889ba4

commit r15-9134-g844eed3364309bd20cbb7d6793a16b7c6b889ba4
Author: Jonathan Wakely 
Date:   Mon Mar 31 12:30:44 2025 +0100

libstdc++: Fix -Warray-bounds warning in std::vector::resize [PR114945]

This is yet another false positive warning fix. This time the compiler
can't prove that when the vector has sufficient excess capacity to
append new elements, the pointer to the existing storage is not null.

libstdc++-v3/ChangeLog:

PR libstdc++/114945
* include/bits/vector.tcc (vector::_M_default_append): Add
unreachable condition so the compiler knows that _M_finish is
not null.
* testsuite/23_containers/vector/capacity/114945.cc: New test.

Reviewed-by: Tomasz KamiÅski 

[Bug middle-end/119576] Please remove -Warray-bounds from -Wall

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Arthur O'Dwyer from comment #6)
> Will Wray points out that GCC's own codebase disables `-Warray-bounds` in
> several places, including at least these places in current master:
> 
> gcc/cp/module.cc:#pragma GCC diagnostic ignored "-Warray-bounds"

r12-2178-g79d3378c7d7381 (PR 101372) looks to hack around maybe undefineness
that was not "fixed"


> gcc/fortran/simplify.cc:  GCC_DIAGNOSTIC_PUSH_IGNORED
> (-Warray-bounds)
> gcc/fortran/simplify.cc:  GCC_DIAGNOSTIC_PUSH_IGNORED
> (-Warray-bounds)
> gcc/fortran/simplify.cc:  GCC_DIAGNOSTIC_PUSH_IGNORED
> (-Warray-bounds)

r7-5713-ge1d070a4f7128f added it. So 8 years ago. This might already be fixed
too but nobody has tried to remove it.


> libgcc/config/pa/fptr.c:#pragma GCC diagnostic ignored "-Warray-bounds"

pa/fptr messes around with function pointers (because PA needs some special
handling for comparing function pointers). This is undefined for user to do.
This is one place where using this pragma and turning off warnings is correct
but users of GCC should get that warning.



> libstdc++-v3/include/bits/char_traits.h:#pragma GCC diagnostic ignored
> "-Warray-bounds"

Done by r12-5874-gf8463b0e3ec243 (I think the underlying issue was fixed but
the #pragma was never removed).


> libstdc++-v3/include/experimental/bits/simd_fixed_size.h:#pragma GCC
> diagnostic ignored "-Warray-bounds"
> libstdc++-v3/include/experimental/bits/simd_fixed_size.h:#pragma GCC
> diagnostic ignored "-Warray-bounds"


These are used when the input are undefined ... Or at least that is what the
comment says.

[Bug rtl-optimization/97286] simplified subreg used outside of the loop can cause conflict and cause an extra move inside the loop

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> simplified to remove intrsinics:
> ```
> typedef int v4si __attribute__((vector_size(4*sizeof(int;
> typedef float v4sf __attribute__((vector_size(4*sizeof(int;
> 
> void f(v4sf *a, v4sf *b, int l)
> {
>   v4si c = (v4si)*a;
>   for(int i = 0;i < l; i++)
>   {
> v4sf d = (v4sf)c;
> d+=b[i];
> c = (v4si)d;
>   }
>   *a = (v4sf)c;
> }
> ```

Richard, do you think this is something early-ra in aarch64 is well-placed to
address? Or is there perhaps a realistic IRA solution?