[Bug c++/119222] Conversion of inf to integer is not diagnosed

[gwen3293940943 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Gwen Fu  ---
Maybe the bug is related to the code below：
(in gcc/fold-const.cc :fold_binary_loc)
case RDIV_EXPR:
  /* Don't touch a floating-point divide by zero unless the mode
 of the constant can represent infinity.  */
  if (TREE_CODE (arg1) == REAL_CST
  && !MODE_HAS_INFINITIES (TYPE_MODE (TREE_TYPE (arg1)))
  && real_zerop (arg1))
return NULL_TREE;

  /* (-A) / (-B) -> A / B  */
  if (TREE_CODE (arg0) == NEGATE_EXPR && negate_expr_p (arg1))
return fold_build2_loc (loc, RDIV_EXPR, type,
TREE_OPERAND (arg0, 0),
negate_expr (arg1));
  if (TREE_CODE (arg1) == NEGATE_EXPR && negate_expr_p (arg0))
return fold_build2_loc (loc, RDIV_EXPR, type,
negate_expr (arg0),
TREE_OPERAND (arg1, 0));

These code uncovered that : There are two types of floating point numbers:
support infinity and do not support infinity.

And I tried to compile the testing code :
int foo() {
return 1/static_cast(0) ;
}

int main()
{
double a = 1/static_cast(0);
return 0 ; 
}
Howerver , there is no warning . 
SO is it feasible that these two situations can support infinity ?

[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs

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

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

--- Comment #16 from Sam James  ---
(In reply to Levi Zim from comment #15)

As long as the flag is passed correctly and applied to both the stage2 + stage3
builds, then the flag can't be to blame (just a trigger for it, rather than
some problem with the flag itself).

[Bug target/119286] [15 Regression] GCN vs. "middle-end: delay checking for alignment to load [PR118464]"

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

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

--- Comment #1 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #0)
> I found commit r15-7886-g2427793af1e545506e0315f8ec06adf73d76b3cc
> "middle-end: delay checking for alignment to load [PR118464]" responsible
> for a number of GCN target (tested '-march=gfx908') regressions (or new
> FAILs for the new test cases): [...]

..., and similarly -- but not identical! -- for '-march=gfx1100':

PASS: gcc.dg/vect/vect-early-break_128.c (test for excess errors)
PASS: gcc.dg/vect/vect-early-break_128.c scan-tree-dump vect "Loop contains
only SLP stmts"
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_128.c scan-tree-dump vect
"vectorizing stmts using SLP"

{+PASS: gcc.dg/vect/vect-early-break_133_pfa10.c (test for excess errors)+}
{+FAIL: gcc.dg/vect/vect-early-break_133_pfa10.c scan-tree-dump vect "LOOP
VECTORIZED"+}

{+PASS: gcc.dg/vect/vect-early-break_133_pfa11.c (test for excess errors)+}
{+FAIL: gcc.dg/vect/vect-early-break_133_pfa11.c scan-tree-dump vect "LOOP
VECTORIZED"+}

{+PASS: gcc.dg/vect/vect-early-break_133_pfa8.c (test for excess errors)+}
{+FAIL: gcc.dg/vect/vect-early-break_133_pfa8.c scan-tree-dump vect "LOOP
VECTORIZED"+}

{+PASS: gcc.dg/vect/vect-early-break_133_pfa9.c (test for excess errors)+}
{+FAIL: gcc.dg/vect/vect-early-break_133_pfa9.c scan-tree-dump vect "LOOP
VECTORIZED"+}
{+PASS: gcc.dg/vect/vect-early-break_133_pfa9.c scan-tree-dump-not vect
"Alignment of access forced using peeling"+}

PASS: gcc.dg/vect/vect-early-break_18.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_18.c
[-scan-tree-dump-]{+scan-tree-dump-not+} vect "LOOP VECTORIZED"

PASS: gcc.dg/vect/vect-early-break_38.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_38.c
[-scan-tree-dump-]{+scan-tree-dump-not+} vect "vectorized 1 loops in function"

PASS: gcc.dg/vect/vect-early-break_43.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_43.c scan-tree-dump vect
"vectorized 1 loops in function"

PASS: gcc.dg/vect/vect-early-break_44.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_44.c scan-tree-dump vect
"vectorized 1 loops in function"

PASS: gcc.dg/vect/vect-early-break_56.c (test for excess errors)
PASS: gcc.dg/vect/vect-early-break_56.c execution test
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_56.c scan-tree-dump-times
vect "vectorized 2 loops" 2

PASS: gcc.dg/vect/vect-early-break_6.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_6.c scan-tree-dump vect
"LOOP VECTORIZED"

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #8)
> Because as this PR shows, those 2->2 insn merges with no change on i2 can
> make a lot of sense and allow combination on the second and following user
> of i2 dest which current trunk just punts on.

No, they never make sense.  They are 1->1 insn changes.  This does not make
much
sense in the first place; where you want this it should be done in
target-specific
something, not from a generic decision.  And, of course, that is not something
the instruction combiner does.

I have often wondered if we should run simplify_rtx on every insn some time
before
combine.  Probably quite a bit before combine.  Really everything that creates
insns should run it on those before inserting the insns, but heh.

In this particular case the testcase is just broken, it is expecting some insns
to be generated that the testcase does not encourage the compiler to generate,
and they are in no way better than what the compiler *does* generate.  Unless
you
introduce some new cost function (but then tell the compiler about that, let it
use it as well !) :-)

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

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/119285] [15 Regression] 5% slowdown of 519.lbm_r on Zen2 and Zen4 since r15-7932-ge355fe414aa3aa

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/119159] [15 Regression] 6% slowdown of 520.omnetpp_r on aarch64

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/119291] New: wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 119291
   Summary: wrong code at -O{2,3} with "-fno-thread-jumps" on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a regression from 12.* and affects 13.* and later. 

Compiler Explorer: https://godbolt.org/z/saoqG5cvv


[510] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250314 (experimental) (GCC) 
[511] % 
[511] % gcctk -O3 small.c; ./a.out
[512] % gcctk -O3 -fno-thread-jumps small.c
[513] % timeout -s 9 5 ./a.out
Killed
[514] % 
[514] % cat small.c
int a, b, f;
long c;
volatile int d;
int main() {
  int e = 1;
 L:
  if (a < 2) {
b = e;
e = -(~c & (c & -(a && b)));
c = e || c;
a = ~e / ~b;
if (a) {
  d;
  goto L;
}
  }
}

[Bug libstdc++/111138] views::zip_transform is underconstrained for empty range pack

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

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

commit r15-8057-g5abe571e0276fafcc6eed27c27abb28943e67c6f
Author: Tomasz KamiÅski 
Date:   Fri Mar 7 11:54:38 2025 +0100

libstdc++: Fix views::zip_transform constraints for empty range pack
[PR38]

Add missing move_constructible && regular_invocable constrains on functor
type,
and is_object on functor result type for invocations of
views::zip_transform
without range arguments.

PR libstdc++/38

libstdc++-v3/ChangeLog:

* include/std/ranges (_ZipTransform::operator()):
Create separate overload for calls with empty range pack,
and add move_constructible, regular_invocable and
is_object_v>> constraints.
* testsuite/std/ranges/zip_transform/1.cc: New tests

Reviewed-by: Patrick Palka 
Jonathan Wakely 
Signed-off-by: Tomasz KamiÅski 

[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs

[rsworktech at outlook dot com via Gcc-bugs]

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

--- Comment #17 from Levi Zim  ---
(In reply to Sam James from comment #16)
> (In reply to Levi Zim from comment #15)
> 
> As long as the flag is passed correctly and applied to both the stage2 +
> stage3 builds, then the flag can't be to blame (just a trigger for it,
> rather than some problem with the flag itself).

It is passed through BOOT_CFLAGS so I suppose it is passed correctly.
I don't know why the comparison failure occur as I am not familiar with the GCC
internals. But building some of the commits yields a crash in RTL
pass(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012#c10). Would it be
related to the bisected commit?

[Bug cobol/119290] New: cobol testsuite should disable non-64-bit multilibs

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

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

Bug ID: 119290
   Summary: cobol testsuite should disable non-64-bit multilibs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

While testing current trunk on Linux/x86_64 with all multilibs, the 32-bit
cobol tests all FAIL like this:

FAIL: cobol.dg/error-1.cob   -O  (test for excess errors)
Excess errors:
: sorry, unimplemented: COBOL requires a 64-bit configuration

This creates quite some unnecessary noise, which is going to get worse over
time when more and more cobol tests are added.  Until this restriction is
(hopefully) lifted, non-64-bit multilib testing should be disabled instead.

[Bug cobol/119290] cobol testsuite should disable non-64-bit multilibs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Guess the cobol/dg.exp driver should call some tcl function to check if it is
supported at all and not run anything if it is not.
Something like e.g. asan.exp wraps all tests with
if [check_effective_target_fsanitize_address] {
or gomp.exp starts with
if ![check_effective_target_fopenmp] {
  return
}
etc.

[Bug cobol/119290] cobol testsuite should disable non-64-bit multilibs

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

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

--- Comment #3 from Jakub Jelinek  ---
Yes, compile a minimal cobol program (some one liner or what).
And perhaps look particularly for the sorry message as failure.

[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs

[rsworktech at outlook dot com via Gcc-bugs]

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

--- Comment #15 from Levi Zim  ---
(In reply to Sam James from comment #14)
> Thanks. Please try to reproduce it manually next.

If I didn't revert that commit, then bisection of the CFLAGS shows that
-Wp,-D_FORTIFY_SOURCE=3 is what causes the build to fail.
If I change that to -Wp,-D_FORTIFY_SOURCE=2, the bootstrap could succeed.

So now we have two bisections, one of the commits and one of the CFLAGS. I am
not sure which one should be blamed. Or if -Wp,-D_FORTIFY_SOURCE=3 uncovers
some issue in the bisected commit?

[Bug target/119270] [15 Regression] 5% slowdown of 507.cactuBSSN_r on Intel Ice Lake

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/119291] [13/14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
   Keywords||wrong-code
Summary|wrong code at -O{2,3} with  |[13/14/15 regression] wrong
   |"-fno-thread-jumps" on  |code at -O{2,3} with
   |x86_64-linux-gnu|"-fno-thread-jumps" on
   ||x86_64-linux-gnu

[Bug web/119227] Does the generated HTML for cobol get installed to the website?

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

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

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-03-14

--- Comment #5 from Mark Wielaard  ---
even with mandoc installed it still won't work. The log ends with:

groff: can't find `DESC' file
groff:fatal error: invalid device `pdf'

[Bug libstdc++/119289] Incorrect behavior of std::filesystem::copy() with none options and the destination link to non-existent file

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Libc++ behaves the same way.

Actually that's not true, libc++ resolves the symlink and copies the file to
that location. So it creates asdf, as you expected.

[Bug c++/119292] New: code deduplication in case of throw (improvement)

[federico at kircheis dot it via Gcc-bugs]

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

Bug ID: 119292
   Summary: code deduplication in case of throw (improvement)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico at kircheis dot it
  Target Milestone: ---

Consider following snippet


struct myclass{
myclass(int i);
};

#ifdef THROWIT
[[noreturn]] __attribute__((noinline)) void throwit(int i){
throw myclass(i);
}
#define THROW(p) throwit(p);
#else
#define THROW(p) throw myclass(p);
#endif


void foo(){
THROW(41);
}


void bar(int j){
THROW(j);
}



https://godbolt.org/z/ja1azahe4

When writing "throw" directly, "a lot" of code is generated in the body of bar
and foo which is identical, which in turn generate a bigger binary.

When wrapping the throw in a non-inline function, this duplication does not
happen, and since throwing is not cheap (__cxa_allocate_exception allocates),
the cost of having a non-inline function should be small.

Does GCC have any option (or chance) for avoiding to wrap all "throw" in
functions to reduce the size of the binary?

[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #11 from Jason Merrill  ---
(In reply to Patrick Palka from comment #10)
> Hmm, I'm not sure CWG 2568 makes this example well-formed?

Indeed not, so now there is CWG 3007.

[Bug tree-optimization/119293] New: [15 Regression] gcc.dg/vect/vect-121.c fails since r15-6811-g086031c0585985

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

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

Bug ID: 119293
   Summary: [15 Regression] gcc.dg/vect/vect-121.c fails since
r15-6811-g086031c0585985
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at gcc dot gnu.org
  Target Milestone: ---
Target: s390*-*-*, powerpc64le-*-*, x86_64-*-*

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

FAIL: gcc.dg/vect/vect-121.c scan-tree-dump-not optimized "Invalid sum"
FAIL: gcc.dg/vect/vect-121.c -flto -ffat-lto-objects  scan-tree-dump-not
optimized "Invalid sum"

Bisect stopped at r15-6811-g086031c0585985

Tests do not only fail for s390x [1] but also for powerpc64le [2] and x86_64
[3].

[1] https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840821.html
[2] https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840872.html
[3] https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840862.html

[Bug web/119227] Does the generated HTML for cobol get installed to the website?

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

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

--- Comment #6 from David Malcolm  ---
Thanks for the info Mark.

Sorry if this comes across as blunt, but pushing changes and waiting for a
cronjob to run (in production) seems very 1990s.

Is there some automated way to bring up a test instance of the server?

[Bug target/92713] ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa

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

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

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

https://gcc.gnu.org/g:1268924a2eed4e4f4cf1f43cc996b2f0eedeb07e

commit r15-8052-g1268924a2eed4e4f4cf1f43cc996b2f0eedeb07e
Author: Thomas Schwinge 
Date:   Thu Feb 20 16:31:50 2025 +0100

GCN, nvptx: Allow for "hosted" libstdc++ build

We need '-fno-exceptions', '-fno-rtti', disable generation of PCH files,
and
for nvptx twiddle some more knobs.

PR target/92713
PR target/101544
libstdc++-v3/
* config/cpu/nvptx/cpu_defines.h: New.
* config/cpu/nvptx/t-nvptx: Likewise.
* configure.host: Handle GCN, nvptx.

[Bug c++/119284] Overload resolution selects wrong overload with `std::invocable` concept and `auto &` in lambda parameter

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

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

--- Comment #3 from Jonathan Wakely  ---
N.B. the error didn't happen because the wrong overload was selection, it
happened while doing overload resolution to see if it _should_ be selected.

This problem is precisely why the monadic operations of std::optional in C++23
are *not* constrained. If we put std::invocable constraints on them, it would
cause exactly this error for generic lambdas.

[Bug cobol/119214] debug volatile asm breaks assembling

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Robert Dubner :

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

commit r15-8056-gb673d7b593f63a526a85d56204f1217bc4fbf6a1
Author: Robert Dubner 
Date:   Thu Mar 13 21:03:46 2025 -0400

Prevent use of ASM_EXPR for optimized COBOL compilations [PR119214]

The creation of assembler labels using ASM_EXPR causes name collisions in
the
assembly language because some optimizations repeat code, and those labels
can get repeated. Use of "if( !optimize )" prevents (at least) that problem
when
it cropped up with "-O -ftrace"

gcc/cobol:

PR cobol/119214
* gengen.cc: applies if( !optimize ) test

[Bug cobol/119214] debug volatile asm breaks assembling

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

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

--- Comment #18 from Robert Dubner  ---
(In reply to Jakub Jelinek from comment #17)
> Note,
> * gengen.cc: applies if( !optimize ) test
> is not properly formatted ChangeLog entry, unfortunately it got through
> pre-commit hooks.
> For next time, I think Richard provided what should have been written:
> * gengen.cc (gg_insert_into_assembler): Prevent use
> of ASM_EXPR for optimized cobol compilations.
> The
> This temporary fix will be replaced with a LABEL_DECL solution
> part doesn't explain what changed, but future intent, that shouldn't go into
> ChangeLog, but either commit message itself (outside of ChangeLog part), or
> say a comment in the source.

It's true: I hadn't registered that the function name is wanted in there.  I
suppose I tricked the hook with "( !optimize ).

I don't understand why the "The creation of assembler labels..." is going to
become part of the ChangeLog.  That text is above the line with the gcc/cobol:
designator.

[Bug libstdc++/119282] [15 Regression] views::transform producing ranges piped to views::join | ranges::to() fails to compile in constant evaluation.

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-03-14

--- Comment #3 from Patrick Palka  ---
The error message is bizarre, but it seems the fix it to just declare
_Clear::~_Clear constexpr in the body of that vector ctor

[Bug middle-end/115076] [OpenMP] "declare variant" scoping rules and visibility

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

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

--- Comment #3 from Tobias Burnus  ---
The testcase mentioned in PR 115271 comment 1, i.e., the existing (xfailed):

 libgomp/testsuite/libgomp.fortran/declare-variant-2.f90
 libgomp/testsuite/libgomp.fortran/declare-variant-2-aux.f90

is interesting as in the variant declaration is in the module - but the actual
base function is declared in the same file as the the module user, which is an
interesting scoping issue. - And belong rather here than to PR 115271.

[Bug tree-optimization/105616] Using regex_replace throws "maybe-uninitialized" warnings with -fsanitize=address

[donn.seeley at everfox dot com via Gcc-bugs]

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

Donn Seeley  changed:

   What|Removed |Added

 CC||donn.seeley at everfox dot com

--- Comment #6 from Donn Seeley  ---
I'm seeing this problem in GCC 14.2.1.  I'm trying to put together automated
ASAN testing for our product, and it's very annoying.  The problem isn't
exclusive to .

Here's my simple reproducer:

  #include 
  #include 

  std::regex re{"x"};

  std::string x2y(const std::string& s)
  {
  return std::regex_replace(s, re, "y");
  }

I build it with:

  g++ -std=gnu++17 -O2 -fsanitize=address -Werror -Wall -Wextra -c
regex_bug.cpp

It produces the same set of error messages as the OP.  I can include the full
blast of messages if anyone's interested.  The failure occurs with -O1 and
higher optimization levels, but not -O0.

After I found that the problem doesn't appear when building with -O0, I did
some bisection to identify the optimizations that trigger the problem.  I can
build the test program successfully with:

  g++ -std=gnu++17 -O1 -fsanitize=address -fno-tree-dominator-opts
-fno-tree-fre -Werror -Wall -Wextra -c regex_bug.cpp

or

  g++ -std=gnu++17 -O2 -fsanitize=address -fno-code-hoisting
-fno-tree-dominator-opts -fno-tree-fre -fno-tree-pre -Werror -Wall -Wextra -c
regex_bug.cpp

For now, I have added "#pragma GCC optimize (0)" directives for "#include
" in our source code.

[Bug ipa/116572] [14/15 Regression] Using a std::string passed to a virtual member function of a side-casted pointer spuriously ICEs (wrong code with checking disable)

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Jambor  ---
Richi's analyssi was basically spot on. I am going to commit the following fix:
https://inbox.sourceware.org/gcc-patches/ri634ffwtda@virgil.suse.cz/T/#u

[Bug target/119120] Unnecessary fldl/stpl pair when assigning real or imaginary part of a complex variable

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

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

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

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

commit r15-8059-gd0d7c6632c2913c0243f048a15ff64aec6b6232e
Author: Jakub Jelinek 
Date:   Fri Mar 14 15:31:47 2025 +0100

c, c++: Set DECL_NOT_GIMPLE_REG_P on *PART_EXPR operand on lhs of
MODIFY_EXPR [PR119120]

The PR119190 patch I've posted regresses the PR119120 testcase (not adding
to testsuite, as it is fairly hard to scan for that problem).
The issue is that for the partial setting of _Complex floating vars
through __real__ on it first and __imag__ later (or vice versa) and since
we forced all complex vars into SSA form we often have undefined (D)
arguments of those COMPLEX_EXPRs.  When we don't DCE them (for -O0 debug
info reasons), their expansion will copy both the real and imag parts
using the floating mode and on some targets like 387 that copying alone can
unfortunately trigger exceptions on sNaNs or other problematic bit patterns
and for uninitialized memory it can be triggered randomly based on whatever
is on the stack before.

The following patch sets DECL_NOT_GIMPLE_REG_P flag in the FEs during
genericization.
I think Fortran doesn't have a way to modify just real or just complex
part separately.

The patch is for code like
  _ComplexT __t;
  __real__ __t = __z.real();
  __imag__ __t = __z.imag();
  _M_value *= __t;
  return *this;
at -O0 which used to appear widely even in libstdc++ before GCC 9
and happens in real-world code.  At -O0 for debug info reasons (see
PR119190) we don't want to aggressively DCE statements and when we
since r0-100845 try to rewrite vars with COMPLEX_TYPE into SSA form
aggressively, the above results in copying of uninitialized data
when expanding COMPLEX_EXPRs added so that the vars can be in SSA form.
The patch detects during genericization the partial initialization and
doesn't rewrite such vars to SSA at -O0.  This has to be done before
gimplification starts, otherwise e.g. the attached testcase ICEs.

2025-03-14  Jakub Jelinek  

PR target/119120
* c-gimplify.cc (c_genericize_control_r): Set DECL_NOT_GIMPLE_REG_P
on {REAL,IMAG}PART_EXPR is_gimple_reg operand at -O0 if it is lhs
of a MODIFY_EXPR.

* cp-gimplify.cc (cp_genericize_r): Set DECL_NOT_GIMPLE_REG_P
on {REAL,IMAG}PART_EXPR is_gimple_reg operand at -O0 if it is lhs
of a MODIFY_EXPR.

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

[Bug tree-optimization/119291] [13/14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||roger at nextmovesoftware dot 
com
Summary|[13/14/15 regression] wrong |[13/14/15 regression] wrong
   |code at -O{2,3} with|code at -O{2,3} with
   |"-fno-thread-jumps" on  |"-fno-thread-jumps" on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r13-793-g8fb94fc6097c0a

--- Comment #2 from Sam James  ---
Started with r13-793-g8fb94fc6097c0a.

[Bug ipa/116572] [14/15 Regression] Using a std::string passed to a virtual member function of a side-casted pointer spuriously ICEs (wrong code with checking disable)

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:075ec330307c5b1fe5ed166a633c718c06b01437

commit r15-8061-g075ec330307c5b1fe5ed166a633c718c06b01437
Author: Martin Jambor 
Date:   Fri Mar 14 16:07:01 2025 +0100

ipa: Do not modify cgraph edges from thunk clones during inlining
(PR116572)

In PR 116572 we hit an assert that a thunk which does not have a body
looks like it has one.  It does not, but the call_stmt of its outgoing
edge points to a statement, which should not.  In fact it has several
outgoing call graph edges, which cannot be.  The problem is that the
code updating the edges to reflect inlining into the master clone (an
ex-thunk, unlike the clone, which is still an unexpanded thunk) is
being updated during inling into the master clone.  This patch simply
makes the code to skip unexpanded thunk clones.

gcc/ChangeLog:

2025-03-13  Martin Jambor  

PR ipa/116572
* cgraph.cc (cgraph_update_edges_for_call_stmt): Do not update
edges of clones that are unexpanded thunk.  Assert that the node
passed as the parameter is not an unexpanded thunk.

gcc/testsuite/ChangeLog:

2025-03-13  Martin Jambor  

PR ipa/116572
* g++.dg/ipa/pr116572.C: New test.

[Bug tree-optimization/119294] New: Strange (buggy?) codegen when passing cleared vector as argument

[gcc at haasn dot dev via Gcc-bugs]

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

Bug ID: 119294
   Summary: Strange (buggy?) codegen when passing cleared vector
as argument
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at haasn dot dev
  Target Milestone: ---

### Description

For some reason, in this program, GCC extraneously writes the vector argument,
normally passed in xmm0, to the stack - sometimes without even incrementing
the stack pointer.

It's furthermore strange that `set_indirect()` compiles to different code than
`set()`, even though the former (should) just directly inline the latter.

You can see that the problem goes away when the value to write is a compile
time constant, rather than taken from a register argument.

### Code

typedef char vec_t __attribute__((vector_size(16)));

void func(vec_t x);

void set(vec_t x, const char val)
{
for (int i = 0; i < 16; i++)
x[i] = val;

func(x);
}

void set_indirect(vec_t x, const char val)
{
set(x, val);
}

void setFF(vec_t x)
{
set(x, 0xFF);
}

void set123(vec_t x)
{
set(x, 123);
}

void set0(vec_t x)
{
set(x, 0);
}

### Expected Output

set:
vmovd   xmm0, edi
vpbroadcastbxmm0, xmm0
jmp func@PLT

set_indirect:
vmovd   xmm0, edi
vpbroadcastbxmm0, xmm0
jmp func@PLT

setFF:
vpcmpeqdxmm0, xmm0, xmm0
jmp func@PLT

.LCPI3_1:
.zero   4,123
set123:
vbroadcastssxmm0, dword ptr [rip + .LCPI3_1]
jmp func@PLT

set0:
vxorps  xmm0, xmm0, xmm0
jmp func@PLT

### Actual Output

set:
vmovd   xmm0, edi
sub rsp, 24
vpbroadcastbxmm0, xmm0
vmovdqa XMMWORD PTR [rsp], xmm0
callfunc
add rsp, 24
ret
set_indirect:
vmovd   xmm0, edi
vpbroadcastbxmm0, xmm0
vmovdqa XMMWORD PTR [rsp-24], xmm0
jmp func
setFF:
vpcmpeqdxmm0, xmm0, xmm0
jmp func
set123:
mov eax, 2071690107
vmovd   xmm0, eax
vpbroadcastdxmm0, xmm0
jmp func
set0:
vpxor   xmm0, xmm0, xmm0
jmp func

### See Also:

https://godbolt.org/z/1hrjKqf8Y

[Bug cobol/119296] cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-03-14
 Status|UNCONFIRMED |ASSIGNED

[Bug cobol/119296] New: cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC

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

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

Bug ID: 119296
   Summary: cobol, libgcobol the library uses strfromf* which are
C23 and not generally available outside GLIBC
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: iains at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

this is a build failure on platforms without support

(working on a work-around)

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #20 from Richard Sandiford  ---
(In reply to Richard Sandiford from comment #18)
> Still more than 0% of course, but nevertheless much less than before.
than before the fix for PR101523 went in, I mean.

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #22 from Segher Boessenkool  ---
(In reply to Richard Sandiford from comment #18)
> I'd been reluctant to get involved in this for fear of creating friction or
> being a cook too many,

No, your input is much appreciated!

> but: the problem in PR101523 was that, after each
> successful 2->2 attempt, distribute_links would search further and further
> for the new next combinable use of the i2 destination.

And the way it searches is linear in time, yeah.  Making that better will
require keeping some extra data structure up to date throughout combine, not
something that will likely be a great success.  Or do you see some other
possibility?

> So rather than
> adding a LUID-based limit to try_combine, how about just limiting the
> distribute_links to a certain number of instructions when i2 is unchanged?

That does not sound too bad.  Heck, even limiting it *always* could be done!

> The attached proof-of-concept hack does that using the upper limit of 1200
> that Jakub mentioned in comment 10.  It also includes a variant of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523#c53 .  I tried it on
> g:839bc42772ba7af66af3bd16efed4a69511312ae~ for the original testcase in
> PR101523 and it reduced combine to ~3% of compilation.  Still more than 0%
> of course, but nevertheless much less than before.

3% on a testcase that was meant to expose something closer to 100% isn't so
bad ;-)

> Does this seem like a plausible approach?  I'm going to be away for the next
> couple of weeks so wouldn't be able to take it further for a while.

Do you see time to still post the patch today?  If not, I'll pick it up.

Thanks!

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #19 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #16)
> Tamar's explanation why #c0 gcc 14 code is better than gcc 15:
> "the mov is a zero latency instruction. sxtw, asr and sbfx themselves are
> aliases to the same thing"

Target-specific, yes.  And the insn_cost of the mov isn't lower than that of
other insns :-(  (Or is it?  That part of the combine dump isn't here).

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #24 from Jakub Jelinek  ---
So, I've retried the #c10 testing with the #c18 patch modified to do
-int limit = i2_unchanged ? 1200 : INT_MAX;
+int limit = i2_unchanged ? (getenv ("COMBLIM") ? atoi (getenv ("COMBLIM"))
: 1200) : INT_MAX;

$ for i in 0 10 100 200 400 600 800 1000 1200 1; do echo COMBLIM=$i time
./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128 -march=z196
-fpreprocessed -w; COMBLIM=$i time ./cc1plus -quiet -nostdinc -O2 pr101523.ii
-mlong-double-128 -march=z196 -fpreprocessed -w; done
COMBLIM=0 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
13.60user 0.15system 0:13.80elapsed 99%CPU (0avgtext+0avgdata
320656maxresident)k
0inputs+776outputs (0major+106035minor)pagefaults 0swaps
COMBLIM=10 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
13.75user 0.13system 0:13.92elapsed 99%CPU (0avgtext+0avgdata
320776maxresident)k
0inputs+784outputs (0major+106049minor)pagefaults 0swaps
COMBLIM=100 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
14.38user 0.14system 0:14.58elapsed 99%CPU (0avgtext+0avgdata
323032maxresident)k
0inputs+808outputs (0major+106701minor)pagefaults 0swaps
COMBLIM=200 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
13.61user 0.13system 0:13.78elapsed 99%CPU (0avgtext+0avgdata
323060maxresident)k
0inputs+816outputs (0major+106960minor)pagefaults 0swaps
COMBLIM=400 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
13.66user 0.15system 0:13.88elapsed 99%CPU (0avgtext+0avgdata
323224maxresident)k
0inputs+816outputs (0major+106994minor)pagefaults 0swaps
COMBLIM=600 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
14.30user 0.13system 0:14.47elapsed 99%CPU (0avgtext+0avgdata
323208maxresident)k
0inputs+832outputs (0major+107229minor)pagefaults 0swaps
COMBLIM=800 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
13.51user 0.13system 0:13.71elapsed 99%CPU (0avgtext+0avgdata
322008maxresident)k
0inputs+832outputs (0major+107302minor)pagefaults 0swaps
COMBLIM=1000 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
14.04user 0.13system 0:14.22elapsed 99%CPU (0avgtext+0avgdata
318300maxresident)k
0inputs+840outputs (0major+106301minor)pagefaults 0swaps
COMBLIM=1200 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
13.87user 0.13system 0:14.06elapsed 99%CPU (0avgtext+0avgdata
315260maxresident)k
0inputs+824outputs (0major+106158minor)pagefaults 0swaps
COMBLIM=1 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
20.57user 0.15system 0:20.79elapsed 99%CPU (0avgtext+0avgdata
334344maxresident)k
0inputs+912outputs (0major+114533minor)pagefaults 0swaps
$ rm pr101523.ii.*; COMBLIM=0 ./cc1plus -quiet -nostdinc -O2 pr101523.ii
-mlong-double-128 -march=z196 -fpreprocessed -w -fdump-rtl-combine-stats; awk
'/^attempts:/{attempts+=$2}/^merges:/{merges+=$2}/^extras:/{extras+=$2}/^successes/{successes+=$2}/^two-insn
combine:/{two+=$3}/^three-insn combine:/{three+=$3}/^four-insn
combine:/{four+=$3}/^insn-with-note combine/{note+=$3}END{printf "attempts:
%d\nmerges: %d\nextras: %d\nsuccesses: %d\ntwo-insn combine: %d\nthree-insn
combine: %d\nfour-insn combine: %d\ninsn-with-note combine: %d\n", attempts,
merges, extras, successes, two, three, four, note}' pr101523.ii.*combine*
attempts: 22689
merges: 21761
extras: 5225
successes: 201
two-insn combine: 200
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
$ rm pr101523.ii.*; COMBLIM=10 ./cc1plus -quiet -nostdinc -O2 pr101523.ii
-mlong-double-128 -march=z196 -fpreprocessed -w -fdump-rtl-combine-stats; awk
'/^attempts:/{attempts+=$2}/^merges:/{merges+=$2}/^extras:/{extras+=$2}/^successes/{successes+=$2}/^two-insn
combine:/{two+=$3}/^three-insn combine:/{three+=$3}/^four-insn
combine:/{four+=$3}/^insn-with-note combine/{note+=$3}END{printf "attempts:
%d\nmerges: %d\nextras: %d\nsuccesses: %d\ntwo-insn combine: %d\nthree-insn
combine: %d\nfour-insn combine: %d\ninsn-with-note combine: %d\n", attempts,
merges, extras, successes, two, three, four, note}' pr101523.ii.*combine*
attempts: 22702
merges: 21774
extras: 5238
successes: 214
two-insn combine: 213
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
$ rm pr101523.ii.*; COMBLIM=100 ./cc1plus -quiet -nostdinc -O2 pr101523.ii
-mlong-double-128 -march=z196 -fpreprocessed -w -fdump-rtl-combine-stats; awk
'/^attempts:/{attempts+=$2}/^merges:/{merges+=$2}/^extras:/{extras+=$2}/^successes/{successes+=$2}/^two-insn
combine:/{two+=$3}/^three-insn combine:/{three+=$3}/^four-insn
combine:/{four+=$3}/^insn-with-note combine/{note+=$3}END{pr

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #23 from Richard Sandiford  ---
(In reply to Segher Boessenkool from comment #22)
> (In reply to Richard Sandiford from comment #18)
> > but: the problem in PR101523 was that, after each
> > successful 2->2 attempt, distribute_links would search further and further
> > for the new next combinable use of the i2 destination.
> 
> And the way it searches is linear in time, yeah.  Making that better will
> require keeping some extra data structure up to date throughout combine, not
> something that will likely be a great success.  Or do you see some other
> possibility?
Nah, I agree.  I don't see an easy way of doing that without using different
data structures (and possibly not even then).  One thing I used in "rtl-ssa"
(yeah, bit of a misleading name) was to combine a splay tree with a linked
list, so that each node belonged to both the tree and the list.  The splay tree
allows for sublinear random updates while the linked list means that in-order
traversal is still linear and neighbouring accesses are still constant-time.

> > So rather than
> > adding a LUID-based limit to try_combine, how about just limiting the
> > distribute_links to a certain number of instructions when i2 is unchanged?
> 
> That does not sound too bad.  Heck, even limiting it *always* could be done!
Yeah, I'd wondered about limiting it an all cases too.  Definitely seems worth
trying.  But given that we're in stage 4, maybe it would make sense to apply
the limit only to the "newly re-enabled" cases for GCC 15 and consider a
universal limit for GCC 16.

> > Does this seem like a plausible approach?  I'm going to be away for the next
> > couple of weeks so wouldn't be able to take it further for a while.
> 
> Do you see time to still post the patch today?
I'll be disappearing very soon, so don't have time to do a test run.

> If not, I'll pick it up.
Thanks, that'd be great.

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-03-14

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #25 from Jakub Jelinek  ---
And some further attempts in the 1500..5000 range:

$ for i in 1500 2000 2500 3000 3500 4000 5000; do echo COMBLIM=$i time
./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128 -march=z196
-fpreprocessed -w; COMBLIM=$i time ./cc1plus -quiet -nostdinc -O2 pr101523.ii
-mlong-double-128 -march=z196 -fpreprocessed -w; done
COMBLIM=1500 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
14.12user 0.15system 0:14.32elapsed 99%CPU (0avgtext+0avgdata
316544maxresident)k
0inputs+824outputs (0major+106337minor)pagefaults 0swaps
COMBLIM=2000 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
14.44user 0.12system 0:14.63elapsed 99%CPU (0avgtext+0avgdata
318616maxresident)k
0inputs+824outputs (0major+104871minor)pagefaults 0swaps
COMBLIM=2500 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
14.61user 0.13system 0:14.79elapsed 99%CPU (0avgtext+0avgdata
318880maxresident)k
0inputs+848outputs (0major+106934minor)pagefaults 0swaps
COMBLIM=3000 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
15.04user 0.15system 0:15.26elapsed 99%CPU (0avgtext+0avgdata
320672maxresident)k
0inputs+856outputs (0major+106836minor)pagefaults 0swaps
COMBLIM=3500 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
15.54user 0.13system 0:15.73elapsed 99%CPU (0avgtext+0avgdata
318856maxresident)k
0inputs+840outputs (0major+107193minor)pagefaults 0swaps
COMBLIM=4000 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
15.53user 0.12system 0:15.72elapsed 99%CPU (0avgtext+0avgdata
321640maxresident)k
0inputs+856outputs (0major+107824minor)pagefaults 0swaps
COMBLIM=5000 time ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w
17.20user 0.15system 0:17.41elapsed 99%CPU (0avgtext+0avgdata
306276maxresident)k
0inputs+872outputs (0major+107194minor)pagefaults 0swaps
$ for i in 1500 2000 2500 3000 3500 4000 5000; do rm pr101523.ii.*; echo
COMBLIM=$i ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats; COMBLIM=$i ./cc1plus
-quiet -nostdinc -O2 pr101523.ii -mlong-double-128 -march=z196 -fpreprocessed
-w -fdump-rtl-combine-stats; awk
'/^attempts:/{attempts+=$2}/^merges:/{merges+=$2}/^extras:/{extras+=$2}/^successes/{successes+=$2}/^two-insn
combine:/{two+=$3}/^three-insn combine:/{three+=$3}/^four-insn
combine:/{four+=$3}/^insn-with-note combine/{note+=$3}END{printf "attempts:
%d\nmerges: %d\nextras: %d\nsuccesses: %d\ntwo-insn combine: %d\nthree-insn
combine: %d\nfour-insn combine: %d\ninsn-with-note combine: %d\n", attempts,
merges, extras, successes, two, three, four, note}' pr101523.ii.*combine*; done
COMBLIM=1500 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 50696
merges: 49743
extras: 14793
successes: 4383
two-insn combine: 4382
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
COMBLIM=2000 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 59541
merges: 58588
extras: 17422
successes: 5229
two-insn combine: 5228
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
COMBLIM=2500 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 63403
merges: 62450
extras: 18572
successes: 5606
two-insn combine: 5605
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
COMBLIM=3000 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 63558
merges: 62605
extras: 18727
successes: 5762
two-insn combine: 5761
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
COMBLIM=3500 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 64203
merges: 63250
extras: 19372
successes: 6416
two-insn combine: 6415
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
COMBLIM=4000 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 70572
merges: 69616
extras: 21019
successes: 6745
two-insn combine: 6744
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0
COMBLIM=5000 ./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128
-march=z196 -fpreprocessed -w -fdump-rtl-combine-stats
attempts: 99213
merges: 98257
extras: 28052
successes: 7632
two-insn combine: 7631
three-insn combine: 1
four-insn combine: 0
insn-with-note combine: 0

So, I think even defaulting to say 3000 could work pretty we

[Bug tree-optimization/119293] [15 Regression] gcc.dg/vect/vect-121.c fails since r15-6811-g086031c0585985

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug rtl-optimization/119285] [15 Regression] 5% slowdown of 519.lbm_r on Zen2 and Zen4 since r15-7932-ge355fe414aa3aa

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

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

Sam James  changed:

   What|Removed |Added

   Priority|P2  |P1

--- Comment #2 from Sam James  ---
P1 until Vlad has a chance to investigate, given he's concerned about the code
size change?

[Bug tree-optimization/119299] Jump followed by jump not optimized.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
yes it is a dup of bug 47253.

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

[Bug middle-end/119291] [13/14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a

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

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

--- Comment #5 from Sam James  ---
(In reply to Andrew Pinski from comment #4)
> Created attachment 60756 [details]
> This should do exactly what that patch did
> 
> It looks like a different change caused this version too.

r13-673-gd863ba23fb1612

[Bug target/47253] Conditional jump to tail function is not generated

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

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

[Bug rtl-optimization/114518] [15 regression] gcc.target/powerpc/combine-2-2.c fails after r14-9692-g839bc42772ba7a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Does the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398#c18 patch fix
this?

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7

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

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

--- Comment #7 from Sam James  ---
This stopped failing for me around:

commit 2bc3ea210565dc7cdbba9adb31acceefed406254
Author: Sam James 
Date:   Fri Nov 22 15:20:45 2024 +

saving uncommitted changes in /etc prior to emerge run

diff --git a/x86_64-pc-linux-gnu/15/x86_64-pc-linux-gnu.xfail
b/x86_64-pc-linux-gnu/15/x86_64-pc-linux-gnu.xfail
index 90bc88f..a36c41d 100644
--- a/x86_64-pc-linux-gnu/15/x86_64-pc-linux-gnu.xfail
+++ b/x86_64-pc-linux-gnu/15/x86_64-pc-linux-gnu.xfail
@@ -576,13 +576,9 @@ Running gcc:/gcc/testsuite/gcc.dg/tsan/tsan.exp ...
 FAIL: c-c++-common/tsan/fd_pipe_race.c -O2  (test for excess errors)

 Running gcc:/gcc/testsuite/gcc.target/i386/i386.exp ...
-FAIL: gcc.target/i386/apx-ndd-tls-1a.c (test for excess errors)
-FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c scan-assembler-not
vfmadd[123]*ph[ \\t]
-FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c scan-assembler-times
vfmaddcph[ \\t] 1
 FAIL: gcc.target/i386/cet-sjlj-3.c scan-assembler-times call\t_?longjmp 1
 FAIL: gcc.target/i386/cet-sjlj-5.c scan-assembler-times call\t_?longjmp 1
 FAIL: gcc.target/i386/force-indirect-call-2.c scan-assembler-times
(?:call|jmp)[ \\t]+\\*% 3
-FAIL: gcc.target/i386/part-vect-complexhf.c scan-assembler-times vfmaddcph[
\\t] 1
 FAIL: gcc.target/i386/pr101716.c scan-assembler leal[\\t ][^\\n]*eax
 FAIL: gcc.target/i386/pr101716.c scan-assembler-not movl[\\t ][^\\n]*eax
 FAIL: gcc.target/i386/pr101950-2.c scan-assembler-times \txor[ql]\t 2

[Bug rtl-optimization/116028] [15 Regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593

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

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

--- Comment #18 from Sam James  ---
Is this failing still after r15-7400?

[Bug middle-end/119297] New: Dead local vector variable isn't removed

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

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

Bug ID: 119297
   Summary: Dead local vector variable isn't removed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-tgl-3 gcc]$ cat /tmp/y.c 
typedef char vec_t __attribute__((vector_size(16)));

extern void func1(vec_t);
extern void func2(char);

void
set1(char val)
{
  vec_t x;
  for (int i = 0; i < 16; i++)
x[i] = val;

  func1(x);
}

void
set2(char val)
{
  char x = val *2;

  func2(x);
}
[hjl@gnu-tgl-3 gcc]$ ./xgcc -B./ -S -O2 -march=x86-64-v3 /tmp/y.c
[hjl@gnu-tgl-3 gcc]$ cat y.s
.file   "y.c"
.text
.p2align 4
.globl  set1
.type   set1, @function
set1:
.LFB0:
.cfi_startproc
vmovd   %edi, %xmm0
vpbroadcastb%xmm0, %xmm0
vmovdqa %xmm0, -24(%rsp)  <<<<<<<< Dead local vector variable isn't
removed.
jmp func1
.cfi_endproc
.LFE0:
.size   set1, .-set1
.p2align 4
.globl  set2
.type   set2, @function
set2:
.LFB1:
.cfi_startproc
addl%edi, %edi
movsbl  %dil, %edi
jmp func2
.cfi_endproc
.LFE1:
.size   set2, .-set2
.ident  "GCC: (GNU) 15.0.1 20250314 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tgl-3 gcc]$

[Bug tree-optimization/87576] Warnings (array-bounds,stringop-overflow) emitted on branch never taken

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail|15.0|
  Known to work||15.0

--- Comment #7 from Andrew Pinski  ---
I still can't reproduce it on the trunk.

[Bug rtl-optimization/116028] [15 Regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593

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

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

--- Comment #19 from Andrew Pinski  ---
(In reply to Sam James from comment #18)
> Is this failing still after r15-7400?

Yes this one is still failing for aarch64:
FAIL: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing
shrink-wrapping"


https://gcc.gnu.org/pipermail/gcc-testresults/2025-March/840877.html

[Bug libstdc++/119029] [13/14/15 regression] abi_check FAILs on Solaris with gld

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14/15 regression]  |[13/14/15 regression]
   |abi_check FAILs on Solaris  |abi_check FAILs on Solaris
   |with gld|with gld

--- Comment #13 from Jakub Jelinek  ---
And that was also backported to 13.2 in
r13-7287-g9c9061e0418ded473672069aac43b25f6fd491b8

[Bug analyzer/119104] Regression in memcpy(3) if [[gnu::nonnull_if_nonzero]] is used instead of [[gnu::nonnull]]; unclear docs

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #7 from Alejandro Colomar  ---
alx@devuan:~/tmp$ cat nninz.c | grep -Tn ^
  1:#include 
  2:
  3:extern int  any;
  4:
  5:[[gnu::nonnull]]
  6:void f(void *);
  7:[[gnu::nonnull_if_nonzero(1, 2)]]
  8:void g(void *, int);
  9:
 10:int
 11:main(void)
 12:{
 13:int one = 1;
 14:int zero = 0;
 15:
 16:f(NULL);  // -Wnonnull
 17:g(NULL, 1);  // -Wnonnull
 18:g(NULL, 0);
 19:g(NULL, one);  // -Wnonnull -O1
 20:g(NULL, zero);
 21:g(NULL, any);
 22:}
alx@devuan:~/tmp$ gcc-15 -Wall -Wextra -O3 -S nninz.c 
nninz.c: In function ‘main’:
nninz.c:16:9: warning: argument 1 null where non-null expected [-Wnonnull]
   16 | f(NULL);  // -Wnonnull
  | ^
nninz.c:6:6: note: in a call to function ‘f’ declared ‘nonnull’
6 | void f(void *);
  |  ^
nninz.c:17:9: warning: argument 1 null where non-null expected because argument
2 is nonzero [-Wnonnull]
   17 | g(NULL, 1);  // -Wnonnull
  | ^
nninz.c:8:6: note: in a call to function ‘g’ declared ‘nonnull_if_nonzero’
8 | void g(void *, int);
  |  ^
nninz.c:19:9: warning: argument 1 null where non-null expected because argument
2 is nonzero [-Wnonnull]
   19 | g(NULL, one);  // -Wnonnull -O1
  | ^~~~
nninz.c:8:6: note: in a call to function ‘g’ declared ‘nonnull_if_nonzero’
8 | void g(void *, int);
  |  ^



Assuming that there's no agreement on wanting to diagnose line 21 under
-Wnonnull, could we add -Wnonnull-maybe-nonzero-size for diagnosing it?

[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld

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

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

--- Comment #11 from Sam James  ---
(In reply to Rainer Orth from comment #0)
> That already happened between 20240405
> (592536eb3c0a97a55b1019ff0216ef77e6ca847e) and 20240412
> (a76f236e084cbd02e4e3711cdfc3191dc7eeb460).
> 

The former commit is r14-9801-g592536eb3c0a97 in 14, so it can't be a P1 unless
some exceptional circumstance (and I don't think this is IMO).

[Bug libstdc++/119029] [14/15 regression] abi_check FAILs on Solaris with gld

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

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

Sam James  changed:

   What|Removed |Added

   Priority|P1  |P2
Summary|[15 regression] abi_check   |[14/15 regression]
   |FAILs on Solaris with gld   |abi_check FAILs on Solaris
   ||with gld

[Bug cobol/119214] debug volatile asm breaks assembling

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

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

--- Comment #20 from Robert Dubner  ---
(In reply to Richard Biener from comment #15)
> (In reply to Robert Dubner from comment #14)
> > (In reply to Richard Biener from comment #13)
> > > (In reply to Robert Dubner from comment #7)
> > > 
[...]
> There's no good way to create a NOP, but I don't understand why you'd need
> that.

Consider
0100  DISPLAY "this"
0101  para-1.
0102  DISPLAY "that"

I generate my NOP equivalent at the point of line 101, so that when NEXTing
through the code GDB stops at line 101, which otherwise generates no code to be
tagged with ".loc 1 101".

> 
> I'll also note that it's probably worth spending some time thinking about
> a better DWARF representation than labels and the way to communicate to
> gdb the desired information.  Changing to labels will be quite some work,
> esp. on the gdb side I'd guess, and the solution still feels a bit of a
> hack.  To me the way COBOL handles PERFORM and specifically the PERFORM
> "target" feels hacky as well, of course ;)

I wear the description "Your code is hacky" proudly.  Yes, it's hacky.  I can
see how, eventually, DWARF will be extended with the DW_AT tags, GCC will be
extended to handle them, and so will GDB.  Meanwhile, I hacked it into working.

And I am sheepishly willing to report that my ASM_EXPR hack puts the text
".proccallxx" into the symbol table and .debug_info section.  I now see that I
can use LABEL_DECL to, well, put that same text into the symbol table and
.debug_info section.  It's possible that making the switch will not require any
changes at all to the GDB-COBOL code.

[Bug cobol/119290] cobol testsuite should disable non-64-bit multilibs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Should be fixed now.

[Bug tree-optimization/119293] [15 Regression] gcc.dg/vect/vect-121.c fails since r15-6811-g086031c0585985

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
I suspect this is similar to PR 118407.

[Bug target/119300] New: ICE: in extract_insn, at recog.cc:2882 with -msoft-float -mfpmath=387 and __builtin_ia32_rsqrtf()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 119300
   Summary: ICE: in extract_insn, at recog.cc:2882 with
-msoft-float -mfpmath=387 and __builtin_ia32_rsqrtf()
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -msoft-float -mfpmath=387 testcase.c
testcase.c: In function 'foo':
testcase.c:5:1: error: unrecognizable insn:
5 | }
  | ^
(insn 8 7 9 2 (set (reg:SF 102)
(mult:SF (reg:SF 101)
(reg:SF 100))) "testcase.c":4:10 -1
 (nil))
during RTL pass: vregs
testcase.c:5:1: internal compiler error: in extract_insn, at recog.cc:2882
0x2ded0c1 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xefb729 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1722
0x86b117 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x86b194 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x859de5 extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2882
0x127869f instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1612
0x127869f instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1995
0x127869f execute
/repo/gcc-trunk/gcc/function.cc:2042
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.

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

[Bug tree-optimization/119299] Jump followed by jump not optimized.

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

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

--- Comment #3 from H.J. Lu  ---
(In reply to AK from comment #0)
...
> https://godbolt.org/z/3xh6Mxq4j

FYI,

https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/condjmp/gcc-16?ref_type=heads

generates:

.globl  g1
.type   g1, @function
g1:
.LFB0:
.cfi_startproc
movl%edi, %eax
orl $1, %eax
cmpl$5, %eax
je  f
cmpl$1, %edi
jbe f
ret
.cfi_endproc
.LFE0:
.size   g1, .-g1
.p2align 4
.globl  g2
.type   g2, @function
g2:
.LFB1:
.cfi_startproc
testl   $-6, %edi
je  f
ret
.cfi_endproc

[Bug target/119300] ICE: in extract_insn, at recog.cc:2882 with -msoft-float -mfpmath=387 and __builtin_ia32_rsqrtf()

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

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

--- Comment #1 from Andrew Pinski  ---
__builtin_ia32_rsqrtf most likely not be turned on for soft-float.

[Bug libstdc++/119029] [13/14/15 regression] abi_check FAILs on Solaris with gld

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|13.4

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

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

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

--- Comment #3 from Martin Jambor  ---
Created attachment 60759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60759&action=edit
Output of -fopt-info-vec in the slow case

Output of -fopt-info-vec in the slow case

[Bug tree-optimization/119287] New: [15 regression] ICE when building linux-6.12.19 (error: type mismatch in binary expression)

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

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

Bug ID: 119287
   Summary: [15 regression] ICE when building linux-6.12.19
(error: type mismatch in binary expression)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 60752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60752&action=edit
xhci-hub.i.xz

```
$ gcc -std=gnu17 -O2 -fno-strict-overflow -c xhci-hub.i
/var/tmp/portage/sys-kernel/gentoo-kernel-6.12.19/work/linux-6.12/drivers/usb/host/xhci-hub.c:
In function ‘xhci_hub_control’:
/var/tmp/portage/sys-kernel/gentoo-kernel-6.12.19/work/linux-6.12/drivers/usb/host/xhci-hub.c:1206:5:
error: type mismatch in binary expression
 1206 | int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
  | ^~~~
int

u32

int

_1609 = psi_626 & 48;
/var/tmp/portage/sys-kernel/gentoo-kernel-6.12.19/work/linux-6.12/drivers/usb/host/xhci-hub.c:1206:5:
error: type mismatch in binary expression
int

u32

int

_1610 = psi_626 & 48;
/var/tmp/portage/sys-kernel/gentoo-kernel-6.12.19/work/linux-6.12/drivers/usb/host/xhci-hub.c:1206:5:
error: type mismatch in binary expression
int

u32

int

_1611 = psi_626 & 48;
during GIMPLE pass: pre
/var/tmp/portage/sys-kernel/gentoo-kernel-6.12.19/work/linux-6.12/drivers/usb/host/xhci-hub.c:1206:5:
internal compiler error: verify_gimple failed
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
```

---

```

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage.notmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,cobol
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 15.0. p, commit
c80eba1e1f25987e05fb9724b199fdb464becb37' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config=bootstrap-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250314 (experimental)
81203220af87714fd0f3170a2043ab5d95353eef (Gentoo Hardened 15.0. p, commit
c80eba1e1f25987e05fb9724b199fdb464becb37)
```

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[chz0808 at gmail dot com via Gcc-bugs]

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

--- Comment #28 from Chen Chen  ---
I have seen that this regression was fixed on gcc15. Is there any plan to fix
it on gcc14 as well? Thanks. 

(In reply to chenglulu from comment #26)
> (In reply to Tianyang Chou from comment #24)
> > (In reply to Chen Chen from comment #0)
> > 
> > Sorry to talk about something unrelated to this bug. I tried running 548 on
> > CPU loongson 3A6000 with the same compiler version and compiler options as
> > you but the score is only 8.5,  so could you please tell me what am I
> > missing? I just can't reproduce your performance result.
> > 
> > The gcc compiler source code is downloaded from the github repo
> > AOSC-Tracking/gcc(13.2.0), configure it with parameters:
> > 
> > "--enable-shared --enable-threads=posix --with-system-zlib
> > --enable-gnu-indirect-function --enable-__cxa_atexit
> > --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
> > --disable-libssp --enable-gnu-unique-object --enable-linker-build-id
> > --enable-lto --enable-plugin --enable-install-libiberty --disable-multilib
> > --disable-werror --enable-pie --enable-checking=release
> > --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new
> > --enable-default-pie --enable-default-ssp --enable-bootstrap
> > --enable-languages=c,c++,fortran,lto --with-abi=lp64d
> > --with-arch=loongarch64 --with-tune=la664 
> > --build=loongarch64-aosc-linux-gnu"
> 
> Setting -mtune=la464 during compilation, I discovered that the score
> decreases with -mtune=la664.

[Bug cobol/119283] cobol FE uses memrchr unconditionally.

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Richard Biener from comment #1)
> I wonder if it could just use strrchr as fallback?

IDK if cobol strings are always null-terminated?

[Bug tree-optimization/119287] [15 regression] ICE when building linux-6.12.19 (error: type mismatch in binary expression)

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug libstdc++/119029] [14/15 regression] abi_check FAILs on Solaris with gld

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

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

--- Comment #12 from Jakub Jelinek  ---
I think it started with r14-321-g9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b

[Bug tree-optimization/119299] Jump followed by jump not optimized.

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

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

--- Comment #1 from Sam James  ---
H.J. may be working on this for 16 (if so, dupe).

[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268

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

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

--- Comment #26 from Segher Boessenkool  ---
(In reply to Richard Sandiford from comment #23)
> Yeah, I'd wondered about limiting it an all cases too.  Definitely seems
> worth trying.  But given that we're in stage 4, maybe it would make sense to
> apply the limit only to the "newly re-enabled" cases for GCC 15 and consider
> a universal limit for GCC 16.

Yup.  But it help to think about what we want to do within a year now, already,
too, even if we cannot *actually* do it completely yet.

> > > Does this seem like a plausible approach?  I'm going to be away for the 
> > > next
> > > couple of weeks so wouldn't be able to take it further for a while.
> > 
> > Do you see time to still post the patch today?
> I'll be disappearing very soon, so don't have time to do a test run.
> 
> > If not, I'll pick it up.
> Thanks, that'd be great.

So, the one thing I really worry about a bit: will everything still work if
we can lose some log_links in some (unusual) cases?  Or does anything rely on
that never happening.

So I've got some more reading to do :-)

[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-03-14

[Bug tree-optimization/119294] Strange (buggy?) codegen when passing cleared vector as argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-03-14
   Severity|normal  |enhancement
   Keywords||missed-optimization
  Component|target  |tree-optimization
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
  __builtin_memset (&x, _10, 16);


Is not converted into `(vector char){_10,_10,_10,...}`


Confirmed.

[Bug cobol/119295] New: cobol, libcobol uses random_r which is GLIBC specific

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

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

Bug ID: 119295
   Summary: cobol, libcobol uses random_r which is GLIBC specific
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: iains at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

This is a build failure on non-Linux platforms.

(working on a draft work-around)

[Bug tree-optimization/119294] Could improve vector formation when generated using a loop (vector char)

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Strange codegen when|Could improve vector
   |passing cleared vector as   |formation when generated
   |argument|using a loop (vector char)

--- Comment #2 from Andrew Pinski  ---
Fre is able to handle it for constants:
Value numbering stmt = __builtin_memset (&x, 255, 16);
Setting value number of .MEM_3 to .MEM_3 (changed)
Value numbering stmt = x.1_7 = x;
Setting value number of x.1_7 to { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1 } (changed)

[Bug rtl-optimization/119297] Dead local vector variable isn't removed

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |rtl-optimization
   Last reconfirmed||2025-03-14
 Ever confirmed|0   |1

[Bug middle-end/119291] [13/14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 60756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60756&action=edit
This should do exactly what that patch did

It looks like a different change caused this version too.

[Bug rtl-optimization/119297] Dead local vector variable isn't removed

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/119294] Could improve vector formation when generated using a loop (vector char)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug tree-optimization/119294] Could improve vector formation when generated using a loop (vector char)

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

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

--- Comment #3 from Andrew Pinski  ---
>It's furthermore strange that `set_indirect()` compiles to different code than 
>`set()`, even though the former (should) just directly inline the latter.


That is because in the set case the argument still has its address taken (due
to the memset) while in the set_indirect case it is a variable (that was
created with the copy of the argument).

Both issues will be fixed if the memset is converted into a vector constructor.

[Bug libstdc++/119282] [15 Regression] views::transform producing ranges piped to views::join | ranges::to() fails to compile in constant evaluation.

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

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

Patrick Palka  changed:

   What|Removed |Added

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

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

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

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

--- Comment #1 from Martin Jambor  ---
Created attachment 60757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60757&action=edit
Perf annotate of the slow case

Perf annotate of the slow case

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

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

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

--- Comment #2 from Martin Jambor  ---
Created attachment 60758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60758&action=edit
Perf annotate of the fast case

Perf annotate of the fast case

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

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

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

--- Comment #4 from Martin Jambor  ---
Created attachment 60760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60760&action=edit
Output of -fopt-info-vec in the fast case

Output of -fopt-info-vec in the fast case

[Bug target/119298] New: 538.imagick_r is faster when compiled with GCC 14.2 and -Ofast -flto -march=native than with master on Zen5

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

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

Bug ID: 119298
   Summary: 538.imagick_r is faster when compiled with GCC 14.2
and -Ofast -flto -march=native than with master on
Zen5
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

SPEC INTrate 2017 538.imagick_r benchmark is faster when compiled with
GCC 14.2 and -Ofast -flto -march=native than with trunk/master on Zen
5 CPUs.

The regression has been introduced in r15-3441-g4292297a0f938f (Jan
Hubicka: Zen5 tuning part 5: update instruction latencies in
x86-tune-costs)

It is the modification of "cost of ADDSS/SD SUBSS/SD insns" that is
the culprit, bumping it back to COSTS_N_INSNS(3) (instead of
COSTS_N_INSNS(2)) makes the regression go away.  Nevertheless, Honza
claims the cost should be correct.


Perf stat of the slow run:

 116866.57 msec task-clock:u #1.000 CPUs
utilized
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
  8347  page-faults:u#   71.423 /sec
  484499860679  cycles:u #4.146 GHz
   21879349058  stalled-cycles-frontend:u#4.52% frontend
cycles idle
 2030074730877  instructions:u   #4.19  insn per
cycle
  #0.01  stalled cycles per
insn
  224436542157  branches:u   #1.920 G/sec
1716173329  branch-misses:u  #0.76% of all
branches

 116.881252465 seconds time elapsed

 116.808499000 seconds user
   0.05735 seconds sys

Perf report of the slow run (annotated assmebly attached):

  # Samples: 470K of event 'cycles:Pu'
  # Event count (approx.): 484158470552
  #
  # Overhead   Samples  Command  Shared Object   
Symbol
  #     ...  ... 
.
  #
  44.71%210348  imagick_r_peak.  imagick_r_peak.mine-lto-nat-m64 
[.] MeanShiftImage
  28.76%135308  imagick_r_peak.  imagick_r_peak.mine-lto-nat-m64 
[.] GetVirtualPixelsFromNexus
  25.50%120106  imagick_r_peak.  imagick_r_peak.mine-lto-nat-m64 
[.] MorphologyApply





Perf stat of the fast run (with just the one cost reverted):

 Performance counter stats for 'taskset -c 0 specinvoke':

 108805.48 msec task-clock:u #1.000 CPUs
utilized
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
  8312  page-faults:u#   76.393 /sec
  450981792793  cycles:u #4.145 GHz
   22610930072  stalled-cycles-frontend:u#5.01% frontend
cycles idle
 1933965750890  instructions:u   #4.29  insn per
cycle
  #0.01  stalled cycles per
insn
  224433996552  branches:u   #2.063 G/sec
1721069495  branch-misses:u  #0.77% of all
branches

 108.819368844 seconds time elapsed

 108.763582000 seconds user
   0.041314000 seconds sys

Perf report of the fast run (annotated assmebly attached):

# Samples: 427K of event 'cycles:Pu'
# Event count (approx.): 439380128661
#
# Overhead   Samples  Command  Shared Object   
Symbol
#     ...  ... 
..
#
44.53%190164  imagick_r_peak.  imagick_r_peak.mine-lto-nat-m64  [.]
MeanShiftImage
28.13%120243  imagick_r_peak.  imagick_r_peak.mine-lto-nat-m64  [.]
MorphologyApply
26.20%111906  imagick_r_peak.  imagick_r_peak.mine-lto-nat-m64  [.]
GetVirtualPixelsFromNexus


Referenced Bugs:

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

[Bug tree-optimization/119294] Could improve vector formation when generated using a loop (vector char)

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

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

--- Comment #5 from H.J. Lu  ---
CSE turns

(insn 18 16 19 2 (set (mem/c:V16QI (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0])) [0 MEM 
[(void *)&x]+0 S16 A128])
(subreg:V16QI (reg:V4SI 111) 0)) "x.c":11:10 2397 {movv16qi_internal}
 (nil))
(insn 19 18 20 2 (set (reg:V16QI 112 [ x ])
(mem/c:V16QI (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0])) [0 x+0 S16 A128]))
"x.c":13:3 2397 {movv16qi_internal}
 (nil))
(insn 20 19 21 2 (set (reg:V16QI 20 xmm0)
(reg:V16QI 112 [ x ])) "x.c":13:3 2397 {movv16qi_internal}
 (expr_list:REG_DEAD (reg:V16QI 112 [ x ])
(nil)))

into

(insn 1 15 18 2 (set (reg:V4SI 111)
(vec_select:V4SI (subreg:V4SI (reg:V8HI 110) 0)
(parallel [
(const_int 0 [0]) repeated x4
]))) "x.c":11:10 8445 {sse2_pshufd_1}
 (expr_list:REG_DEAD (reg:V8HI 110)
(nil)))
(insn 18 16 20 2 (set (mem/c:V16QI (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0])) [0 MEM 
[(void *)&x]+0 S16 A128])
(subreg:V16QI (reg:V4SI 111) 0)) "x.c":11:10 2397 {movv16qi_internal}
 (expr_list:REG_DEAD (reg:V4SI 111)
(nil)))
(insn 20 18 21 2 (set (reg:V16QI 20 xmm0)
(subreg:V16QI (reg:V4SI 111) 0)) "x.c":13:3 2397 {movv16qi_internal}
 (expr_list:REG_DEAD (reg:V16QI 112 [ x ])
(nil)))

But the unused store isn't removed.

[Bug middle-end/119291] [13/14/15 regression] wrong code at -O{2,3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a

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

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

--- Comment #3 from Andrew Pinski  ---
Works on aarch64 and the gimple level loops the same between x86_64 and
aarch64.

I suspect this is either a target issue or a rtl optimization issue.

[Bug cobol/119290] cobol testsuite should disable non-64-bit multilibs

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

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

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

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

commit r15-8062-gb2de4b0926bddbb97b991dd95592c714ee519e1e
Author: Jakub Jelinek 
Date:   Fri Mar 14 20:32:43 2025 +0100

cobol: Don't run cobol tests with -m32 or -mx32 [PR119290]

The following patch adds cobol effective target and uses it to guard main
loop in cobol.dg/dg.exp, so that we don't run the tests on unsupported
multilibs.

Tested on x86_64-linux with
make check-cobol RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp'
which previously had all FAILs in the -m32 case and now doesn't report
any PASSes/FAILs/XFAILs/XPASSes etc, while for -m64 the testsuite is run
normally.

2025-03-14  Jakub Jelinek  

PR cobol/119290
* lib/target-supports.exp (check_compile): Use *.cob extension for
"*> COBOL" comment.
* lib/cobol-dg.exp (check_effective_target_cobol): New procedure.
* cobol.dg/dg.exp: Guard main loop with
[check_effective_target_cobol]
test.

[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #4 from Jakub Jelinek  ---
> > Does it have in that case the desired effect?  I mean, does Solaris dynamic
> > linker complain with that
> > __extension__ __asm (".globl _ZSt21ios_base_library_initv");
> > if one tries to run a program against older libstdc++.so.6?
> 
> I'll try that later tonight.
> 
> > Depending on that, we should be either using _GLIBCXX_SYMVER_SUN in both 
> > spots,
> > or just the second one.
> 
> I'll start trying the first variant (both spots) then.
> 
> However, please note I'll be on vacation starting tomorrow until the end
> of next week, thus unlikely to respond further in that timeframe.

Any progress on this?

[Bug libstdc++/119282] [15 Regression] views::transform producing ranges piped to views::join | ranges::to() fails to compile in constant evaluation.

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-8063-g2f03a8d7be9775312c50abdc99109aaf8641bda3
Author: Patrick Palka 
Date:   Fri Mar 14 16:10:35 2025 -0400

libstdc++: Missing 'constexpr' in vector's from_range ctor [PR119282]

A missing 'constexpr' in the non-forward (and non-sized) branch of our
recently implemented vector from_range ctor was causing this valid example
to be rejected with a cryptic error.

PR libstdc++/119282

libstdc++-v3/ChangeLog:

* include/bits/stl_vector.h (vector::vector(from_range_t)): Add
missing 'constexpr' to local class _Clear.
* testsuite/std/ranges/conv/1.cc (test_pr119282): New test.

Reviewed-by: Jonathan Wakely 

[Bug tree-optimization/79637] documentation for --param max-fsm-thread-length is confusing

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
max-fsm-thread-length was removed with r13-1999-gc64ef5cd92c2e3.

fsm-maximum-phi-arguments, max-fsm-thread-length, and max-fsm-thread-paths were
removed with r12-4421-g0bd68793921ecf.

Only max-fsm-thread-path-insns is left:

-param=max-fsm-thread-path-insns=
Common Joined UInteger Var(param_max_fsm_thread_path_insns) Init(100)
IntegerRange(1, 99) Param Optimization
Maximum number of instructions to copy when duplicating blocks on a finite
state automaton jump thread path.

Which seems decent to me.

So closing as fixed.

[Bug tree-optimization/79637] documentation for --param max-fsm-thread-length is confusing

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/87576] Warnings (array-bounds,stringop-overflow) emitted on branch never taken

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #8 from Sam James  ---
11 fails, 12 works now, 13 fails, 14 fails, trunk works now. But it's a library
change (using gcc 12 preprocessed source on trunk fails).

[Bug libstdc++/119282] [15 Regression] views::transform producing ranges piped to views::join | ranges::to() fails to compile in constant evaluation.

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed, thanks for the bug report

[Bug tree-optimization/87576] Warnings (array-bounds,stringop-overflow) emitted on branch never taken

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

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

--- Comment #9 from Sam James  ---
Created attachment 60762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60762&action=edit
a.ii.xz (gcc 12)

g++ a.ii -o a -O3 -g -DDEBUG -D_DEBUG  -Wno-array-bounds -Wall -Wextra
-pedantic -Wno-unused-parameter -Werror -std=c++17

[Bug tree-optimization/119299] New: Jump followed by jump not optimized.

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 119299
   Summary: Jump followed by jump not optimized.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

Testcase

```
void g2(T x) {
T y = x & ~1;
if (y == 0 || y == 4) f(x);
}
```


clang -O3
```
g2(unsigned int):
testedi, -6
je  f(unsigned int)@PLT
ret
```

gcc -O3
```
g2(unsigned int):
testedi, -6
je  .L8
ret
.L8:
jmp f(unsigned int)
```

https://godbolt.org/z/3xh6Mxq4j

[Bug middle-end/119279] Specifying frame pointer dependency in inline asm

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

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

--- Comment #3 from Richard Biener  ---
I think

asm ("" : : "g" (__builtin_frame_address_(0)))

and using that input as frame pointer looks spot-on semantically, is that
what you are actually using or are you then using %rbp anyway in the
assembler text?

We should make sure to not elide the frame if there's such a use then
and possibly document this as the way to get a frame and at the frame
pointer in inline asm context.

[Bug libstdc++/119282] New: Views

[email at miropalmu dot cc via Gcc-bugs]

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

Bug ID: 119282
   Summary: Views
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: email at miropalmu dot cc
  Target Milestone: ---