[Bug target/117688] [15 Regression] RISC-V: Wrong code for .SAT_SUB

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:81aa9488321dea5ed1d55d0dfb1a72f362a1a24f

commit r15-7266-g81aa9488321dea5ed1d55d0dfb1a72f362a1a24f
Author: Pan Li 
Date:   Thu Jan 23 12:08:17 2025 +0800

RISC-V: Fix incorrect code gen for scalar signed SAT_ADD [PR117688]

This patch would like to fix the wroing code generation for the scalar
signed SAT_ADD.  The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode.  Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure we have the correct value before ALU like add.  The gen_lowpart
will generate something like lbu which has all zero for highest bits.

For example, when 0xff(-1 for QImode) plus 0x2(1 for QImode), we actually
want to -1 + 2 = 1, but if there is no sign extend like lbu, we will get
0xff + 2 = 0x101 which is incorrect.  Thus, we have to sign extend
0xff(Qmode)
to 0x(assume XImode is DImode) before plus in Xmode.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

PR target/117688

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_expand_ssadd): Leverage the helper
riscv_extend_to_xmode_reg with SIGN_EXTEND.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr117688-add-run-1-s16.c: New test.
* gcc.target/riscv/pr117688-add-run-1-s32.c: New test.
* gcc.target/riscv/pr117688-add-run-1-s64.c: New test.
* gcc.target/riscv/pr117688-add-run-1-s8.c: New test.
* gcc.target/riscv/pr117688.h: New test.

Signed-off-by: Pan Li 

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

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

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

--- Comment #20 from Richard Biener  ---
For the time being you could go the ext-dce workaround I added in
r15-6793-g03faac50791380 and disable the pass when computing the DF problems
will
likely go out of hands.

I agree that avoiding whole function DF when it's not actually needed would
be good.  RTL-SSA might be OK, but I suspect it has similar worse-cases
when operating on a whole function.  I suppose building it more locally
might be possible as well (I think a "local" DF would be possible, too,
but it requires some engineering here).

[Bug target/117688] [15 Regression] RISC-V: Wrong code for .SAT_SUB

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r15-7268-g5a48079c15fda4863b02eb253e473c57a5105528
Author: Pan Li 
Date:   Thu Jan 23 14:28:39 2025 +0800

RISC-V: Fix incorrect code gen for scalar signed SAT_TRUNC [PR117688]

This patch would like to fix the wroing code generation for the scalar
signed SAT_TRUNC.  The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode.  Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure we have the correct value before ALU like add.  The gen_lowpart
will generate something like lbu which has all zero for highest bits.

For example, when 0xff7f(-129 for HImode) trunc to QImode, we actually
want compare -129 to -128, but if there is no sign extend like lbu, we will
compare 0xff7f to 0xff80(assum Xmode is DImode).  Thus, we have
to sign extend 0xff(Qmode) to 0xff7f(assume Xmode is DImode)
before compare in Xmode.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

PR target/117688

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_expand_sstrunc): Leverage the helper
riscv_extend_to_xmode_reg with SIGN_EXTEND.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr117688.h: Add test helper macros.
* gcc.target/riscv/pr117688-trunc-run-1-s16-to-s8.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s32-to-s16.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s32-to-s8.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s64-to-s16.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s64-to-s32.c: New test.
* gcc.target/riscv/pr117688-trunc-run-1-s64-to-s8.c: New test.

Signed-off-by: Pan Li 

[Bug target/117688] [15 Regression] RISC-V: Wrong code for .SAT_SUB

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r15-7267-gbfb57d62c743235284f9b31a88c6ceed9971d27a
Author: Pan Li 
Date:   Thu Jan 23 12:14:43 2025 +0800

RISC-V: Fix incorrect code gen for scalar signed SAT_SUB [PR117688]

This patch would like to fix the wroing code generation for the scalar
signed SAT_SUB.  The input can be QI/HI/SI/DI while the alu like sub
can only work on Xmode.  Unfortunately we don't have sub/add for
non-Xmode like QImode in scalar, thus we need to sign extend to Xmode
to ensure we have the correct value before ALU like sub.  The gen_lowpart
will generate something like lbu which has all zero for highest bits.

For example, when 0xff(-1 for QImode) sub 0x1(1 for QImode), we actually
want to -1 - 1 = -2, but if there is no sign extend like lbu, we will get
0xff - 1 = 0xfe which is incorrect.  Thus, we have to sign extend
0xff(Qmode)
to 0x(assume XImode is DImode) before sub in Xmode.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

PR target/117688

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_expand_sssub): Leverage the helper
riscv_extend_to_xmode_reg with SIGN_EXTEND.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr117688.h: Add test helper macro.
* gcc.target/riscv/pr117688-sub-run-1-s16.c: New test.
* gcc.target/riscv/pr117688-sub-run-1-s32.c: New test.
* gcc.target/riscv/pr117688-sub-run-1-s64.c: New test.
* gcc.target/riscv/pr117688-sub-run-1-s8.c: New test.

Signed-off-by: Pan Li 

[Bug libstdc++/108053] std::visit_format_arg should hide __int128 and other extensions behind a handle

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

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

--- Comment #2 from Jonathan Wakely  ---
Libc++ fixed an equivalent issue with
https://github.com/llvm/llvm-project/commit/e948cab07d68c240723a12cdc151d09c5cef87ba

[Bug c++/118673] [14 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

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

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

--- Comment #17 from Sam James  ---
Thanks for the quick fix Jason. The MLIR testsuite now passes too.

[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines

[Yash.Shinde at windriver dot com via Gcc-bugs]

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

Yash Shinde  changed:

   What|Removed |Added

 CC||Yash.Shinde at windriver dot 
com

--- Comment #15 from Yash Shinde  ---
Hi,

I discussed with Jeremy and sent a V2 for review.
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674340.html

[Bug target/109093] [15 regression] csmith: a February runtime bug ?

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|13.4|15.0
   Last reconfirmed|2023-03-13 00:00:00 |2025-1-29
Summary|csmith: a February runtime  |[15 regression] csmith: a
   |bug ?   |February runtime bug ?

[Bug target/118125] [15 Regression] 7-16% slowdown of 510.parest_r on x86-64(-v3) since r15-6110-g92e0e0f8177530

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

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

--- Comment #9 from Martin Jambor  ---
Passing -fdisable-tree-rebuild_frequencies1 to the LTO linking step
brings back the original performance.

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

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

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

--- Comment #21 from Richard Sandiford  ---
I should have said, but: another reason for suggesting rtl-ssa is that it is
usually self-updating.  My long-term hope is that we'll be able to maintain it
between passes, when we have consecutive passes that both use it.  That isn't
useful at the moment, because of the sparse usage, but it would become more
useful if more passes use the framework.

So in the long term, converting to rtl-ssa would mean that we might not need to
build the whole IR for this pass individually.  In contrast, doing local DF
means that we would be committing to doing extra work for this pass in
particular.

[Bug c++/118673] [14 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #16 from Iain Sandoe  ---
(In reply to Jason Merrill from comment #15)
> Fixed on trunk by r15-7259-gd0f230adf0e888

This regresses obj-c++ with NeXT runtime
the previous (CONST_DECL) case contains...


  /* CONST_DECL without TREE_STATIC are enumeration values and
 thus not lvalues.  With TREE_STATIC they are used by ObjC++
 in objc_build_string_object and need to be considered as
 lvalues.  */

the CONST_DECL case then falls through into the processing for VAR_DECL, and
then tries to DECL_MERGEABLE - which ICEs because it's not a VAR.



perhaps:

diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index fb6b2b18e94..fba026d2efb 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -213,7 +213,8 @@ lvalue_kind (const_tree ref)
  && DECL_IN_AGGR_P (ref))
return clk_none;

-  if (DECL_MERGEABLE (ref))
+  if ((TREE_CODE (ref) == CONST_DECL && TREE_STATIC (ref))
+ || DECL_MERGEABLE (ref))
return clk_ordinary | clk_mergeable;

   /* FALLTHRU */




(imo) It would be useful to allow more use of CONST_DECL this way where we have
code like contracts that generates a lot of const objects - doing it manually
with read-only vars and invented local names is less obvious.  I think Richi
also has a long-term objective to use it in some way to optimise strings.

[Bug libgcc/118685] FreeBSD static executables segfault due to libgcc missing crtbeginT.o

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org,
   ||gerald at pfeifer dot com
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2025-January
   ||/674663.html

--- Comment #3 from Eric Gallager  ---
(In reply to kargls from comment #2)
> I can confirm that Dimitry's patch fixes gcc 15.0 (aka top-of-tree).
> 
> This is likely going to need a global maintainer to approval the patch.
> I'm not sure if there is an active FreeBSD maintainer, so will need
> someone to commit the patch as well.

Gerald Pfeifer sometimes commits FreeBSD-related patches; maybe he could do so
here as well?

[Bug middle-end/118692] [15 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3350 with out-of-bounds string ops

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Last reconfirmed||2025-01-29
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We expand

vect__6.6_4 = MEM  [(double *)&c + 8143523003042804629B];

again via the

11809   exp = build3 (BIT_FIELD_REF, type, base, TYPE_SIZE (type),
11810 bitsize_int (offset * BITS_PER_UNIT));
11811   REF_REVERSE_STORAGE_ORDER (exp) = reverse;
11812   return expand_expr (exp, target, tmode, modifier);

fallback.  The issue is offset * 8 is "negative", more to the point,
it overflows poly_uint64.  It should in reality use poly_offset_int
and the assert in bit_field_offset is problematic.  Similar issues
would exist for TYPE_SIZE.

Changing bit_field_{offset,size} to return poly_offset_int is probably
the correct thing to do?

Note I do not like the above BIT_FIELD_REF fallback much, the other
fallback is stack.  I'm not sure if we invoke this fallback for
EXPAND_WRITE for example ... (but why not).

The trivial fix for the regression part is to avoid the use of
bit_field_{offset,size} in tree_could_trap_p/bit_field_ref_in_bounds_p.

I'm going to do that now.

[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276) since r15-6551

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Sandiford  ---
Mine

[Bug middle-end/118691] [15 Regression] gcc_r in SPECCPU 2017 miscompare with PGO + LTO

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

--- Comment #1 from Richard Biener  ---
Please add -fno-strict-aliasing and try again.

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

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Sandiford  ---
Mine

[Bug target/109093] [15 regression] csmith: a February runtime bug ?

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

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

--- Comment #32 from Jakub Jelinek  ---
with that f = 1 I get
./cc1.r14-4971 -quiet -O2 -march=znver1 -ftrivial-auto-var-init=zero
-fno-stack-protector pr109093.c; gcc -o pr109093{,.s}; ./pr109093
./cc1.r14-4972 -quiet -O2 -march=znver1 -ftrivial-auto-var-init=zero
-fno-stack-protector pr109093.c; gcc -o pr109093{,.s}; ./pr109093
Segmentation fault (core dumped)
from bisection.
That was a RA change.

[Bug middle-end/118691] [15 Regression] gcc_r in SPECCPU 2017 miscompare with PGO + LTO

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

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

--- Comment #2 from Tamar Christina  ---
(In reply to Richard Biener from comment #1)
> Please add -fno-strict-aliasing and try again.

Already on.  Full options are:

-fprofile-generate -mcpu=neoverse-v1 -Ofast -fomit-frame-pointer -flto=auto -g3
-fno-strict-aliasing -fgnu89-inline -std=gnu17

[Bug c++/118693] New: istream& getline (istream& is, string& str, char delim) does not return with long input

[alban_sf--- via Gcc-bugs]

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

Bug ID: 118693
   Summary: istream& getline (istream&  is, string& str, char
delim) does not return with long input
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alban...@baker-research.com
  Target Milestone: ---

Created attachment 60314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60314&action=edit
Test program, .s, .ii files, compiler command and output, sample ouptut.

Hi,

In c++, the function

  istream& getline (istream&  is, string& str, char delim)

doesn't return when"

  1) delim is '>', and

  2) The input to stream "is" consists of 'A' repeated 4926 times followed by
'>'.

In this case, the size of str is usually around 4096 instead of the expected
value of 4926.

However, getline() does return if either:

  1) The input consists of 'A' repeated 2000 times followed by '>'.  In this
case, the size of str is 2000, as expected.

  2) The input consists of 'A' repeated 4926 followed by ">\n>".  In this case,
the size of str is usually around 4096 instead of the expected value of 4926.

I've attached testDecludeFilter.tar.gz that contains:

  1) The test program testGetline.cpp.  Run the test by running testGetline,
and providing the input by cutting the specified number of 'A' characters from
a file, and pasting.

  2) Compiler command.

  3) Compiler output.

  4) .s and .ii files.

  5) Input and output with 4926 'A' characters.

For me a satisfactory solution would be to change the documentation of
getline() to state that the input must not exceed a value before the delim
character.  However, that might not satisfy everyone.

Thanks,
Alban

[Bug middle-end/118692] [15 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3350 with out-of-bounds string ops

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-checking|

--- Comment #2 from Richard Biener  ---
Oh, and

#define bitsize_int(L) size_int_kind (L, stk_bitsizetype)
extern tree size_int_kind (poly_int64, enum size_type_kind);

so bitsize_int truncates as well.  The following fixes the ICE
but generates wrong code (the * 8 / 8 truncates/sign-extends).
The wrong-code is very old - before poly-int size_int_kind had
a HOST_WIDE_INT argument.

foo:
.LFB0:
.cfi_startproc
movabsq $-1079849033811971180, %rax
movupd  -8(%rsp,%rax), %xmm0
addpd   cf(%rip), %xmm0
movaps  %xmm0, cf(%rip)
ret


diff --git a/gcc/tree-eh.cc b/gcc/tree-eh.cc
index 7015189a2de..128744eebdd 100644
--- a/gcc/tree-eh.cc
+++ b/gcc/tree-eh.cc
@@ -2652,16 +2652,14 @@ range_in_array_bounds_p (tree ref)
 static bool
 bit_field_ref_in_bounds_p (tree expr)
 {
-  tree size_tree;
-  poly_uint64 size_max, min, wid, max;
-
-  size_tree = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (expr, 0)));
-  if (!size_tree || !poly_int_tree_p (size_tree, &size_max))
+  tree size_tree = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (expr, 0)));
+  if (!size_tree || !poly_int_tree_p (size_tree))
 return false;

-  min = bit_field_offset (expr);
-  wid = bit_field_size (expr);
-  max = min + wid;
+  poly_offset_int size_max = wi::to_poly_offset (size_tree);
+  poly_offset_int min = wi::to_poly_offset (TREE_OPERAND (expr, 2));
+  poly_offset_int wid = wi::to_poly_offset (TREE_OPERAND (expr, 1));
+  poly_offset_int max = min + wid;
   if (maybe_lt (max, min)
   || maybe_lt (size_max, max))
 return false;

[Bug c++/118673] [14 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

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

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

--- Comment #18 from Jason Merrill  ---
(In reply to Iain Sandoe from comment #16)
> +  if ((TREE_CODE (ref) == CONST_DECL && TREE_STATIC (ref))
> + || DECL_MERGEABLE (ref))

LGTM.

[Bug c++/118673] [14 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

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

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

--- Comment #19 from Jason Merrill  ---
(In reply to Jason Merrill from comment #18)
> (In reply to Iain Sandoe from comment #16)
> > +  if ((TREE_CODE (ref) == CONST_DECL && TREE_STATIC (ref))
> > + || DECL_MERGEABLE (ref))
> 
> LGTM.

Except we don't need to check TREE_STATIC because we already returned for
CONST_DECL without TREE_STATIC.

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

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

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

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

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

commit r14-11259-gf0420cc224db64efe87cbe2f45d4d7ba8deb9eb0
Author: Patrick Palka 
Date:   Wed Jan 29 10:02:28 2025 -0500

libstdc++: Fix views::transform(move_only_fn{}) forwarding [PR118413]

The range adaptor perfect forwarding simplification mechanism is currently
only enabled for trivially copyable bound arguments, to prevent undesirable
copies of complex objects.  But "trivially copyable" is the wrong property
to check for here, since a move-only type with a trivial move constructor
is considered trivially copyable, and after P2492R2 we can't assume copy
constructibility of the bound arguments.  This patch makes the mechanism
more specifically check for trivial copy constructibility instead so
that it's properly disabled for move-only bound arguments.

PR libstdc++/118413

libstdc++-v3/ChangeLog:

* include/std/ranges (views::__adaptor::_Partial): Adjust
constraints on the "simple" partial specializations to require
is_trivially_copy_constructible_v instead of
is_trivially_copyable_v.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc (test04):
Extend P2494R2 test.
* testsuite/std/ranges/adaptors/transform.cc (test09): Likewise.

Reviewed-by: Jonathan Wakely 
(cherry picked from commit 09d1cbee10b8c51aed48f047f30717f622d6f811)

[Bug libstdc++/118413] Move only function makes `std::views::transform` not working correctly

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Fixed for 14.3 / 15, thanks for the bug report.

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

[bonzini at gnu dot org via Gcc-bugs]

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

--- Comment #22 from Paolo Bonzini  ---
Yes, I suggested the MD problem because it did solve gambit performance issues
with fwprop for good, but RTL-SSA is certainly applicable.

Also, once all RD uses are converted to RTL-SSA it should really be removed
from df.c as a bad idea (and probably also MD since it's unused *sheds a
tear*).

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

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

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

--- Comment #23 from Richard Sandiford  ---
FWIW, running locally on x86 with fold_mem_offsets disabled (admittedly with
rtl checking), I see:

 combiner   :   0.91 (  0%)21M (  0%)
 late combiner  :   1.31 (  0%)  1329k (  0%)

and:

 forward prop   :   1.41 (  0%)  1028k (  0%)

This includes two late-combine runs (one before and one after RA) and two
fwprop runs.

So the time and memory overhead seem reasonable for this particular testcase. 
That obviously doesn't mean that it's free of scaling problems elsewhere, of
course.

[Bug rtl-optimization/117506] [15 Regression] ICE: in decompose, at wide-int.h:1049 with -O3 -funroll-loops

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So, we have a loop with
(insn 3 72 4 5 (set (reg:DI 159 [ ivtmp_86 ])
(const_int 0 [0])) "pr117506.c":7:7 277 {*movdi_64bit}
 (nil))
before the loop and
(insn 84 80 86 6 (set (reg:DI 159 [ ivtmp_86 ])
(sign_extend:DI (plus:SI (subreg/s/u:SI (reg:DI 159 [ ivtmp_86 ]) 0)
(reg:SI 216 "pr117506.c":6:23 discrim 1 8 {addsi3_extended}
 (expr_list:REG_DEAD (reg:SI 216)
(expr_list:REG_EQUAL (sign_extend:DI (plus:SI (subreg/s/u:SI (reg:DI
159 [ ivtmp_86 ]) 0)
(const_poly_int:SI [8, 8])))
(nil
inside of the loop.
The BIV analysis uses DImode as outermode, that is fine, but then
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 added some loop-iv.cc RISCV
specific hacks.
Now, because (const_poly_int:SI [8, 8]) is a CONSTANT_P but doesn't have
VOIDmode, that obviously causes ICE on the simplify_gen_binary.
Guess one possibility would be to
--- gcc/loop-iv.cc.jj   2025-01-02 11:23:04.479684906 +0100
+++ gcc/loop-iv.cc  2025-01-29 11:55:57.723511186 +0100
@@ -711,7 +711,7 @@ get_biv_step_1 (df_ref def, scalar_int_m
  if (CONSTANT_P (op0))
std::swap (op0, op1);

- if (!simple_reg_p (op0) || !CONSTANT_P (op1))
+ if (!simple_reg_p (op0) || !CONST_INT_P (op1))
return false;

  prev_code = code;
Another would be to make sure op1 is SIGN/ZERO_EXTENDED before we actually use
it later in the simplify_gen_binary:
--- gcc/loop-iv.cc.jj   2025-01-02 11:23:04.479684906 +0100
+++ gcc/loop-iv.cc  2025-01-29 12:01:08.899294623 +0100
@@ -714,6 +714,7 @@ get_biv_step_1 (df_ref def, scalar_int_m
  if (!simple_reg_p (op0) || !CONSTANT_P (op1))
return false;

+ op1 = simplify_gen_unary (code, outer_mode, op1, GET_MODE (rhs));
  prev_code = code;
  code = PLUS;
}
Both fix the ICE on this testcase but otherwise completely untested.
But, I have no way to test this on RISC-V, so deferring to Jeff as the commit
author.

[Bug tree-optimization/118689] New: [15 regression] Abort compiling m2pim_NumberIO_BinToStr

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

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

Bug ID: 118689
   Summary: [15 regression] Abort compiling
m2pim_NumberIO_BinToStr
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: gaius at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

Between 20250126 (55d288d4ff5360c572f2a017ba9385840ac5134e) and 20250127
(6a510dea7f3b047d0650a48e558a4911973930eb),
Solaris/SPARC gm2 bootstrap broke: in stage 3, compilation of
gcc/m2/gm2-libs/NumberIO.mod
fails with

/var/gcc/regression/master/11.4-gcc/build/./gcc/gm2
-B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -c -g -O2 -g -O2
-fm2-pathname=m2pim -I. -I/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs
-fm2-pathname=m2iso -I/vol/gcc/src/hg/master/local/gcc/m2/gm2-libs-iso -fm2-g
-g -Wcase-enum -Wreturn-type -fcase -fm2-prefix=m2pim
/vol/gcc/src/hg/master/local/libgm2/libm2pim/../../gcc/m2/gm2-libs/NumberIO.mod
 -fPIC -DPIC -o .libs/NumberIO.o

terminate called after throwing an instance of 'unsigned int' 
during GIMPLE pass: evrp
In function ‘m2pim_NumberIO_BinToStr’:
cc1gm2: internal compiler error: Abort
0x1feb43b internal_error(char const*, ...)
/vol/gcc/src/hg/master/local/gcc/diagnostic-global-context.cc:517
0xfd2c13 crash_signal
/vol/gcc/src/hg/master/local/gcc/toplev.cc:322

A reghunt identified

commit 92a5c5100c25190622ca86b63586a598952546bf
Author: Jakub Jelinek 
Date:   Mon Jan 27 10:22:28 2025 +0100

match.pd: Canonicalize unsigned division by power of two into right shift
[PR118637]

as the culprit.

[Bug tree-optimization/117892] [15 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/118689] [15 regression] Abort compiling m2pim_NumberIO_BinToStr

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/117892] [15 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5

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

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

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

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

commit r15-7269-g3d07e7bf13d4aec794dd25b5090c139b4d78283d
Author: Martin Jambor 
Date:   Wed Jan 29 10:51:08 2025 +0100

tree-ssa-dce: Avoid creating invalid BBs with no outgoing edge (PR117892)

Zhendong Su and Michal Jireš found out that our gimple DSE pass can,
under fairly specific conditions, remove a noreturn call which then
leaves behind a "normal" BB with no successor edges which following
passes do not expect.  This patch simply tells the pass to leave such
calls alone even when they otherwise appear to be dead.

Interestingly, our CFG verifier does not report this.  I'll put on my
todo list to add a test for it in the next stage 1.

gcc/ChangeLog:

2025-01-28  Martin Jambor  

PR tree-optimization/117892
* tree-ssa-dse.cc (dse_optimize_call): Leave control-altering
noreturn calls alone.

gcc/testsuite/ChangeLog:

2025-01-27  Martin Jambor  

PR tree-optimization/117892
* gcc.dg/tree-ssa/pr117892.c: New test.
* gcc.dg/tree-ssa/pr118517.c: Likewise.

co-authored-by: Michal Jireš 

[Bug d/118477] Race condition in 'd' Make-lang.in

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

--- Comment #5 from Rainer Orth  ---
It would be good to fix this one way or another: D bootstrap is broken on many
targets due to this for more than two weeks already, and keeping either of the
proposed patches local is tedious.

[Bug c++/86769] g++ destroys condition variable in for statement too early

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/81233] -Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/79164] -Wduplicated-branches and macros

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/79959] -Wimplicit-fallthrough doesn't recognize some more complex exit cases

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/90309] Spurious warning shift-negative-value

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug d/118495] Unable to build gdc (D compiler) for MinGW-w64

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #15 from Brecht Sanders  ---
So what is needed to be able to use gdc to build a simple "Hello world" program
for Windows (x86_64-w64-mingw32)?

[Bug sanitizer/78208] Compile-time hog with -fsanitize=null with operator overloading

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

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

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

--- Comment #19 from Richard Sandiford  ---
Mind if I take this and try converting it to rtl-ssa?  I think that would be
more forward-looking, rather than adding more custom (dominator walk) code to
the pass itself.  Also, the switch to rtl-ssa did seem to make fwprop.c faster:
see https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558922.html for
details.

[Bug tree-optimization/114052] [12/13/14/15 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245

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

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

--- Comment #14 from Richard Biener  ---
I have an alternate patch fixing maybe_lower_iteration_bound, I think that's
the only place we have to fix.

[Bug middle-end/118684] wrong alignment for stack temporary created during RTL expansion

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

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

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

https://gcc.gnu.org/g:7b02b8f65ef60be77f3f93945e2a6b463edaa0aa

commit r15-7264-g7b02b8f65ef60be77f3f93945e2a6b463edaa0aa
Author: Richard Biener 
Date:   Wed Jan 29 08:58:39 2025 +0100

middle-end/118684 - fix fallout of wrong stack local alignment fix

When we expand BIT_FIELD_REF  we can end up creating
a stack local, running into the fix.  But get_object_alignment
will return 8 for any SSA_NAME because that's not an "object" we
handle.  Deal with handled components on registers by singling out
SSA_NAME bases, using their type alignment instead of
get_object_alignment (I considered "robustifying" get_object_alignment,
but decided not to at this point).

This fixes an ICE on gcc.dg/pr41123.c on arm as reported by the CI.

PR middle-end/118684
* expr.cc (expand_expr_real_1): When creating a stack local
during expansion of a handled component, when the base is
a SSA_NAME use its type alignment and avoid calling
get_object_alignment.

* gcc.dg/pr118684.c: Require automatic_stack_alignment.

[Bug tree-optimization/112458] SLP permute optimization issue

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
This was fixed with r15-773-g3507ab1b018a68

[Bug middle-end/110972] [14/15 Regression] 13% fatigue regression with r14-3078-gd9f3ea61fe36e2

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|13% fatigue regression with |[14/15 Regression] 13%
   |r14-3078-gd9f3ea61fe36e2|fatigue regression with
   ||r14-3078-gd9f3ea61fe36e2
   Target Milestone|--- |14.3

--- Comment #5 from Richard Biener  ---
On the zen3 graph there are now two bigger regressions and one progression
visible.

Still needs analysis.

[Bug rtl-optimization/116073] [15 regression] invalid rtl sharing compiling compiling FileSystem.mod caused by ext-dce

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Gaius Mulley  ---
> Created attachment 60298
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60298&action=edit
> Proposed fix for 32 bit
>
> Apologies for the breakage.  Here is a proposed fix which changes the default
> size of COFF_T to the same as CSSIZE_T.  Bootstrapped successfully on x86_64,
> x86_32, aarch64 and ppc64le gnu/linux (and no regression failures).

I've now tried it on both i386-pc-solaris2.11 and sparc-sun-solaris2.11
(both 32 and 64-bit multilibs): all the failures are gone.

Thanks.

[Bug middle-end/118692] [15 Regression] ICE: in tree_to_poly_uint64, at tree.cc:3350 with out-of-bounds string ops

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

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

--- Comment #3 from Richard Biener  ---

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 7f3149b85ee..10467f82c0d 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -11806,6 +11806,14 @@ expand_expr_real_1 (tree exp, rtx target, machine_mode
tmode,
  set_mem_size (temp, int_size_in_bytes (type));
return temp;
  }
+   /* When the access is fully outside of the underlying object
+  expand the offset as zero.  This avoids out-of-bound
+  BIT_FIELD_REFs and generates smaller code for these cases
+  with UB.  */
+   type_size = tree_to_poly_uint64 (TYPE_SIZE_UNIT (type));
+   if (!ranges_maybe_overlap_p (offset, type_size, 0,
+GET_MODE_SIZE (DECL_MODE (base
+ offset = 0;
exp = build3 (BIT_FIELD_REF, type, base, TYPE_SIZE (type),
  bitsize_int (offset * BITS_PER_UNIT));
REF_REVERSE_STORAGE_ORDER (exp) = reverse;

also works.

[Bug c++/55203] No unused warning for variables of non-trivial types

[ing.russomauro at gmail dot com via Gcc-bugs]

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

mauro russo  changed:

   What|Removed |Added

 CC||ing.russomauro at gmail dot com

--- Comment #25 from mauro russo  ---
Hello,

I was going to post a new potential bug (for gcc 14.2) and then found two
exist: PR 60212 and this one, too.

I will paste here below my intended message with the error description, but
note that in my description a missing warning happens also for trivial type
when the value-initialization is used.
I wasn't sure whether to post this message here or in PR 60212.




I found the case while studying differences about user-provided and
non-user-provided explicitly-defaulted default constructors.


In the following code:

struct X{
X() = default;
// int m;
};

//X::X() = default;

int main()
{
X x;

return 0;
}

gcc raises a warning about unused variable x,


but in the following other code (https://godbolt.org/z/36WKzbvP6)

struct X{
X(); // = default;
// int m;
};

X::X() = default;

int main()
{
X x;

return 0;
}

no warning is issued.


Well, in second case, the explictly-defaulted default constructor is
user-provided, which also leads it not to be trivial (and, consequently, the
type neither).
However, in both cases, no initialization of any base or non-static data member
is done, and nothing changes also if a data member "int m;" is added (with no
default member initializer).

I cannot figure out what motivation may lead to a different behaviour.

In particular, if the opposite behaviour would have happened, I could have
supposed the error to be related to the vacuous-initialization when
non-user-provided (first case).

Additionally, note that if 'x' is value-initialized ("X x{};"), then the
warning disappears in both cases (trivial or non-trivial), regardless of adding
or not an "int m;" data member, where the only theoretical difference (beyond
the 'trivial' and consequent 'vacuous-initialization') is that no
zero-initialization is performed as first step of the value-initialization (see
https://eel.is/c++draft/dcl.init.general#9.1), before the
default-initialization (that does nothing).

[Bug target/118125] [15 Regression] 7-16% slowdown of 510.parest_r on x86-64(-v3) since r15-6110-g92e0e0f8177530

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

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

--- Comment #8 from Martin Jambor  ---
I guess I should have started with looking at annotated assembly. The
hot loop in the hot functions changes from:

53 : ,-> 5534e0: lea(%r11,%rax,1),%rsi
   659 : |   5534e4: mov(%rsi),%edi
   485 : |   5534e6: mov0x4(%rsi),%r8d
  2173 : |   5534ea: vmovsd (%rcx,%rdi,8),%xmm0
  1032 : |   5534ef: mov0x8(%rsi),%edi
  1673 : |   5534f2: mov0xc(%rsi),%esi
   550 : |   5534f5: vmovhpd (%rcx,%r8,8),%xmm0,%xmm0
 24357 : |   5534fb: vmovsd (%rcx,%rdi,8),%xmm2
   900 : |   553500: vmovhpd (%rcx,%rsi,8),%xmm2,%xmm2
   : |s += *val_ptr++ * src(*colnum_ptr++);
  2198 : |   553505: vmulpd 0x10(%rdx,%rax,2),%xmm2,%xmm2
 10806 : |   55350b: vfmadd132pd (%rdx,%rax,2),%xmm2,%xmm0
 19463 : |   553511: add$0x10,%rax
   158 : |   553515: vaddpd %xmm0,%xmm1,%xmm1
   : |while (val_ptr != val_end_of_row)
 65079 : |   553519: cmp-0x538(%rbp),%rax
   689 : '-- 553520: jne5534e0 

to:

 7 : ,-> 5535a0: lea(%rdi,%r10,1),%rdx
   : |return val[i];
   408 : |   5535a4: mov%rdx,-0x500(%rbp)
  2231 : |   5535ab: mov(%rdx),%edx
   420 : |   5535ad: mov%rdx,-0x538(%rbp)
59 : |   5535b4: mov-0x500(%rbp),%rdx
  2214 : |   5535bb: mov0x4(%rdx),%edx
   658 : |   5535be: mov%rdx,-0x540(%rbp)
 21572 : |   5535c5: mov-0x538(%rbp),%rdx
  1916 : |   5535cc: vmovsd (%r9,%rdx,8),%xmm0
   987 : |   5535d2: mov-0x540(%rbp),%rdx
  2341 : |   5535d9: vmovhpd (%r9,%rdx,8),%xmm0,%xmm0
  9349 : |   5535df: mov-0x500(%rbp),%rdx
   117 : |   5535e6: mov0x8(%rdx),%edx
  1162 : |   5535e9: mov%rdx,-0x538(%rbp)
   581 : |   5535f0: mov-0x500(%rbp),%rdx
 18660 : |   5535f7: mov0xc(%rdx),%edx
  1778 : |   5535fa: mov%rdx,-0x500(%rbp)
   271 : |   553601: mov-0x538(%rbp),%rdx
  2605 : |   553608: vmovsd (%r9,%rdx,8),%xmm2
  4943 : |   55360e: mov-0x500(%rbp),%rdx
  1206 : |   553615: vmovhpd (%r9,%rdx,8),%xmm2,%xmm2
   : |s += *val_ptr++ * src(*colnum_ptr++);
 11703 : |   55361b: vmulpd 0x10(%rax,%r10,2),%xmm2,%xmm2
 56077 : |   553622: vfmadd132pd (%rax,%r10,2),%xmm2,%xmm0
 47327 : |   553628: add$0x10,%r10
   871 : |   55362c: vaddpd %xmm0,%xmm1,%xmm1
   : |while (val_ptr != val_end_of_row)
 66067 : |   553630: cmp%r11,%r10
  1762 : `-- 553633: jne5535a0 

So it looks like register allocation/spilling issue.

The gimple IL of the loop is the same in both cases, but the "local
count" of the BB with the loop body (in the optimized dump) is
3540039452134 in the fast version and only 832066009199 (so down ~77%).

[Bug middle-end/118691] [15 Regression] gcc_r in SPECCPU 2017 miscompare with PGO + LTO

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Andrew Pinski from comment #3)
> Isn't this a dup of bug 115450 ?

Don't believe so. This is only showing up with PGO for me, but it's only during
training, so I suspect -fprofile-generate is doing something as it doesn't show
up on the job without it.

[Bug d/118477] [12/13/14/15 Regression] Race condition in 'd' Make-lang.in

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|12.5
Summary|Race condition in 'd'   |[12/13/14/15 Regression]
   |Make-lang.in|Race condition in 'd'
   ||Make-lang.in

--- Comment #6 from Jakub Jelinek  ---
I think this is at least in theory a regression already from GCC 11 to GCC 12
which introduced those d/root-%.d and d/common-%.d rules, i.e. r12-5703 and
r12-5849.
d/.deps/file.Tpo and d/.deps/string.Tpo were ambiguous already back then.  But
it is no longer latent only since the recent changes.

[Bug d/118477] [12/13/14/15 Regression] Race condition in 'd' Make-lang.in

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

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

--- Comment #7 from Jakub Jelinek  ---
And for backports we want some minimal change, not revamping where the object
files are located.

[Bug target/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab

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

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

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

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

commit r15-7271-gdc6b949c553a3be1ce4d6671fb8a9de213ede114
Author: Andrew Pinski 
Date:   Tue Jan 28 12:00:06 2025 -0800

split-path: Small fix for poor_ifcvt_pred (tsvc s258) [PR118505]

After r15-3436-gb2b20b277988ab, poor_ifcvt_pred returns false for
the case where the statement could trap but in this case trapping
instructions cannot be made unconditional so it is a poor ifcvt.

This fixes a small preformance regression with TSVC s258 at
`-O3 -ftrapping-math` on aarch64 where ifcvt would not happen
and we would still have a branch.

On a specific aarch64, we go from 0.145s down to 0.118s.

Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

PR tree-optimization/118505
* gimple-ssa-split-paths.cc (poor_ifcvt_pred): Return
true for trapping statements.

Signed-off-by: Andrew Pinski 

[Bug libstdc++/118693] istream& getline (istream& is, string& str, char delim) does not return with long input

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 60315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60315&action=edit
testcase

[Bug middle-end/118691] [15 Regression] gcc_r in SPECCPU 2017 miscompare with PGO + LTO

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Isn't this a dup of bug 115450 ?

[Bug testsuite/118127] gfortran tests XPASS on ppc64le when built with --with-long-double-format=ieee

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:50c111ecd1ae8eb8af0e7938305de7af892ba9ab

commit r14-11260-g50c111ecd1ae8eb8af0e7938305de7af892ba9ab
Author: Siddhesh Poyarekar 
Date:   Thu Dec 19 08:09:15 2024 -0500

testsuite/118127: Pass fortran tests on ppc64le for IEEE128 long doubles

Denormal behaviour is well defined for IEEE128 long doubles, so
XFAIL some gfortran tests only for targets with the IBM128 long double
ABI.

gcc/testsuite/ChangeLog:

PR testsuite/118127
* lib/target-supports.exp
(check_effective_target_long_double_is_ibm128): New
procedure.
* gfortran.dg/default_format_2.f90: xfail for
long_double_is_ibm128.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.

Signed-off-by: Siddhesh Poyarekar 
(cherry picked from commit d4d4e874dee2d5b0abe5ceb9f2a78e5602e86030)

[Bug libstdc++/118693] istream& getline (istream& is, string& str, char delim) does not return with long input

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

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

--- Comment #2 from Jonathan Wakely  ---
I can't reproduce this with upstream GCC or with gcc-14.2.1-3.fc40.x86_64

tmp$ wc input.txt 
   22 4930 input.txt
tmp$ xxd input.txt  | tail -2
1330: 4141 4141 4141 4141 4141 4141 4141 3e0a  AA>.
1340: 3e0a >.
tmp$ head -c 4926 input.txt | ./getline
inputLine.size():  4926
eof():  1, fail():  0, bad():  0, good():  0
tmp$ head -c 4927 input.txt | ./getline
inputLine.size():  4926
eof():  0, fail():  0, bad():  0, good():  1
tmp$ head -c 4928 input.txt | ./getline
inputLine.size():  4926
eof():  0, fail():  0, bad():  0, good():  1
tmp$ head -c 4929 input.txt | ./getline
inputLine.size():  4926
eof():  0, fail():  0, bad():  0, good():  1
tmp$ cat  input.txt | ./getline
inputLine.size():  4926
eof():  0, fail():  0, bad():  0, good():  1


I'll try Fedora 41 ...

[Bug testsuite/118127] gfortran tests XPASS on ppc64le when built with --with-long-double-format=ieee

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #4 from Siddhesh Poyarekar  ---
Fixed.

[Bug rtl-optimization/116073] [15 regression] invalid rtl sharing compiling compiling FileSystem.mod caused by ext-dce

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #7 from Gaius Mulley  ---
Thanks for re-testing.

Another data point I've just also seen armv7a-unknown-linux-gnueabihf bootstrap
and pass regressions.

I'll commit the above patch.

Thanks again.

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

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

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

--- Comment #9 from Robin Dapp  ---
Bisecting further only leads to the commit that introduced the vector ABI. 
Comparing the dumps with and without vector ABI is very tedious because a lot
of things differ.

It looks like we cannot create a reload for a masked sub
 vsub v8,v16,v24,v0.t
(which already uses all available LMUL=8 hard regs).
This insn is being inlined and disabling inlining gets rid of the ICE.

I don't yet understand how the ABI changes spilling possibilities here.

[Bug tree-optimization/118688] path splitting should happen when it is known only path is hot

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> I think tracer should already do this?

Gimple-ssa-path-split.cc has some code which splits the path except it rejects
it to a candidate due to thinking it will be ifcvt (which it will be). So
tracer does not even come into play.

[Bug target/118687] RISC-V extensions for inline asm code (vs. llvm)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID
 Target||riscv

--- Comment #7 from Richard Biener  ---
GCC takes written asm() text literally without verification or macro expansion.
 This is a user error (or a missed feature in gas as said in other comments).

[Bug tree-optimization/118688] path splitting should happen when it is known only path is hot

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|patch splitting should  |path splitting should
   |happen when it is known |happen when it is known
   |only path is hot|only path is hot

--- Comment #2 from Richard Biener  ---
I think tracer should already do this?

[Bug c++/118655] [14 Regression] std::is_bounded_array::value returns true for zero-size arrays

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14/15 Regression]  |[14 Regression]
   |std::is_bounded_array::valu |std::is_bounded_array::valu
   |e returns true for  |e returns true for
   |zero-size arrays|zero-size arrays

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

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

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

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

--- Comment #17 from Christoph Müllner  ---
I reproduced the slow-down with a recent master on a 5950X:
* no-mem-fold-offset: 4m58.226s
* mem-fold-offset: 11m19.311s (+127%)

More details from -ftime-report:
* no-mem-fold-offset: df reaching defs   :   9.34 (  3%) 0  (  0%)
* mem-fold-offset: df reaching defs  : 381.40 ( 55%) 0  (  0%)

A look at the detailed time report (-ftime-report -ftime-report-details) shows:

Time variable  wall   GGC
[...]
 phase opt and generate : 682.81 ( 99%)  6175M ( 97%)
 [...]
 callgraph functions expansion  : 646.99 ( 94%)  5695M ( 89%)
[...]
 fold mem offsets   :   1.73 (  0%)   679k (  0%)
 `- CFG verifier:   2.10 (  0%) 0  (  0%)
 `- df use-def / def-use chains :   2.32 (  0%) 0  (  0%)
 `- df reaching defs: 370.68 ( 54%) 0  (  0%)
 `- verify RTL sharing  :   0.05 (  0%) 0  (  0%)
[...]
 TOTAL  : 690.06 6365M

I read this as "fold mem offset utilizes 0% of memory", so there is no issue
with the memory footprint.

To confirm this, `time -v` was used:
* no-mem-fold-offset: Maximum resident set size (kbytes): 15563684
* mem-fold-offset: Maximum resident set size (kbytes): 15564364

I looked at the pass, and a few things could be cleaned up in the pass itself
(e.g., redundant calls). However, that won't change anything in the observed
performance.
The time-consuming part is UD+DU DF analysis for the whole function.
Even if the pass would "return 0" right after doing nothing but the analysis,
we end up with the same run time (confirmed by measurement).

The pass operates on BB-granularity, so DF analysis of the whole function
provides more information than needed. When going through the documentation, I
came across df_set_blocks(), which I expected to reduce the problem
significantly.
So, I moved the df_analyse() call into the FOR_ALL_BB_FN() loop, right after a
call to df_set_blocks(), with the intent to only have a single block set per
iteration.
However, that triggered a few ICEs in DF, and once they were bypassed, ended up
in practical non-termination (i.e. the calls to df_analyse() won't get
significantly cheaper by df_set_blocks()).

My conclusion:
This can only be fixed by not using DF analysis and implementing a
pass-specific analysis.

So far, I have not found a good solution for this. But I haven't looked at all
the suggestions in detail. Can someone help me find what Paolo referenced as
"the multiple definitions DF problem that was introduced for fwprop in 2009"?

[Bug c++/118655] [14/15 Regression] std::is_bounded_array::value returns true for zero-size arrays

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

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

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

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

commit r15-7263-g3a6ddbf7b241e1cd9f73495ea373b0a12015bb07
Author: Jakub Jelinek 
Date:   Wed Jan 29 09:32:04 2025 +0100

c++: Return false from __is_bounded_array for zero-sized arrays [PR118655]

This is basically Marek's PR114479 r14-9759 __is_array fix applied to
__is_bounded_array as well.  Similarly to that trait, when not using
the builtin it returned false for zero sized arrays but when using
the builtin it returns true.

2025-01-29  Jakub Jelinek  

PR c++/118655
* semantics.cc (trait_expr_value) :
Return
false for zero-sized arrays.

* g++.dg/ext/is_bounded_array.C: Extend.

[Bug rtl-optimization/117922] [15 Regression] 1000% compilation time slow down on the testcase from pr26854

[bonzini at gnu dot org via Gcc-bugs]

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

--- Comment #18 from Paolo Bonzini  ---
> Can someone help me find what Paolo referenced as "the multiple definitions 
> DF problem 
> that was introduced for fwprop in 2009"?

Yes, the patch is at
https://gcc.gnu.org/pipermail/gcc-patches/2009-June/263754.html

It's composed of two parts:

1) a cheap dataflow problem that records registers that have multiple
definitions where the CFG joins. The problem instructs the pass to ignore
completely those registers

2) a dominator walk to note use-def relations where there can be only one
definition.

The basic algorithm starts at function build_single_def_use_links() in
fwprop.c.  You can find the old version of the file in git, just ask if you
have more questions.

[Bug target/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab

[dhruvc at nvidia dot com via Gcc-bugs]

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

--- Comment #18 from Dhruv Chawla  ---
(In reply to Andrew Pinski from comment #16)
> So if we add:
> if ((rand() & 1))
>  arr[i] *= -1;
> 
> For the initialization loop. 
> 
> And increase the 2D size from 256 to 1000 (this part is important).
> The difference between path splitting vs non path splitting is:
> 0.646 (ifcvt) vs 0.676 (split path)
> 
> Which means then ifcvt is faster. 
> 
> So it is just a bad benchmark.
> I will submit the changes I found for the trapping case later today though.

Yup, seeing the same behaviour. Thanks for looking at this!

[Bug target/118687] RISC-V extensions for inline asm code (vs. llvm)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
If you want the compiler to synthetize the constant, why don't you use asm (""
: "=r" (ret) : "0" (0x0123456789abcdefull)); (of course in this case why not
just return 0x0123456789abcdefull).  In any case, ask for the constant to be in
either some register or a selected specific register.

[Bug ipa/101625] [12/13/14/15 Regression] ICE in modref_tree::merge with LTO since r11-3825-g71dbabccbfb295c8

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |ICE in  |ICE in
   |modref_tree::merge |modref_tree::merge
   |with LTO and -m32 since |with LTO since
   |r11-3825-g71dbabccbfb295c8  |r11-3825-g71dbabccbfb295c8
   Last reconfirmed|2021-08-02 00:00:00 |2025-1-29
  Known to work||10.5.0

--- Comment #7 from Andrew Pinski  ---
`-xc -std=c11 -Os -ffat-lto-objects -nostdlib -nostdlib -Wl,-r,-d -flto`

[Bug fortran/108454] ICE in gfc_trans_common, at fortran/trans-common.cc:1385

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 60322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60322&action=edit
Patch part 1

This fixes the memory corruption due to false freeing of the
symbol during resolution.

To be done: reject invalid testcase z4.

[Bug ipa/105227] [12/13/14/15 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233 since r9-2502-g143b379d89b12ccc

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

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 60323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60323&action=edit
Reduced testcase

[Bug c++/118697] New: static_assert message is not escaped

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

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

Bug ID: 118697
   Summary: static_assert message is not escaped
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

So there is a different behavior from the C front-end where the non-printable
characters are escaped.
I am not sure if this is a C or C++ front-end issue but it would be good to
have them agree.

Simple testcase:
```
static_assert(0, "\x1b[31mThis should be red\x1b[0m");
```

The C front-end will escape the \x1b while the C++ front-end will just print as
is.

[Bug c/55678] _Static_assert escapes tick marks just to make me mad

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Note escaping `'` in double quoted strings is ok as "\'" is valid still.

[Bug c++/118698] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #2 from Andrew Pinski  ---
The ICE:
```
:23:17: internal compiler error: in keep_template_parm, at
cp/pt.cc:11099
   23 | static_assert(  is_foo> );
  | ^~~~
0x290bff5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29230c6 internal_error(char const*, ...)
???:0
0xacd248 fancy_abort(char const*, int, char const*)
???:0
0x17eed6c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x17eed6c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x17eed6c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x17eed6c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x17eed6c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x17ef061 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xd05382 find_template_parameters(tree_node*, tree_node*)
???:0
0xb54668 evaluate_concept_check(tree_node*)
???:0
0xb470d0 maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0xd74640 finish_static_assert(tree_node*, tree_node*, unsigned long, bool,
bool)
???:0
0xcebbc3 c_parse_file()
???:0
0xe4d569 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
```

[Bug c++/118698] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 60325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60325&action=edit
testcase

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||14.1.0
   Target Milestone|--- |14.3
Summary|Compiler ICE on concept |[14/15 Regression] Compiler
   |code accepted by MSVC and   |ICE on concept code
   |clang   |accepted by MSVC and clang
  Known to work||13.3.0

[Bug c++/118698] [14/15 Regression] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #7 from Andrew Pinski  ---
Note the reduced testcase worked in GCC 13 but the original testcase was
rejected.

[Bug c++/118698] Compiler ICE on concept code accepted by MSVC and clang

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-01-30

--- Comment #5 from Andrew Pinski  ---
Confirmed. It is both related to the decltype of the lambda and the template
template argument.

[Bug testsuite/116860] Move optimization from match.pd into tree-ssa-reassoc (optimize_range_tests) where it can be more effective

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P2
Summary|[15 Regression] New test|Move optimization from
   |case|match.pd into
   |gcc.dg/tree-ssa/fold-xor-an |tree-ssa-reassoc
   |d-or.c from |(optimize_range_tests)
   |r15-3866-ga88d6c6d777ad7|where it can be more
   |fails   |effective
   Assignee|law at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

[Bug c++/118698] Compiler ICE on concept code accepted by MSVC and clang

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 60326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60326&action=edit
Semi reduced

[Bug c++/118698] Compiler ICE on concept code accepted by MSVC and clang

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60326|0   |1
is obsolete||

--- Comment #4 from Andrew Pinski  ---
Created attachment 60327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60327&action=edit
Reduced further

[Bug testsuite/116860] [15 Regression] New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails

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

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

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

https://gcc.gnu.org/g:15dba7dfba8b7800ac7b74213171e4df9bc32bb9

commit r15-7281-g15dba7dfba8b7800ac7b74213171e4df9bc32bb9
Author: Jeff Law 
Date:   Wed Jan 29 19:42:11 2025 -0700

[PR testsuite/116860] Testsuite adjustment for recently added tests

There's two new tests that are dependent on logical-op-non-short-circuit
settings.  The BZ is reported against ppc64 and ppc64le, but also applies
to a
goodly number of the other targets.

The "regression" fix is trivial, just add the appropriate param to force
the
behavior we're expecting.  I'm committing that fix momentarily.  It's been
verified on ppc64, ppc64le and x86_64 as well as the various embedded
targets
in my tester where many FAILS flip to PASS.

I'm leaving the bug open without the regression marker as Jakub has noted a
couple of improvements that we can and probably should make.

PR target/116860
gcc/testsuite
* gcc.dg/tree-ssa/fold-xor-and-or.c: Set
logical-op-non-short-circuit.
* gcc.dg/tree-ssa/fold-xor-or.c: Similarly.

[Bug c++/118698] Compiler ICE on concept code accepted by MSVC and clang

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60327|0   |1
is obsolete||

--- Comment #6 from Andrew Pinski  ---
Created attachment 60328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60328&action=edit
Remove variable template arguments

[Bug target/118696] [15 Regression] qemu miscompilation on s390x

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug tree-optimization/96945] unused std::vector is not always optimized away

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

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

Bug 110137 Summary: implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137

   What|Removed |Added

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

[Bug middle-end/116868] GCC trunk doesn't eliminate a superfluous new/delete pair

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

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

Bug 110137 Summary: implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137

   What|Removed |Added

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

[Bug libstdc++/109442] Dead local copy of std::vector not removed from function

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

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

Bug 110137 Summary: implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137

   What|Removed |Added

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

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #36 from Sam James  ---
Fixed in 15, or are we keeping it open for something?

[Bug d/118477] [12/13/14/15 Regression] Race condition in 'd' Make-lang.in

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

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

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

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

commit r15-7278-gd9ac0ad1e9a4ceec2d354ac0368da7462bea5675
Author: Arsen ArsenoviÄ 
Date:   Wed Jan 29 21:14:33 2025 +0100

d: give dependency files better filenames [PR118477]

Currently, the dependency files for root-file.o and common-file.o were
both d/.deps/file.Po, which would cause parallel builds to fail
sometimes with:

  make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/build/gcc'
  make[3]: Entering directory
'/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/build/gcc'
  mv: cannot stat 'd/.deps/file.TPo': No such file or directory
  make[3]: ***
[/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/gcc-14-20240511/gcc/d/Make-lang.in:421:
d/root-file.o] Error 1 shuffle=131581365

Also, this means that dependencies of one of root-file or common-file
are missing when developing.  After this patch, those two files get
assigned dependency files d/.deps/root-file.Po and
d/.deps/common-file.Po respectively, so match the actual object
files in the d/ subdirectory.

There are other files with similar conflicts (mangle-package.o,
visitor-package.o for instance).

2025-01-29  Arsen ArsenoviÄ  
Jakub Jelinek  

PR d/118477
* Make-lang.in (DCOMPILE, DPOSTCOMPILE): Use $(basename $(@F))
instead of $(*F).

Co-Authored-By: Jakub Jelinek 

[Bug target/116010] [15 regression] vectorization regressions on arm and aarch64 since r15-491-gc290e6a0b7a9de

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

--- Comment #11 from Thiago Jung Bauermann  
---
(In reply to Richard Biener from comment #10)
> Should be fixed.

Thanks! I can confirm that the gfortran.dg/vect/vect-8.f90 failure has been
fixed on aarch64-linux-gnu.

But unfortunately the gcc.target/arm/simd/mve-vabs.c failure on
armv8l-linux-gnueabihf and arm-eabi is still present.

Should I open a separate bugzilla for it?

[Bug middle-end/92023] [12/13/14/15 Regression] Miscompilation when inlining operator delete[]

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

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

--- Comment #10 from Richard Biener  ---
I think we should try to behave better by default here, for QOI reasons.  I'm
not sure the implementation is conforming.

As for how to improve our standard behavior it might be possible to simply
ignore a (implicit) malloc attribute for functions which we have a definition
for (once we stream PTA info we have to be careful with LTO here).  This
wouldn't be enough if only operator delete[] would have a visible difinition
but not operator new[] - but at least for C++ it might be possible to
connect both, thus look up a corresponding operator delete[] or have the
frontend set some flag on the availability.

Alternatively to ignoring malloc we could slap 'noipa' on those operators.
Though of course they might simply wrappers around global new/delete.

IIRC we do have documentation on issues with malloc/free implementations being
visible.

[Bug target/116010] [15 regression] vectorization regressions on arm and aarch64 since r15-491-gc290e6a0b7a9de

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 29 Jan 2025, thiago.bauermann at linaro dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116010
> 
> --- Comment #11 from Thiago Jung Bauermann  org> ---
> (In reply to Richard Biener from comment #10)
> > Should be fixed.
> 
> Thanks! I can confirm that the gfortran.dg/vect/vect-8.f90 failure has been
> fixed on aarch64-linux-gnu.
> 
> But unfortunately the gcc.target/arm/simd/mve-vabs.c failure on
> armv8l-linux-gnueabihf and arm-eabi is still present.
> 
> Should I open a separate bugzilla for it?

Please - from a quick look this looks unrelated, possibly just requiring
scan-assembler-times adjustments (I never know how to test this MVE stuff
myself)

[Bug rtl-optimization/116073] [15 regression] invalid rtl sharing compiling compiling FileSystem.mod caused by ext-dce

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:62abe069506e67d2668e8de7c5e00c118c60d8a7

commit r15-7279-g62abe069506e67d2668e8de7c5e00c118c60d8a7
Author: Gaius Mulley 
Date:   Wed Jan 29 20:32:07 2025 +

PR modula2/116073 invalid rtl sharing compiling FileSystem.mod caused by
ext-dce

The bug fixes to PR modula2/118010 and PR modula2/118183 uncovered a bug
in the procedure interface to lseek which uses SYSTEM.COFF_T rather than
SYSTEM.CSSIZE_T.  This patch sets the default size for COFF_T to the same
as CSSIZE_T.

gcc/ChangeLog:
PR modula2/118010
PR modula2/118183
PR modula2/116073
* doc/gm2.texi (-fm2-file-offset-bits=): Change the default size
description to CSSIZE_T.
Add COFF_T to the list of data types exported by SYSTEM.def.

gcc/m2/ChangeLog:
PR modula2/118010
PR modula2/118183
PR modula2/116073
* gm2-compiler/M2Options.mod (OffTBits): Assign to 0.
* gm2-gcc/m2type.cc (build_m2_specific_size_type): Ensure that
layout_type is called before returning c.
(build_m2_offt_type_node): If GetFileOffsetBits returns 0 then
use the type size of ssize_t.

gcc/testsuite/ChangeLog:

PR modula2/118010
PR modula2/118183
PR modula2/116073
* gm2/pim/run/pass/printtypesize.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug rtl-optimization/116073] [15 regression] invalid rtl sharing compiling compiling FileSystem.mod caused by ext-dce

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #9 from Gaius Mulley  ---
Closing.

[Bug modula2/118010] -Wlto-type-mismatch warning/error during m2 bootstrap on arm (gm2-libs-boot/Glibc.h:206:16: warning: type of ‘libc_lseek’ does not match original declaration [-Wlto-type-mismatch]

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:62abe069506e67d2668e8de7c5e00c118c60d8a7

commit r15-7279-g62abe069506e67d2668e8de7c5e00c118c60d8a7
Author: Gaius Mulley 
Date:   Wed Jan 29 20:32:07 2025 +

PR modula2/116073 invalid rtl sharing compiling FileSystem.mod caused by
ext-dce

The bug fixes to PR modula2/118010 and PR modula2/118183 uncovered a bug
in the procedure interface to lseek which uses SYSTEM.COFF_T rather than
SYSTEM.CSSIZE_T.  This patch sets the default size for COFF_T to the same
as CSSIZE_T.

gcc/ChangeLog:
PR modula2/118010
PR modula2/118183
PR modula2/116073
* doc/gm2.texi (-fm2-file-offset-bits=): Change the default size
description to CSSIZE_T.
Add COFF_T to the list of data types exported by SYSTEM.def.

gcc/m2/ChangeLog:
PR modula2/118010
PR modula2/118183
PR modula2/116073
* gm2-compiler/M2Options.mod (OffTBits): Assign to 0.
* gm2-gcc/m2type.cc (build_m2_specific_size_type): Ensure that
layout_type is called before returning c.
(build_m2_offt_type_node): If GetFileOffsetBits returns 0 then
use the type size of ssize_t.

gcc/testsuite/ChangeLog:

PR modula2/118010
PR modula2/118183
PR modula2/116073
* gm2/pim/run/pass/printtypesize.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug modula2/118183] Unable to rebuild the bootstrap tools

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:62abe069506e67d2668e8de7c5e00c118c60d8a7

commit r15-7279-g62abe069506e67d2668e8de7c5e00c118c60d8a7
Author: Gaius Mulley 
Date:   Wed Jan 29 20:32:07 2025 +

PR modula2/116073 invalid rtl sharing compiling FileSystem.mod caused by
ext-dce

The bug fixes to PR modula2/118010 and PR modula2/118183 uncovered a bug
in the procedure interface to lseek which uses SYSTEM.COFF_T rather than
SYSTEM.CSSIZE_T.  This patch sets the default size for COFF_T to the same
as CSSIZE_T.

gcc/ChangeLog:
PR modula2/118010
PR modula2/118183
PR modula2/116073
* doc/gm2.texi (-fm2-file-offset-bits=): Change the default size
description to CSSIZE_T.
Add COFF_T to the list of data types exported by SYSTEM.def.

gcc/m2/ChangeLog:
PR modula2/118010
PR modula2/118183
PR modula2/116073
* gm2-compiler/M2Options.mod (OffTBits): Assign to 0.
* gm2-gcc/m2type.cc (build_m2_specific_size_type): Ensure that
layout_type is called before returning c.
(build_m2_offt_type_node): If GetFileOffsetBits returns 0 then
use the type size of ssize_t.

gcc/testsuite/ChangeLog:

PR modula2/118010
PR modula2/118183
PR modula2/116073
* gm2/pim/run/pass/printtypesize.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug rtl-optimization/77499] [12/13/14/15 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2023-09-02 00:00:00 |2025-1-29

--- Comment #26 from Andrew Pinski  ---
We get on the trunk -O2:
```
.L4:
lsrsr0, r0, #1
mla lr, r4, r1, r6
subsr1, r1, r3
eor ip, r0, r5
uxthip, ip
cmp lr, #1431655765
it  cs
movcs   r0, ip
cmp r2, r1
blt .L4
```

-O2 -fno-code-hoisting:
```
.L5:
mla ip, r4, r1, lr
subsr1, r1, r3
cmp ip, #1431655765
ite cs
eorcs   r0, r5, r0, lsr #1
lsrcc   r0, r0, #1
cmp r2, r1
blt .L5
```

[Bug target/118008] [14/15 regression] ICE when bootstrapping with Go on arm (gen_movdi, at config/arm/arm.md:6296)

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

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

--- Comment #12 from Andrew Pinski  ---
So PR 118695 has a C testcase for a similar ICE. The problem is the code there
is undefined while here it might be well defined (but I am not so sure).

[Bug target/118695] ice in gen_movsi, at config/arm/arm.md:6476

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 60320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60320&action=edit
ICE in gen_movdi instead of gen_movsi

[Bug middle-end/116651] Memory allocation elision for std::vector like cases

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

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

Bug 110137 Summary: implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137

   What|Removed |Added

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