[Bug testsuite/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 #8 from Thomas Schwinge  ---
Tamar, thanks!  I confirm all fixed -- but one:

(In reply to myself from comment #1)
> ..., and similarly -- but not identical! -- for '-march=gfx1100':

> 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"

Which cure does that one need?

[Bug tree-optimization/119858] [15/16 Regression] GCN vs. "middle-end: Fix incorrect codegen with PFA and VLS [PR119351]"

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #1 from Tamar Christina  ---
Thanks for the report,

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 958b829fa8d..cd80b38e15d 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -11657,8 +11657,11 @@ vectorizable_live_operation (vec_info *vinfo,
stmt_vec_info stmt_info,
break_lhs_phi);

  if (POINTER_TYPE_P (TREE_TYPE (new_tree)))
-   tmp2 = gimple_build (&iv_stmts, POINTER_PLUS_EXPR,
-TREE_TYPE (new_tree), new_tree, tmp2);
+   {
+ tmp2 = gimple_convert (&iv_stmts, sizetype, tmp2);
+ tmp2 = gimple_build (&iv_stmts, POINTER_PLUS_EXPR,
+  TREE_TYPE (new_tree), new_tree,
tmp2);
+   }
  else
{
  tmp2 = gimple_convert (&iv_stmts, TREE_TYPE (new_tree),

fixes it, will submit after easter

[Bug testsuite/119818] FAIL: cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob -O0 execution test

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
   Keywords||patch
 CC||jklowden at gcc dot gnu.org,
   ||rdubner at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-04-18
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
 "Fix time
zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob' [PR119818]".

[Bug rtl-optimization/119160] wrong code with -O2 -finstrument-functions-once -favoid-store-forwarding -fnon-call-exceptions -fschedule-insns -mgeneral-regs-only

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Philipp Tomsich :

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

commit r16-15-g7e628ff49f7f890d5337369d7b4f8e21a1f17029
Author: kelefth 
Date:   Thu Mar 13 11:49:39 2025 +0100

avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

In the case that we are eliminating the load instruction, we use
zero_extend
for the initialization of the base register for the zero-offset store.
This causes issues when the store and the load use the same mode,
as we are trying to generate a zero_extend with the same inner and
outer modes.

This patch fixes the issue by zero-extending the value stored in the
base register only when the load's mode is wider than the store's mode.

PR rtl-optimization/119160

gcc/ChangeLog:

* avoid-store-forwarding.cc (process_store_forwarding):
Zero-extend the value stored in the base register, in case
of load-elimination, only when the mode of the destination
is wider.

gcc/testsuite/ChangeLog:

* gcc.dg/pr119160.c: New test.

[Bug libstdc++/119840] FAIL: g++.old-deja/g++.robertl/eb73.C -std=gnu++26 (test for excess errors)

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

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

--- Comment #4 from Tomasz Kamiński  ---
I would like to get confirmation from John David Anglin, that warnings no
longer appear on the target.

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #10)
> Hi Folks,
> 
> Is it worth reverting or fixing this before the 15-branch release? After
> all, the bug made its way into the Fedora 42 release?
> 
> Cheers
> 
> Paul

I agree that doing one of these options very soon, and asking the RM
to allow a backport.

Any refinement of checks can be done for 16 or later.

[Bug tree-optimization/119858] New: [15/16 Regression] GCN vs. "middle-end: Fix incorrect codegen with PFA and VLS [PR119351]"

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

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

Bug ID: 119858
   Summary: [15/16 Regression] GCN vs. "middle-end: Fix incorrect
codegen with PFA and VLS [PR119351]"
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, tnfchris at gcc dot gnu.org
Blocks: 119351
  Target Milestone: ---
Target: GCN

For '--target=amdgcn-amdhsa' (tested '-march=gfx908', '-march=gfx1100'), the
recent commit r15-9518-g46ccce1de686c1b437eff43431dc20d20d4687c0 "middle-end:
Fix incorrect codegen with PFA and VLS [PR119351]" is causing a number of
GIMPLE checking ICEs:

[...]/source-gcc/gcc/testsuite/gcc.c-torture/compile/930325-1.c: In
function 'f':
[...]/source-gcc/gcc/testsuite/gcc.c-torture/compile/930325-1.c:15:1:
error: type mismatch in 'pointer_plus_expr'
uint *

uint *

unsigned int

_245 = _243 + _244;
during GIMPLE pass: vect
[...]/source-gcc/gcc/testsuite/gcc.c-torture/compile/930325-1.c:15:1:
internal compiler error: verify_gimple failed
0x22db616 internal_error(char const*, ...)
[...]/source-gcc/gcc/diagnostic-global-context.cc:517
0x129972e verify_gimple_in_cfg(function*, bool, bool)
[...]/source-gcc/gcc/tree-cfg.cc:5682
0x11268e0 execute_function_todo
[...]/source-gcc/gcc/passes.cc:2101
0x1126e5b execute_todo
[...]/source-gcc/gcc/passes.cc:2155

(Not fixed by follow-up commit
r15-9550-g7cf5503e0af52f5b726da4274a148590c57a458a "middle-end: fix masking for
partial vectors and early break [PR119351]".)

PASS: gcc.c-torture/compile/930325-1.c   -O0  (test for excess errors)
PASS: gcc.c-torture/compile/930325-1.c   -O1  (test for excess errors)
PASS: gcc.c-torture/compile/930325-1.c   -O2  (test for excess errors)
{+FAIL: gcc.c-torture/compile/930325-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error: verify_gimple failed)+}
[-PASS:-]{+FAIL:+} gcc.c-torture/compile/930325-1.c   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
{+FAIL: gcc.c-torture/compile/930325-1.c   -O3 -g  (internal compiler
error: verify_gimple failed)+}
[-PASS:-]{+FAIL:+} gcc.c-torture/compile/930325-1.c   -O3 -g  (test for
excess errors)
PASS: gcc.c-torture/compile/930325-1.c   -Os  (test for excess errors)

PASS: gcc.c-torture/compile/pr37056.c   -O0  (test for excess errors)
PASS: gcc.c-torture/compile/pr37056.c   -O1  (test for excess errors)
PASS: gcc.c-torture/compile/pr37056.c   -O2  (test for excess errors)
{+FAIL: gcc.c-torture/compile/pr37056.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error: verify_gimple failed)+}
[-PASS:-]{+FAIL:+} gcc.c-torture/compile/pr37056.c   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
{+FAIL: gcc.c-torture/compile/pr37056.c   -O3 -g  (internal compiler error:
verify_gimple failed)+}
[-PASS:-]{+FAIL:+} gcc.c-torture/compile/pr37056.c   -O3 -g  (test for
excess errors)
PASS: gcc.c-torture/compile/pr37056.c   -Os  (test for excess errors)

PASS: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O0 
PASS: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O1 
PASS: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O2 
{+FAIL:+} gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
[-PASS:-]{+(internal compiler error: verify_gimple failed)+}
[-PASS:-]{+FAIL:+} gcc.c-torture/execute/builtins/memset-chk.c compilation,
 -O3 -g  {+(internal compiler error: verify_gimple failed)+}
PASS: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -Og -g 
PASS: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -Os 
PASS: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O0 
PASS: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O1 
PASS: gcc.c-torture/execute/builtins/memset-chk.c execution,  -O2 
[-PASS:-]{+UNRESOLVED:+} gcc.c-torture/execute/builtins/memset-chk.c
execution,  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions 
[-PASS:-]{+UNRESOLVED:+} gcc.c-torture/execute/builtins/memset-chk.c
execution,  -O3 -g 
PASS: gcc.c-torture/execute/builtins/memset-chk.c execution,  -Og -g 
PASS: gcc.c-torture/execute/builtins/memset-chk.c execution,  -Os 

@@ -21007,10 +21011,12 @@ PASS: gcc.c-torture/execute/memset-1.c   -O1 
(test for excess 

[Bug libgomp/119857] New: GCN offloading: occasional 'libgomp.c-c++-common/declare-target-indirect-2.c' execution test FAIL

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

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

Bug ID: 119857
   Summary: GCN offloading: occasional
'libgomp.c-c++-common/declare-target-indirect-2.c'
execution test FAIL
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: openmp, testsuite-fail
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcy at codesourcery dot com
  Target Milestone: ---
Target: GCN

With GCN offloading (but not nvptx?), I occasionally see:

[-PASS:-]{+FAIL:+}
libgomp.c++/../libgomp.c-c++-common/declare-target-indirect-2.c execution test

assertion "indirect_htab" failed: file
"[...]/source-gcc/libgomp/config/accel/target-indirect.c", line 104, function:
GOMP_target_map_indirect_ptr
[...]

It may be a coincidence, but I only ever saw the FAILs for
'libgomp.c++/../libgomp.c-c++-common/declare-target-indirect-2.c', but not
'libgomp.c/../libgomp.c-c++-common/declare-target-indirect-2.c'.

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

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

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

--- Comment #9 from Tamar Christina  ---
(In reply to Thomas Schwinge from comment #8)
> Tamar, thanks!  I confirm all fixed -- but one:
> 
> (In reply to myself from comment #1)
> > ..., and similarly -- but not identical! -- for '-march=gfx1100':
> 
> > 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"
> 
> Which cure does that one need?

oh I hadn't realized that the cause for that test for -march-gfx1100 was
different than for gfx908.

vect-early-break_38.c:15:20: missed:   unsupported vect permute { 0 2 4 6 8 10
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62
64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 104 106 108 110
112 114 116 118 120 122 124 126 }
vect-early-break_38.c:15:20: missed:   single-element interleaving permutation
not supported, using elementwise access

It's scalarizing the loads again so the fix is the same as

vect-early-break_18.c

in that it needs a consistent architecture. -march=gfx908 is testing what the
test was intended to test.

[Bug tree-optimization/119858] [15/16 Regression] GCN vs. "middle-end: Fix incorrect codegen with PFA and VLS [PR119351]"

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

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

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

https://gcc.gnu.org/g:1f7ac78efa622e19f38d6a45e857941b3dea1437

commit r16-19-g1f7ac78efa622e19f38d6a45e857941b3dea1437
Author: Richard Biener 
Date:   Fri Apr 18 14:52:41 2025 +0200

tree-optimization/119858 - type mismatch with POINTER_PLUS

The recent PFA early-break vectorization fix left us with a POINTER_PLUS
and non-sizetype offset.

PR tree-optimization/119858
* tree-vect-loop.cc (vectorizable_live_operation): Convert
pointer offset to sizetype.

[Bug tree-optimization/119858] [15/16 Regression] GCN vs. "middle-end: Fix incorrect codegen with PFA and VLS [PR119351]"

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Richard Biener
:

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

commit r15-9557-gd88b917325546cee24a544dc05cbfbef0febfe25
Author: Richard Biener 
Date:   Fri Apr 18 14:52:41 2025 +0200

tree-optimization/119858 - type mismatch with POINTER_PLUS

The recent PFA early-break vectorization fix left us with a POINTER_PLUS
and non-sizetype offset.

PR tree-optimization/119858
* tree-vect-loop.cc (vectorizable_live_operation): Convert
pointer offset to sizetype.

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #12 from kargls at comcast dot net ---
On 4/17/25 23:59, pault at gcc dot gnu.org wrote:
> 
> Is it worth reverting or fixing this before the 15-branch release? After all,
> the bug made its way into the Fedora 42 release?

I'll submit a patch that fixes it tomorrow.

[Bug c++/119859] [15 Regression?] template member function overload with base class

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/119859] [15 Regression?] template member function overload with base class

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/119859] [15 Regression?] template member function overload with base class

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
This was changed by r15-3740 which corrected our CWG 2273 implementation to
apply the inherited-ness tiebreaker only to constructors rather than to all
member functions, and as you point out the candidates effectively only differ
in their return type wrt overload resolution, so rejecting this example as
ambiguous seems right to me.

It's interesting however that although GCC and Clang now agree on the
using1.C/using5.C testcases changed in r15-3740, here Clang disagrees and
chooses the non-inherited function, but I don't see a justification for that. 
Jason, what do you think?

[Bug c++/119859] [15 Regression] template member function overload with base class

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

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

--- Comment #2 from Andrew Pinski  ---
Another example:
```
struct A {
  template
  const A& f();
  const A& g();
};

struct B : public A {
  using A::f;
  using A::g;
  template
  const int f();
  const int g();
};

int main() {
  B b;
  b.g();
  b.f<0>();
}
```

GCC trunk seemly only rejects the template member function as being ambigious
though.

[Bug libstdc++/119861] New: formatter specialization of formatter for map class scope has set_separator/set_brackets

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 119861
   Summary: formatter specialization of formatter for map class
scope has set_separator/set_brackets
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

[Bug libstdc++/119861] formatter specialization for map-like range has set_separator/set_brackets

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
..which should not:

#include 

struct Map {
  std::pair* begin();
  std::pair* end();
};

template<>
constexpr auto std::format_kind = std::range_format::map;

int main() {
  std::formatter fmt;
  fmt.set_separator("?");
  fmt.set_brackets({}, {});
}

https://godbolt.org/z/xWxvfhqYK

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

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

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

--- Comment #13 from Jerry DeLisle  ---
(In reply to kargls from comment #12)
> On 4/17/25 23:59, pault at gcc dot gnu.org wrote:
> > 
> > Is it worth reverting or fixing this before the 15-branch release? After 
> > all,
> > the bug made its way into the Fedora 42 release?
> 
> I'll submit a patch that fixes it tomorrow.

Standing by ready to assist.

[Bug testsuite/119862] New: gcc.dg/pr119160.c FAILs

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

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

Bug ID: 119862
   Summary: gcc.dg/pr119160.c FAILs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: konstantinos.eleftheriou at vrull dot eu
  Target Milestone: ---
Target: *-*-solaris2.11

The new gcc.dg/pr119160.c test FAILs on Solaris, both sparc and x86, 32 and
64-bit:

+FAIL: gcc.dg/pr119160.c (test for excess errors)
+UNRESOLVED: gcc.dg/pr119160.c compilation failed to produce executable

On sparc, the failure is

Excess errors:
xgcc: error: unrecognized command-line option '-mgeneral-regs-only' 

while on x86 it's

Excess errors:
Undefined   first referenced
 symbol in file
__cyg_profile_func_exit /var/tmp//cc.HL88a.o
__cyg_profile_func_enter/var/tmp//cc.HL88a.o
ld: fatal: symbol referencing errors

The -mgeneral-regs-only option is only supported on arm, aarch64, and i386,
so the test should be restricted accordingly.

Haven't looked at the x86 link failure yet.

[Bug c++/119859] [15 Regression] template member function overload with base class

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

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

--- Comment #3 from Andrew Pinski  ---
Another example:
```
struct A {
  template
  const A& f(T);
  const A& g(int);
  template
  const A& h();
};

struct B : public A {
  using A::f;
  using A::g;
  using A::h;
  template
  const int f(T);
  const int g(int);
  template
  const int h();
};

int main() {
  B b;
  b.g(0);
  b.f(0);
  b.h();
}
```

Only `b.f(0)` is rejected as ambiguous on GCC 15+.

[Bug testsuite/119862] gcc.dg/pr119160.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |16.0

[Bug c++/119859] [15 Regression] template member function overload with base class

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

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

--- Comment #4 from Jason Merrill  ---
(In reply to Andrew Pinski from comment #2)
> GCC trunk seemly only rejects the template member function as being
> ambigious though.

Yes, because https://eel.is/c++draft/namespace.udecl#11 says "The set of
declarations named by a using-declarator that inhabits a class C does not
include member functions and member function templates of a base class that
correspond to (and thus would conflict with) a declaration of a function or
function template in C."

And "correspond" is defined in terms of the parameters for non-template
functions, while it considers the return type for function templates.  So A::g
corresponds to B::g (and so is not added), but A::f does not correspond to B::f
(and is added).

So both declarations of f are candidates.  As others have pointed out, there is
no difference in the conversion for the object parameter.  The return type does
not participate in overload resolution.  And I don't see anything in
[over.match.best] that would apply here.

The tiebreaker in https://eel.is/c++draft/over#match.best.general-2.7 was
originally proposed to apply to all functions, but was limited to only
constructors at the 2017-05-08 CWG teleconference.

So I agree with Patrick, this seems ambiguous under the current draft.  It is
mysterious why Clang would treat this differently from the non-template default
argument case.

[Bug c++/119859] [15 Regression] template member function overload with base class

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

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

--- Comment #5 from Jason Merrill  ---
(In reply to Andrew Pinski from comment #3)
> Another example:
...
>   template
>   const A& h();
...
>   b.h();

T cannot be deduced in this call, so A::h is not a viable candidate, so it's
not ambiguous.

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org,
   ||pinskia at gmail dot com

--- Comment #10 from Paul Thomas  ---
Hi Folks,

Is it worth reverting or fixing this before the 15-branch release? After all,
the bug made its way into the Fedora 42 release?

Cheers

Paul

[Bug testsuite/119818] FAIL: cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob -O0 execution test

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

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

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

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

commit r16-30-ged8761241ac529ccddb2b76a1895c124c67c132c
Author: Thomas Schwinge 
Date:   Fri Apr 18 13:01:57 2025 +0200

Fix time zone for 'cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob'
[PR119818]

This progresses:

PASS: cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob   -O0  (test for
excess errors)
[-FAIL:-]{+PASS:+} cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob  
-O0  execution test
[Etc.]

PR cobol/119818
gcc/testsuite/
* cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob:
'dg-set-target-env-var TZ UTC0'.

[Bug libfortran/119502] Runtime segfault when closing invalid unit

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #8 from Jerry DeLisle  ---
I think we can close this one.

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

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

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

--- Comment #15 from Jerry DeLisle  ---
Building with Steve's latest patch now. If all passes here I will commit to 16
and request to backport to 15.  Thanks Steve.

[Bug c++/119863] New: [modules] Bogus conflicting friend template declaration

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 119863
   Summary: [modules] Bogus conflicting friend template
declaration
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

$ cat Test.cpp 

export module m;

template
class T;

template
class U
{
  template
  friend class T;
};

template
class T
{
  U x = {};
};

export
template
T f(V) { return {}; }

$ cat main.cpp 

import m;

int main()
{
  auto const x = f(1);
}

$ ~/gcc-15/bin/g++ -fmodules -c Test.cpp -fmodule-only

$ ~/gcc-15/bin/g++ -fmodules main.cpp 
In module m, imported at main.cpp:2:
Test.cpp: In instantiation of ‘class U@m’:
Test.cpp:17:8:   required from ‘class T@m’
   17 |   U x = {};
  |^
main.cpp:6:19:   required from here
6 |   auto const x = f(1);
  |  ~^~~
Test.cpp:11:16: error: conflicting declaration of template ‘template
class T@m’
   11 |   friend class T;
  |^
Test.cpp:5:7: nota: previous declaration ‘template class T@m’
5 | class T;
  |   ^

$ ~/gcc-15/bin/g++ -v
Usando especificaciones internas.
COLLECT_GCC=/home/pililatiesa/gcc-15/bin/g++
COLLECT_LTO_WRAPPER=/home/pililatiesa/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Objetivo: x86_64-pc-linux-gnu
Configurado con: ../gcc-15.1.0-RC-20250418/configure --disable-multilib
--disable-bootstrap --enable-languages=c,c++ --prefix=/home/pililatiesa/gcc-15/
Modelo de hilos: posix
Algoritmos de compresión LTO admitidos: zlib zstd
gcc versión 15.0.1 20250418 (prerelease) (GCC)

[Bug target/119865] New: [15/16 regression] RISC-V: ICE in g++.target/riscv/mv(c)-symbols[1-5].C

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 119865
   Summary: [15/16 regression] RISC-V: ICE in
g++.target/riscv/mv(c)-symbols[1-5].C
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Created attachment 61154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61154&action=edit
freport-bug output

postcommit is seeing the following errors on rv32/64 linux targets:

FAIL: g++.target/riscv/mv-symbols1.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mv-symbols1.C (test for excess errors)
FAIL: g++.target/riscv/mv-symbols2.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mv-symbols2.C (test for excess errors)
FAIL: g++.target/riscv/mv-symbols3.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mv-symbols3.C (test for excess errors)
FAIL: g++.target/riscv/mv-symbols4.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mv-symbols4.C (test for excess errors)
FAIL: g++.target/riscv/mv-symbols5.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mv-symbols5.C (test for excess errors)
FAIL: g++.target/riscv/mvc-symbols1.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mvc-symbols1.C (test for excess errors)
FAIL: g++.target/riscv/mvc-symbols2.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mvc-symbols2.C (test for excess errors)
FAIL: g++.target/riscv/mvc-symbols3.C (internal compiler error: Aborted)
FAIL: g++.target/riscv/mvc-symbols3.C (test for excess errors)

https://github.com/patrick-rivos/gcc-postcommit-ci/issues/2986

Likely caused by r15-9564-g2d6f1ca17f2

command/backtrace
$
/scratch/ewlu/ci/triage/baseline/build-mv-symbols-ice/build-gcc-linux-stage2/gcc/testsuite/g++/../../xg++
-B/scratch/ewlu/ci/triage/baseline/build-mv-symbols-ice/build-gcc-linux-stage2/gcc/testsuite/g++/../../

/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/g++.target/riscv/mv-symbols1.C
 -march=rv64gcv -mabi=lp64d -mcmodel=medlow   -fdiagnostics-plain-output 
-nostdinc++
-I/scratch/ewlu/ci/triage/baseline/build-mv-symbols-ice/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/lib64/lp64d/libstdc++-v3/include/riscv64-unknown-linux-gnu
-I/scratch/ewlu/ci/triage/baseline/build-mv-symbols-ice/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/lib64/lp64d/libstdc++-v3/include
-I/scratch/ewlu/ci/triage/baseline/gcc/libstdc++-v3/libsupc++
-I/scratch/ewlu/ci/triage/baseline/gcc/libstdc++-v3/include/backward
-I/scratch/ewlu/ci/triage/baseline/gcc/libstdc++-v3/testsuite/util
-fmessage-length=0 -O0 -march=rv64gc -mabi=lp64 -ffat-lto-objects -fno-ident 
-S   -o mv-symbols1.s -freport-bug
munmap_chunk(): invalid pointer
/scratch/ewlu/ci/triage/baseline/gcc/gcc/testsuite/g++.target/riscv/mv-symbols1.C:11:10:
internal compiler error: Aborted
0x33f89d6 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:517
0x1796333 crash_signal
../../../gcc/gcc/toplev.cc:322
0x76a32d44532f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x76a32d49eb2c __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x76a32d49eb2c __pthread_kill_internal
./nptl/pthread_kill.c:78
0x76a32d49eb2c __GI___pthread_kill
./nptl/pthread_kill.c:89
0x76a32d44527d __GI_raise
../sysdeps/posix/raise.c:26
0x76a32d4288fe __GI_abort
./stdlib/abort.c:79
0x76a32d4297b5 __libc_message_impl
../sysdeps/posix/libc_fatal.c:134
0x76a32d4a8ff4 malloc_printerr
./malloc/malloc.c:5772
0x76a32d4a947b munmap_chunk
./malloc/malloc.c:3040
0x76a32d4addf9 __GI___libc_free
./malloc/malloc.c:3388
0x1bccb4f parse_features_for_version
../../../gcc/gcc/config/riscv/riscv.cc:13140
0x1bccc2e riscv_compare_version_priority(tree_node*, tree_node*)
../../../gcc/gcc/config/riscv/riscv.cc:13196
0x1bccc2e riscv_common_function_versions(tree_node*, tree_node*)
../../../gcc/gcc/config/riscv/riscv.cc:13213
0x1bccc2e riscv_common_function_versions(tree_node*, tree_node*)
../../../gcc/gcc/config/riscv/riscv.cc:13207
0xec02a7 decls_match(tree_node*, tree_node*, bool)
../../../gcc/gcc/cp/decl.cc:1216
0xec0f29 duplicate_decls(tree_node*, tree_node*, bool, bool)
../../../gcc/gcc/cp/decl.cc:1683
0xfa0c18 pushdecl(tree_node*, bool)
../../../gcc/gcc/cp/name-lookup.cc:3981
0xebd803 start_preparsed_function(tree_node*, tree_node*, int)
../../../gcc/gcc/cp/decl.cc:18548
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/119867] New: Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

[yyc1992 at gmail dot com via Gcc-bugs]

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

Bug ID: 119867
   Summary: Spurious warning about out-of-bound write with -O3 and
-D_GLIBCXX_ASSERTIONS
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

The following code, when compiled on arm (32bit) or aarch64 with `-O3
-D_GLIBCXX_ASSERTIONS` produces a warning for out of bound write.

```
: In function 'auto f(unsigned int, unsigned int)':
:7:16: warning: writing 16 bytes into a region of size 1
[-Wstringop-overflow=]
7 | res[i] = 1;
:3:1: note: at offset [32, 33] into destination object ''result_decl'
not supported by dump_expr' of size 33
3 | auto f(unsigned idx1, unsigned idx2)
  | ^~~~
Compiler returned: 0
```

```
#include 

auto f(unsigned idx1, unsigned idx2)
{
std::array res;
for (unsigned i = idx1 + 1; i < idx2; i++)
res[i] = 1;
return res;
}
```

Testing on compiler explorer suggests that this affect at least all gcc
versions >=14 up to trunk but seems to not affect non-arm architectures. The
code above could of course produce out of bound write but I don't think the
compiler is in the business of warning me about this and it also does not seem
to be what the warning is about. FWIW, directly writing `res[idx1] = 0` or
`res[idx2] = 0` does not produce a warning and adding a `i < 33` in the loop
condition also seems to suppress the warning. This makes me think the bug isn't
in libstdc++ but in the compiler vectorizes the loop with the wrong bound or
sth

[Bug c++/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

[yyc1992 at gmail dot com via Gcc-bugs]

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

Yichao Yu  changed:

   What|Removed |Added

 Blocks|88443   |
  Component|tree-optimization   |c++
   Keywords|diagnostic  |

--- Comment #1 from Yichao Yu  ---
As a meta bug, should the ''result_decl' not supported by dump_expr' in the error message be reported anywhere? Both the fact that it
couldn't print and that it uses the return type declaration rather than the
declaration of the returned variable


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #14 from kargls at comcast dot net ---
Created attachment 61157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61157&action=edit
Patch to fix issue

Here are Changelog entries for fortran/ and testsuite/.

2025-04-18  Steven G. Kargl  

PR fortran/119836
* resolve.cc(check_pure_function, pure_subroutine): Fix checking for
an impure subprogram within a DO CONCURRENT construct.


2025-04-18  Steven G. Kargl  

PR fortran/119836
* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: Ditto.
* gfortran.dg/pr119836_3.f90: Ditto.
* gfortran.dg/pr119836_4.f90: Ditto.

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||88443

--- Comment #2 from Andrew Pinski  ---
So with _GLIBCXX_ASSERTIONS, there is a check that is added to oeprator[]. that
the `index <= size` as `&res[size]` is well defined. So what happens is the
vectorizer vectorizes up to and including 33 as the index. And that write is
still there which does show an undefinedness in the original code really.

If we add a check to make sure idx2 is within the range of the length of the
array before the loop, then we (correctly) get memset for the loop.

I am not 100% sure we can call this a false positive since the compiler has no
knowledge of the ranges of idx1 and idx2 here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

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

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

--- Comment #3 from Andrew Pinski  ---
There might be another dup of this bug too ...

[Bug libstdc++/119840] FAIL: g++.old-deja/g++.robertl/eb73.C -std=gnu++26 (test for excess errors)

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Yes.

[Bug tree-optimization/119858] [15/16 Regression] GCN vs. "middle-end: Fix incorrect codegen with PFA and VLS [PR119351]"

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug middle-end/108016] RISC-V：Bad codegen in scalar code comparing to LLVM

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

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

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

https://gcc.gnu.org/g:529a43109fcd93f5aafda345da14679f538ada86

commit r16-17-g529a43109fcd93f5aafda345da14679f538ada86
Author: Alexey Merzlyakov 
Date:   Fri Apr 18 06:45:10 2025 -0600

[PATCH] [RISC-V] Tune for removal unnecessary sext in builtin overflows
[PR108016]

It fixes one of the PR108016 mis-optimization.

The patch adjusts expanding for __builtin_add/sub_overflow() on RV64
targets
to avoid unnecessary sext.w instructions.

It replaces expanded for ADD/SUB_OVERFLOW code:
  r141:SI=r139:DI#0+r140:DI#0 .. r143:DI=sign_extend(r141:SI)
to the followong kind of chain ->
  r143:DI=sign_extend(r139:DI#0+r140:DI#0) .. r141:SI=r143:DI#0
so that sign_extend(a:SI+b:SI) to be emitted as addw (or subw) instruction,
while output r141:SI register will be placed at the end of chain without
extra dependencies, and thus could be easily optimized-out by further
pipeline.

PR middle-end/108016
gcc/ChangeLog:

* config/riscv/riscv.md (addv4, uaddv4, subv4,
usubv4): Tunes for unnecessary sext.w elimination.

PR middle-end/108016
gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr108016.c: New test.

[Bug tree-optimization/119351] [14 Regression] Incorrect forall masking for AND reduction in early break

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

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

Bug 119858 Summary: [15/16 Regression] GCN vs. "middle-end: Fix incorrect 
codegen with PFA and VLS [PR119351]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119858

   What|Removed |Added

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

[Bug tree-optimization/119858] [15/16 Regression] GCN vs. "middle-end: Fix incorrect codegen with PFA and VLS [PR119351]"

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/119860] New: needless vector unrolling causes less profitable vectorization

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

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

Bug ID: 119860
   Summary: needless vector unrolling causes less profitable
vectorization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
  Target Milestone: ---

consider the following loop:

#define N 512
#define END 505

long long x[N] __attribute__((aligned(32)));

int __attribute__((noipa))
foo (void)
{
  for (unsigned int i = 0; i < END; ++i)
{
  if (x[i] > 0)
return 1;
}
  return -1;
}

When vectorized produces with -O3 -march=armv8-a:

.L2:
add v29.4s, v29.4s, v26.4s
add v28.4s, v28.4s, v27.4s
cmp x1, x0
beq .L15
.L4:
ldp q31, q30, [x0], 32
cmgtv31.2d, v31.2d, #0
cmgtv30.2d, v30.2d, #0
orr v31.16b, v31.16b, v30.16b
umaxp   v31.4s, v31.4s, v31.4s
fmovx3, d31
cbz x3, .L2

which is suboptimal, due to the forcing of an 2x unroll factor.

This happens because the SLP tree rooted in the if with the vector IV works on
a smaller type than the rest of the loop.

The vectorizer enforces datasize rather than VF over the different SLP
instances and so we end up with V2DI vs V4SI and so the V2DI needs to be
unrolled.

I could have chosen V2DI and V2SI.

The unroll factor ends up making early break less profitable depending on the
loop size and also prevents further optimizations.

Perhaps we should try to enforce VF rather that total vector size first?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115130
[Bug 115130] [meta-bug] early break vectorization

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Yichao Yu from comment #5)
> Yeah adding explicit bounds check do work but I still don't think the
> compiler should be warning about this type of possible out-of-bound access.


The problem is more complex since the bounds check that is added for
std::array[] allows for the one past the last element (since that is valid for
an address). And with that extra information, GCC's vectorizer is getting
confused due to that too.

[Bug middle-end/80328] With -ffloat-store std::array operator[] no longer cost-free

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |13.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=14708
 Resolution|--- |FIXED

--- Comment #5 from Andrew Pinski  ---
-fexcess-precision= is an option for C++ since GCC 13
(r13-3290-g98e341130f8798).

Also -ffloat-store documentation (because of PR 14708) now mentions
-fexcess-precision=.

Closing as fixed for GCC 13.

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

[yyc1992 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Yichao Yu  ---
Yeah adding explicit bounds check do work but I still don't think the compiler
should be warning about this type of possible out-of-bound access.

FWIW, this code originate from a bigger project where the bounds check is
performed at a much higher level in a different compilation unit that the
compiler can't possibly see and in general I believe it's common for C/C++ code
to provide (especially internal) unsafe API. The OOB warning from compiler
should apply to cases where the compiler can see the input value (and it has
been really helpful in many cases) but not in all cases where a OOB access
"could" happen due to lack of information

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Yichao Yu from comment #1)
> As a meta bug, should the ''result_decl' not supported by
> dump_expr' in the error message be reported anywhere? Both
> the fact that it couldn't print and that it uses the return type declaration
> rather than the declaration of the returned variable

As for the result_decl issue, I will file a different bug for that one.

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

[yyc1992 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Yichao Yu  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Yichao Yu from comment #1)
> > As a meta bug, should the ''result_decl' not supported by
> > dump_expr' in the error message be reported anywhere? Both
> > the fact that it couldn't print and that it uses the return type declaration
> > rather than the declaration of the returned variable
> 
> As for the result_decl issue, I will file a different bug for that one.

Thanks!

[Bug tree-optimization/119868] New: `'result_decl' not supported by dump_expr` is printed instead of ` res` in some cases

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

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

Bug ID: 119868
   Summary: `'result_decl' not supported by dump_expr` is printed instead of ` res` in
some cases
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#include 

auto f(unsigned idx1, unsigned idx2)
{
std::array res;
__builtin_strcpy(res.data(), "1234567890123456789012345678901234567890");
return res;
}



auto f1(unsigned idx1, unsigned idx2)
{
std::array res;
for (unsigned i = idx1 + 1; i < idx2; i++)
res[i] = 1;
return res;
}
```

Compile with `-O3 -D_GLIBCXX_ASSERTIONS` (and `-mavx2` on x86_64 to get early
exit vectorization).

We get:
```
: In function 'auto f()':
:6:21: warning: 'void* __builtin_memcpy(void*, const void*, long
unsigned int)' forming offset [33, 40] is out of the bounds [0, 33] of object
' res' with type 'std::array' [-Warray-bounds=]
6 | __builtin_strcpy(res.data(),
"1234567890123456789012345678901234567890");
  |
^~~~
:3:1: note: ' res' declared here
3 | auto f()
  | ^~~~
: In function 'auto f1(unsigned int, unsigned int)':
:16:16: warning: writing 32 bytes into a region of size 1
[-Wstringop-overflow=]
   16 | res[i] = 1;
:12:1: note: at offset [32, 33] into destination object ''result_decl'
not supported by dump_expr' of size 33
   12 | auto f1(unsigned idx1, unsigned idx2)
  | ^~~~
```

Notice how in the first Warray-bounds warnings we get ' res'
while in the second case we get 'result_decl' not supported by
dump_expr.

[Bug tree-optimization/119867] Spurious warning about out-of-bound write with -O3 and -D_GLIBCXX_ASSERTIONS

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Yichao Yu from comment #1)
> > As a meta bug, should the ''result_decl' not supported by
> > dump_expr' in the error message be reported anywhere? Both
> > the fact that it couldn't print and that it uses the return type declaration
> > rather than the declaration of the returned variable
> 
> As for the result_decl issue, I will file a different bug for that one.

Filed as PR 119868 as sometimes we print something decent.

[Bug c++/119859] New: [15 Regression?] template member function overload with base class

[Laurent.Rineau__gcc at normalesup dot org via Gcc-bugs]

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

Bug ID: 119859
   Summary: [15 Regression?] template member function overload
with base class
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Laurent.Rineau__gcc at normalesup dot org
  Target Milestone: ---

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

The attached source code compiled with g++-14.2.0 but not with g++-15. See also
on Godbolt: https://godbolt.org/z/W1f9xYE6s

The error message is an ambiguity:

: In function 'int main()':
:12:11: error: call of overloaded 'f()' is ambiguous
   12 |   b.f();
  |   ^~
:12:11: note: there are 2 candidates
:2:33: note: candidate 1: 'const A& A::f() const [with T = int]'
2 |   template const A& f() const { return *this; }
  | ^
:7:33: note: candidate 2: 'const B& B::f() const [with T = int]'
7 |   template const B& f() const { return *this; }
  | ^
Compiler returned: 1


Actually, I am not completely sure that is a regression. According to
https://eel.is/c++draft/namespace.udecl#12:

> For the purpose of forming a set of candidates during overload resolution, 
> the functions named by a using-declaration in a derived class are treated as 
> though they were direct members of the derived class.
In particular, the implicit object parameter is treated as if it were a
reference to the derived class rather than to the base class
([over.match.funcs]).

So the function templates only differ by their return types.

[Bug c++/119864] New: [modules] ICE -fmodules and omp reduction of UDT

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 119864
   Summary: [modules] ICE -fmodules and omp reduction of UDT
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

$ cat p1.cpp 

export module p1;

export
template
struct T
{
  double d;

  T &operator +=(T const &x) { d += x.d; return *this; }
};

export
template
T sum(T const *p, unsigned N)
{
T Sum = {};

#pragma omp declare reduction(Op: T: omp_out += omp_in) initializer(omp_priv
= {})
#pragma omp parallel for reduction(Op: Sum)
for (unsigned i = 0u; i < N; ++i)
  {
  Sum += *p;
  ++p;
  }
return Sum;
}

$ ~/gcc-15/bin/g++ -std=c++20 -fmodules -fopenmp -c p1.cpp -fmodule-only

$ cat main.cpp 

import p1;

int main()
{
  T<1u> v[3u] = {};

  T s = sum(v, 3u);

}

$ ~/gcc-15/bin/g++ -std=c++20 -fmodules -fopenmp -freport-bug -c main.cpp 
main.cpp: In function ‘void omp declare reduction Op(T@p1&)’:
main.cpp:8:9: error interno del compilador: Violación de segmento
8 |   T s = sum(v, 3u);
  | ^~~
0x22373d6 internal_error(char const*, ...)
    ../../gcc-15.1.0-RC-20250418/gcc/diagnostic-global-context.cc:517
0xf8a223 crash_signal
    ../../gcc-15.1.0-RC-20250418/gcc/toplev.cc:322
0x77463624532f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xf7b946 relayout_decl(tree_node*)
    ../../gcc-15.1.0-RC-20250418/gcc/stor-layout.cc:854
0xc1caee allocate_struct_function(tree_node*, bool)
    ../../gcc-15.1.0-RC-20250418/gcc/function.cc:4882
0x8a6c87 module_state::read_cluster(unsigned int)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/module.cc:16705
0x8a739d module_state::load_section(unsigned int, binding_slot*)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/module.cc:20217
0x8a754e lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/module.cc:21100
0x8ba57d name_lookup::search_namespace_only(tree_node*)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/name-lookup.cc:929
0x8bbbf3 name_lookup::search_unqualified(tree_node*, cp_binding_level*)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/name-lookup.cc:1159
0x8bdcae lookup_name(tree_node*, LOOK_where, LOOK_want)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/name-lookup.cc:8121
0x8cd182 lookup_name(tree_node*, LOOK_want)
    ../../gcc-15.1.0-RC-20250418/gcc/cp/name-lookup.h:410
0x8cd182 cp_parser_lookup_name
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:32997
0x90f17a cp_parser_class_name
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:27374
0x90f49c cp_parser_type_name
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:21464
0x90487e cp_parser_simple_type_specifier
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:21157
0x9064ac cp_parser_postfix_expression
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:8158
0x902ec8 cp_parser_unary_expression
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:9733
0x8d726a cp_parser_cast_expression
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:10648
0x8d807b cp_parser_binary_expression
    ../../gcc-15.1.0-RC-20250418/gcc/cp/parser.cc:10751
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
Véase <https://gcc.gnu.org/bugs/> para instrucciones.


$ cat /tmp/ccKxMTkW.out 
// Objetivo: x86_64-pc-linux-gnu
// Configurado con: ../gcc-15.1.0-RC-20250418/configure --disable-multilib
--disable-bootstrap --enable-languages=c++ --prefix=/home/pililatiesa/gcc-15/
// Modelo de hilos: posix
// Algoritmos de compresión LTO admitidos: zlib zstd
// gcc versión 15.0.1 20250418 (prerelease) (GCC) 
// 
// main.cpp: In function ‘void omp declare reduction Op(T@p1&)’:
// main.cpp:8:9: error interno del compilador: Violación de segmento
// 8 |   T s = sum(v, 3u);
//   | ^~~
// 0x22373d6 internal_error(char const*, ...)
//      ../../gcc-15.1.0-RC-20250418/gcc/diagnostic-global-context.cc:517
// 0xf8a223 crash_signal
//      ../../gcc-15.1.0-RC-20250418/gcc/toplev.cc:322
// 0x77a4532f ???
//  ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
// 0xf7b946 relayout_decl(tree_node*)
//      ../../gcc-15.1.0-RC-20250418/gcc/stor-layout.cc:854
// 0xc1caee allocate_struct_function(tree_node*, bool)
//      ../../gcc-15.1.0-RC-20250418/gcc/function.cc:4882
// 0x8a6c87 module_state::read_cluster(unsigned int)
//      ../../gcc-15.1.0-RC-20250418/gcc/cp/module.cc:16705
// 0x8a739d module_state::load_section(unsigned int, binding_slot*)
//      ../../gcc-15.1.0-RC-20250418/gcc/cp/module.cc:20217
// 0x8a754e lazy_load_binding(unsigned int, tree_node*, tree_node*,
binding_slot*)
//      ../../gcc-15.1.0-RC-20250418/gcc/cp/module.cc:21100
// 0x8ba57d name_lookup::

[Bug tree-optimization/83022] [12/13/14/15/16 Regression] malloc & memset -> calloc is not always an optimization

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

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

--- Comment #18 from Andrew Pinski  ---
Created attachment 61156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61156&action=edit
Full patch which I will be submitting once testing is finished

It does not do the probability but does handle the post domination instead
which allows for just enough and rejects the ones which were problemantic to
begin with.

[Bug fortran/119836] [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r16-32-gf9ea46d946887a05d7ecbca5aeeb99fd868f6e70
Author: Steven G. Kargl 
Date:   Fri Apr 18 18:05:10 2025 -0700

Fortran: Fix checking for IMPURE in DO CONCURRENT.

PR fortran/119836

gcc/fortran/ChangeLog:

* resolve.cc (check_pure_function): Fix checking for
an impure subprogram within a DO CONCURRENT construct.
(pure_subroutine): Ditto.

gcc/testsuite/ChangeLog:

* gfortran.dg/do_concurrent_all_clauses.f90: Remove invalid
dg-error test.
* gfortran.dg/pr119836_1.f90: New test.
* gfortran.dg/pr119836_2.f90: New test.
* gfortran.dg/pr119836_3.f90: New test.
* gfortran.dg/pr119836_4.f90: New test.

[Bug c++/119863] [15/16 Regression][modules] Bogus conflicting friend template declaration

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|[modules] Bogus conflicting |[15/16 Regression][modules]
   |friend template declaration |Bogus conflicting friend
   ||template declaration
 CC||nshead at gcc dot gnu.org
   Last reconfirmed||2025-04-19

--- Comment #1 from Nathaniel Shead  ---
Confirmed.  We should find this in 'lookup_imported_hidden_friend' when doing
'tsubst_friend_class' but we currently do not, because the template is not
registered on the current module lookup since it's not considered an
uninstantiated friend.

This worked in GCC 14; looks like perhaps because we just didn't check for
conflicting decls at the time?

[Bug c++/119863] [15/16 Regression][modules] Bogus conflicting friend template declaration

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #2 from Nathaniel Shead  ---
Created attachment 61158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61158&action=edit
pr119863.patch

The attached patch fixes the bug for me, but I'm not super happy with it; there
might be a neater way to handle friend classes.

[Bug driver/110522] `-fdiagnostics-format=sarif-file`: file name conflicts / races

[lebedev.ri at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Roman Lebedev  ---
Somewhat relevant: i've looked into feeding such compiler SARIF's
into already-existing Github SARIF upload tooling, and it almost works,
consider upvoting: https://github.com/orgs/community/discussions/157136

[Bug tree-optimization/83022] [12/13/14/15/16 Regression] malloc & memset -> calloc is not always an optimization

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

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

--- Comment #19 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681439.html

[Bug c/44677] Warn for variables incremented but not used (+=, ++)

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #19 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #18)
> *** Bug 119544 has been marked as a duplicate of this bug. ***

The example in this bug was

extern char* str;

void foo(void)
{
int i = 0;

while (*str == ' ' || *str == '\t' || *str == '\n' || *str == '\r')
{
i++;
str++;
}
}

However, the i++ is not completely useless, as this is a way to tell the
compiler that the number of iterations is bounded by INT_MAX (perhaps not very
useful here, but there may be cases where this kind of information could be
used for optimization, e.g. loop unrolling -- there does not seem to be a
standard way to give such information).

[Bug c/47781] warnings from custom printf format specifiers

[lukeshu at lukeshu dot com via Gcc-bugs]

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

Luke Shumaker  changed:

   What|Removed |Added

 CC||lukeshu at lukeshu dot com

--- Comment #31 from Luke Shumaker  ---
Prior art for consideration: Plan 9

Similar to GNU libc's register_printf_specifier() and
register_printf_modifier(), Plan 9 libc has fmtinstall() which can add new
specifiers and modifiers; and to support checking these strings, the compiler
supports `#pragma varargck`:

fmtinstall('C', CONVFUNC)/* since 1e (1992); if CONVFUNC returns 0
then 'C' is a specifier, if it returns 1 it's a modifier */
#pragma varargck argpos FUNC POS /* since 3e (2000); equivalent to putting
`[[gnu::format(printf, POS, POS+1)]]` on FUNC
#pragma varargck flag 'C'/* since 3e (2000); says that 'C' is a
modifier, consumes 0 arguments */
#pragma varargck type "C" TYPE   /* since 4e (2002); says that 'C' is a
specifier, consumes 1 argument of type TYPE */

fmtinstall()ed modifiers and specifiers can consume any number of arguments,
but `#pragma varargck` only supports indicating that they consume 0 and 1
arguments respectively.  Note that Plan 9 printf does not support POSIX-style
position-specifiers; arguments may only be consumed in order.

https://man.cat-v.org/plan_9/1/8c (8c is the x86 compiler)
https://man.cat-v.org/plan_9/2/fmtinstall

[Bug target/119865] [15/16 regression] RISC-V: ICE in g++.target/riscv/mv(c)-symbols[1-5].C

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   See Also||https://github.com/patrick-
   ||rivos/gcc-postcommit-ci/iss
   ||ues/2986

[Bug target/119865] [15/16 regression] RISC-V: ICE in g++.target/riscv/mv(c)-symbols[1-5].C

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Sam James  ---
For 15, maybe it should just be reverted as Jeff mentioned in his review that
it was likely latent before.

[Bug rtl-optimization/119160] wrong code with -O2 -finstrument-functions-once -favoid-store-forwarding -fnon-call-exceptions -fschedule-insns -mgeneral-regs-only

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
  Known to work||16.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug middle-end/119507] only the comdat functions before normal functions get their own gcc_except_table section (unless using -ffunction-sections)

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from Sam James  ---
(In reply to chenglulu from comment #6)
> Ping?

Submitted as
https://inbox.sourceware.org/gcc-patches/20250329045722.71851-1-quic_apin...@quicinc.com/,
just needs review. Andrew pinged it just now.

[Bug target/119869] New: copysign(0, x) code could be better

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

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

Bug ID: 119869
   Summary: copysign(0, x) code could be better
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
double native1(double x) {
return __builtin_copysign(0, x);
}
```

Currently GCC produces:
```
moviv30.4s, 0
movid31, #0
fnegv30.2d, v30.2d
bif v0.8b, v31.8b, v30.8b
ret
```

But the movi/bfi could be merged just into an and.

Like:
```
movid1, #
fnegd1, d1
and v0.8b, v0.8b, v1.8b
ret
```

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

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

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

--- Comment #19 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:7381ea8fc4d6dc12af287c20caa3b2019b2f6567

commit r14-11653-g7381ea8fc4d6dc12af287c20caa3b2019b2f6567
Author: Jakub Jelinek 
Date:   Tue Apr 1 16:40:55 2025 +0200

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

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

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

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

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

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

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

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

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

[Bug c/119582] ICE in gimplify_expr, at gimplify.cc:18708 with -fsanitize=pointer-subtract

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11654-gc0946fe4d216829e96bf2cd64faf5e4630dd8cc2
Author: Jakub Jelinek 
Date:   Wed Apr 2 19:28:20 2025 +0200

c: Fix ICEs with -fsanitize=pointer-{subtract,compare} [PR119582]

The following testcase ICEs because c_fully_fold isn't performed on the
arguments of __sanitizer_ptr_{sub,cmp} builtins and so e.g.
C_MAYBE_CONST_EXPR can leak into the gimplifier where it ICEs.

2025-04-02  Jakub Jelinek  

PR c/119582
* c-typeck.cc (pointer_diff, build_binary_op): Call c_fully_fold on
__sanitizer_ptr_sub or __sanitizer_ptr_cmp arguments.

* gcc.dg/asan/pr119582.c: New test.

(cherry picked from commit 29bc904cb827615ed9f36bc3742ccc4ac77515ec)

[Bug libgcc/101075] libatomic's libat_lock_n can deadlock from inconsistent locking order

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11663-g50bd360f9270e6656368a5bdf9426b4022780609
Author: Jakub Jelinek 
Date:   Wed Apr 16 17:21:39 2025 +0200

libatomic: Fix up libat_{,un}lock_n [PR119796]

As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
   acquired always in the order from addr_hash (ptr) up to
   locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
   so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
   case at pointer starting at page boundary and in another case at
   page boundary + 2048 bytes, the first thread can lock the first
   32 mutexes, the second thread can lock the last 32 mutexes and
   then first thread wait for the lock 32 held by second thread and
   second thread wait for the lock 0 held by the first thread;
   fixed below by always locking the locks in order of increasing
   index, if there is a wrap-around, by locking in 2 loops, first
   locking some locks at the start of the array and second at the
   end of it
2) the number of locks seems to be determined solely depending on the
   n value, I think that is wrong, we don't know the structure alignment
   on the libatomic side, it could very well be 1 byte aligned struct,
   and so how many cachelines are actually (partly or fully) occupied
   by the atomic access depends not just on the size, but also on
   ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
   should IMHO lock 2 locks because it occupies the first and second
   cacheline

Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.

2025-04-16  Jakub Jelinek  

PR libgcc/101075
PR libgcc/119796
* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE).  If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.

(cherry picked from commit 61dfb0747afcece3b7a690807b83b366ff34f329)

[Bug tree-optimization/119722] wrong code with _BitInt(), __builtin_stdc_rotate_left() at -O2 -fno-tree-forwprop -fno-tree-copy-prop -fno-tree-fre

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:056a01f9fa85c584ed97533e75b50160d5993613

commit r14-11658-g056a01f9fa85c584ed97533e75b50160d5993613
Author: Jakub Jelinek 
Date:   Sat Apr 12 13:13:53 2025 +0200

bitintlower: Fix up handling of SSA_NAME copies in coalescing [PR119722]

The following patch is miscompiled, because during the limited
SSA name coalescing the bitintlower pass does we incorrectly don't
register a conflict.
This is on
   [local count: 1073741824]:
  # b_17 = PHI 
  g.4_13 = g;
  _14 = g.4_13 >> 50;
  _15 = (unsigned int) _14;
  _21 = b_17;
  _16 = (unsigned int) _21;
  s_22 = _15 + _16;
  return s_22;
basic block where in the map->bitint bitmap we track 14, 17 and 19.
The build_bitint_stmt_ssa_conflicts "hook" has special code where
it tracks uses at the final statements of mergeable operations, so
e.g. the
  _16 = (unsigned int) _21;
statement is considered to be use of b_17 because _21 is not in
map->bitmap (or large_huge.m_names), i.e. is mergeable.
The problem is that build_ssa_conflict_graph has special code to handle
SSA_NAME copies and _21 = b_17; is gimple_assign_copy_p.  In such cases
it calls live_track_clear_var on the rhs1.  The problem is that
on the above bb, after we note in the _16 = (unsigned int) _21;
stmt we need b_17 the generic code makes us forget that because
of the copy statement, and then build_bitint_stmt_ssa_conflicts
ignores it completely (because _21 is large/huge bitint and is
not in map->bitint, so assumed to be handled by a later stmt in the
bb, for backwards walk like this before this one).
As the b_17 use is ignored, the coalescing thinks it can put
all of b_17, b_19 and _14 into the same partition, which is wrong,
while we can and should coalesce b_17 and b_19, _14 needs to be a different
temporary because b_17 is set before and used after _14 has been written.

The following patch fixes it by handling gimple_assign_copy_p in two
separate spots, move the generic coalesce handling of it after
build_ssa_conflict_graph (where build_ssa_conflict_graph handling
doesn't fall through to that, it does continue after the call) and
inside of build_ssa_conflict_graph it performs it too, but only if
the lhs is not mergeable large/huge bitint.

2025-04-12  Jakub Jelinek  

PR tree-optimization/119722
* gimple-lower-bitint.h (build_bitint_stmt_ssa_conflicts): Add
CLEAR argument.
* gimple-lower-bitint.cc (build_bitint_stmt_ssa_conflicts): Add
CLEAR argument.  Call clear on gimple_assign_copy_p rhs1 if lhs
is large/huge bitint unless lhs is not in names.
* tree-ssa-coalesce.cc (build_ssa_conflict_graph): Adjust
build_bitint_stmt_ssa_conflicts caller.  Move gimple_assign_copy_p
handling to after the build_bitint_stmt_ssa_conflicts call.

(cherry picked from commit 3f9dfb94eab1ab1bbf9a2b5e20d1f61e36516063)

[Bug middle-end/119808] wrong code with _BitInt() and -ftree-coalesce-vars -fstack-protector-strong

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:40c50659569f9d50db9108a5a9847518a5bcec66

commit r14-11662-g40c50659569f9d50db9108a5a9847518a5bcec66
Author: Jakub Jelinek 
Date:   Wed Apr 16 09:11:06 2025 +0200

bitintlower: Fix interaction of gimple_assign_copy_p stmts vs.
has_single_use [PR119808]

The following testcase is miscompiled, because we emit a CLOBBER in a place
where it shouldn't be emitted.
Before lowering we have:
  b_5 = 0;
  b.0_6 = b_5;
  b.1_1 = (unsigned _BitInt(129)) b.0_6;
...
   = b_5;
The bitint coalescing assigns the same partition/underlying variable
for both b_5 and b.0_6 (possible because there is a copy assignment)
and of course a different one for b.1_1 (and other SSA_NAMEs in between).
This is -O0 so stmts aren't DCEd and aren't propagated that much etc.
It is -O0 so we also don't try to optimize and omit some names from m_names
and handle multiple stmts at once, so the expansion emits essentially
  bitint.4 = {};
  bitint.4 = bitint.4;
  bitint.2 = cast of bitint.4;
  bitint.4 = CLOBBER;
...
   = bitint.4;
and the CLOBBER is the problem because bitint.4 is still live afterwards.
We emit the clobbers to improve code generation, but do it only for
(initially) has_single_use SSA_NAMEs (remembered in m_single_use_names)
being used, if they don't have the same partition on the lhs and a few
other conditions.
The problem above is that b.0_6 which is used in the cast has_single_use
and so was in m_single_use_names bitmask and the lhs in that case is
bitint.2, so a different partition.  But there is gimple_assign_copy_p
with SSA_NAME rhs1 and the partitioning special cases those and while
b.0_6 is single use, b_5 has multiple uses.  I believe this ought to be
a problem solely in the case of such copy stmts and its special case
by the partitioning, if instead of b.0_6 = b_5; there would be
b.0_6 = b_5 + 1; or whatever other stmts that performs or may perform
changes on the value, partitioning couldn't assign the same partition
to b.0_6 and b_5 if b_5 is used later, it couldn't have two different
(or potentially different) values in the same bitint.N var.  With
copy that is possible though.

So the following patch fixes it by being more careful when we set
m_single_use_names, don't set it if it is a has_single_use SSA_NAME
but SSA_NAME_DEF_STMT of it is a copy stmt with SSA_NAME rhs1 and that
rhs1 doesn't have single use, or has_single_use but SSA_NAME_DEF_STMT of it
is a copy stmt etc.

Just to make sure it doesn't change code generation too much, I've gathered
statistics how many times
  if (m_first
  && m_single_use_names
  && m_vars[p] != m_lhs
  && m_after_stmt
  && bitmap_bit_p (m_single_use_names, SSA_NAME_VERSION (op)))
{
  tree clobber = build_clobber (TREE_TYPE (m_vars[p]),
CLOBBER_STORAGE_END);
  g = gimple_build_assign (m_vars[p], clobber);
  gimple_stmt_iterator gsi = gsi_for_stmt (m_after_stmt);
  gsi_insert_after (&gsi, g, GSI_SAME_STMT);
}
emits a clobber on
make check-gcc GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="--target_board=unix\{-m64,-m32\} GCC_TEST_RUN_EXPENSIVE=1
dg.exp='*bitint* pr112673.c builtin-stdc-bit-*.c pr112566-2.c pr112511.c
pr116588.c pr116003.c pr113693.c pr113602.c flex-array-counted-by-7.c'
dg-torture.exp='*bitint* pr116480-2.c pr114312.c pr114121.c' dfp.exp=*bitint*
i386.exp='pr118017.c pr117946.c apx-ndd-x32-2a.c'
vect.exp='vect-early-break_99-pr113287.c' tree-ssa.exp=pr113735.c"
and before this patch it was 41010 clobbers and after it is 40968,
so difference is 42 clobbers, 0.1% fewer.

2025-04-16  Jakub Jelinek  

PR middle-end/119808
* gimple-lower-bitint.cc (gimple_lower_bitint): Don't set
m_single_use_names bits for SSA_NAMEs which have single use but
their SSA_NAME_DEF_STMT is a copy from another SSA_NAME which
doesn't
have a single use, or single use which is such a copy etc.

(cherry picked from commit 5a48e7732d6aa0aaf12b508fa640125e6c4d14b9)

[Bug tree-optimization/119707] wrong code with _BitInt() mask and shift at -O1

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

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

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

https://gcc.gnu.org/g:008ba21711a4aef3b6d6e7d3dbbe2f2265e29ff8

commit r14-11657-g008ba21711a4aef3b6d6e7d3dbbe2f2265e29ff8
Author: Jakub Jelinek 
Date:   Fri Apr 11 08:27:55 2025 +0200

bitintlower: Fix up handling of nested casts in m_upward_2limbs cases
[PR119707]

The following testcase is miscompiled I believe starting with
PR112941 r14-6742.  That commit fixed the bitint-55.c testcase.
The m_first initialization for such conversion initializes 2 SSA_NAMEs,
one is PHI result on the loop (m_data[save_data_cnt]) and the other
(m_data[save_data_cnt+1]) is the argument of that PHI from the latch
edge initialized somewhere in the loop.  Both of these are used to
propagate sign extension (i.e. either 0 or all ones limb) from the
iteration with the sign bit of a narrower type to following iterations.
The bitint-55.c testcase was ICEing with invalid SSA forms as it was
using unconditionally the PHI argument SSA_NAME even in places which
weren't dominated by that.  And the code which was touched is about
handling constant idx, so if e.g. there are nested casts and the
outer one does conditional code based on index comparison with
a particular constant index.
In the following testcase there are 2 nested casts, one from signed
_BitInt(129) to unsigned _BitInt(255) and the outer from unsigned
_BitInt(255) to unsigned _BitInt(256).  The m_upward_2limbs case which
is used for handling mergeable arithmetics (like +-|&^ and casts etc.)
one loop iteration handles 2 limbs, the first half the even ones, the
second half the odd ones.
And for these 2 conversions, the special one for the inner conversion
on x86_64 is with index 2 where the sign bit of _BitInt(129) is present,
while for the outer one index 3 where we need to mask off the most
significant bit.
The r15-6742 change started using m_data[save_data_cnt] for all constant
indexes if it is still inside of the loop (and it is sign extension).
But that doesn't work correctly for the case where the inner conversion
produces the sign extension limb in the loop for an even index and
the outer conversion needs to special case the immediately next conversion,
because in that case using the PHI result will see still 0 there rather
than the updated value from the handling of previous limb.
So the following patch special cases this and uses the other SSA_NAME.

Commented IL, trying to lower
  _1 = (unsigned _BitInt(255)) y_4(D);
  _2 = (unsigned _BitInt(256)) _1;
  _3 = _2 + x_5(D);
   = _3;
we were emitting
   [local count: 1073741824]:
  # _8 = PHI <0(2), _9(12)> // This is the limb index
  # _10 = PHI <0(2), _11(12)>   // Sign extension limb from inner cast (0
or ~0UL)
  # _22 = PHI <0(2), _23(12)>   // Overflow bit from addition of previous
limb
  if (_8 <= 2)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 1073741824]:
  if (_8 == 2)
goto ; [20.00%]
  else
goto ; [80.00%]

   [local count: 1073741824]:
  _12 = VIEW_CONVERT_EXPR(y)[_8]; // Full limbs in y
  goto ; [100.00%]

   [local count: 214748360]:
  _13 = MEM  [(_BitInt(129) *)&y + 16B]; // y[2] which
  _14 = () _13;   // needs to be
  _15 = (unsigned long) _14;// sign extended
  _16 = (signed long) _15;  // to full
  _17 = _16 >> 63;  // limb
  _18 = (unsigned long) _17;

   [local count: 1073741824]:
  # _19 = PHI <_12(5), _10(3), _15(6)>  // Limb to add for result of casts
  # _20 = PHI <0(5), _10(3), _18(6)>// Sign extension limb from
previous limb
  _11 = _20;// PHI _10 argument above
  _21 = VIEW_CONVERT_EXPR(x)[_8];
  _24 = .UADDC (_19, _21, _22);
  _25 = IMAGPART_EXPR <_24>;
  _26 = REALPART_EXPR <_24>;
  VIEW_CONVERT_EXPR()[_8] = _26;
  _27 = _8 + 1;
  if (_27 == 3) // For the outer cast limb 3 is special
goto ; [20.00%]
  else
goto ; [80.00%]

   [local count: 1073741824]:
  if (_27 < 2)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 1073741824]:
  _28 = VIEW_CONVERT_EXPR(y)[_27];// These are used
in full

   [local count: 1073741824]:
  # _29 = PHI <_28(9), _11(8)>
  goto ; [100.00%]

   [local count: 214748360]:
// And HERE is the actual bug.  Using _10 for idx 3 will mean it is always
// zero there and doesn't contain the _18 value propagated to it.
// It should be
// _30 = () _11;
// Now if the outer conversion had special iteration say 5, we could
// have used _10 fin

[Bug rtl-optimization/119785] [12/13/14 Regression] UBSAN errors in machmode.h on sparc

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11661-gefb22612f98c79f38c9e9c7ace3bc681dbcecc03
Author: Jakub Jelinek 
Date:   Mon Apr 14 19:34:22 2025 +0200

expmed: Always use QImode for init_expmed set_zero_cost [PR119785]

This is a regression on some targets introduced I believe by r6-2055
which added mode argument to set_src_cost.

The problem here is that in the first iteration, mode is always QImode
and we get as -Os zero cost set_src_cost (const0_rtx, QImode, false).
But then we use the mode variable for iterating over int, partial int
and vector int modes, so for the second iteration we call set_src_cost
with mode which is at that time (machine_mode) (MAX_MODE_VECTOR_INT + 1).

In the x86 case that happens to be V2HFmode and we don't crash (and
compute the same 0 cost as we would for QImode).
But e.g. in the SPARC case (machine_mode) (MAX_MODE_VECTOR_INT + 1) is
MAX_MACHINE_MODE and that does all kinds of weird things especially
when doing ubsan bootstrap.

Fixed by always using QImode.

2025-04-14  Jakub Jelinek  

PR rtl-optimization/119785
* expmed.cc (init_expmed): Always pass QImode rather than mode to
set_src_cost passed to set_zero_cost.

(cherry picked from commit f96a54350afcf7f3c90d0ecb51d7683d826acc00)

[Bug lto/119625] lto1: fatal error: open failed: No such file or directory

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

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

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

https://gcc.gnu.org/g:293a95b87c5676ff04c6511e900c3d127692d664

commit r14-11655-g293a95b87c5676ff04c6511e900c3d127692d664
Author: Jakub Jelinek 
Date:   Fri Apr 4 20:57:09 2025 +0200

lto: lto-opts fixes [PR119625]

I can reproduce a really weird error in our distro i686 trunk gcc
(but haven't managed to reproduce it with vanilla trunk yet).
echo 'void foo (void) {}' > a.c; gcc -O2 -flto=auto -m32 -march=i686
-ffat-lto-objects -fhardened -o a.o -c a.c; gcc -O2 -flto=auto -m32 -march=i686
-r -o a.lo a.o
lto1: fatal error: open  failed: No such file or directory
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
The error is because
cat ./a.lo.lto.o-args.0
""
a.o
My suspicion is that this "" in there is caused by weird .gnu.lto_.opts
section content during
gcc -O2 -flto=auto -m32 -march=i686 -ffat-lto-objects -fhardened -S -o a.s
-c a.c
compilation (and I can reproduce that one with vanilla trunk).
The above results in
.section.gnu.lto_.opts,"e",@progbits
.string "'-fno-openmp' '-fno-openacc' '-fPIC' '' '-m32'
'-march=i686' '-O2' '-flto=auto' '-ffat-lto-objects'"
There are two weird things, one (IMHO the cause of the "" later on) is
the '' part, I think it comes from lto_write_options doing
append_to_collect_gcc_options (&temporary_obstack, &first_p, "");
IMHO it shouldn't call append_to_collect_gcc_options at all for that case.

The -fhardened option causes global_options.x_flag_cf_protection
to be set to CF_FULL and later on the backend option processing
sets it to CF_FULL | CF_SET (i.e. 7, a value not handled in
lto_write_options).

The following patch fixes it by not emitting anything there if
flag_cf_protection is one of the unhandled values.

Perhaps it could incrementally use
switch (global_options.x_flag_cf_protection & ~CF_SET)
instead, dunno.

And the other problem is that the -fPIC in there is really weird.
Our distro compiler or vanilla configured trunk certainly doesn't
default to -fPIC and -fhardened uses -fPIE when
-fPIC/-fpic/-fno-pie/-fno-pic is not specified, so I was expecting
-fPIE in there.
The thing is that the -fpie option causes setting of both
global_options.x_flag_pi{c,e} to 1, -fPIE both to 2:
  /* If -fPIE or -fpie is used, turn on PIC.  */
  if (opts->x_flag_pie)
opts->x_flag_pic = opts->x_flag_pie;
  else if (opts->x_flag_pic == -1)
opts->x_flag_pic = 0;
  if (opts->x_flag_pic && !opts->x_flag_pie)
opts->x_flag_shlib = 1;
so checking first for flag_pic == 2 and then flag_pic == 1
and only afterwards for flag_pie means we never print
-fPIE/-fpie.

Or do you want something further (like
switch (global_options.x_flag_cf_protection & ~CF_SET)
)?

2025-04-04  Jakub Jelinek  

PR lto/119625
* lto-opts.cc (lto_write_options): If neither flag_pic nor
flag_pie are set, check first for flag_pie and only later
for flag_pic rather than the other way around, use a temporary
variable.  If flag_cf_protection is not set, don't append anything
if flag_cf_protection is none of CF_{NONE,FULL,BRANCH,RETURN} and
use a temporary variable.

(cherry picked from commit d25728c98682c058bfda79333c94b0a8cf2a3f49)

[Bug libgcc/101075] libatomic's libat_lock_n can deadlock from inconsistent locking order

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11664-gd490c5884bf0e5b8d8752969d2ee4dacea700be0
Author: Jakub Jelinek 
Date:   Wed Apr 16 17:22:49 2025 +0200

libatomic: Fix up libat_{,un}lock_n for mingw [PR119796]

Here is just a port of the previously posted patch to mingw which
clearly has the same problems.

2025-04-16  Jakub Jelinek  

PR libgcc/101075
PR libgcc/119796
* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE).  If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.

(cherry picked from commit 34fe8e90007afbc87941df9b01ffcf8747c11497)

[Bug driver/119727] -freport-bug vs. ASLR

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:438c4df22217280df3f141bd0b1df0523b4de6d3

commit r14-11660-g438c4df22217280df3f141bd0b1df0523b4de6d3
Author: Jakub Jelinek 
Date:   Mon Apr 14 10:18:13 2025 +0200

driver: On linux hosts disable ASLR during -freport-bug [PR119727]

Andi had a useful comment that even with the PR119727 workaround to
ignore differences in libbacktrace printed addresses, it is still better
to turn off ASLR when easily possible, e.g. in case some address leaks
in somewhere in the ICE message elsewhere, or to verify the ICE doesn't
depend on a particular library/binary load addresses.

The following patch adds a configure check and uses personality syscall
to turn off randomization for further -freport-bug subprocesses.

2025-04-14  Jakub Jelinek  

PR driver/119727
* configure.ac (HOST_HAS_PERSONALITY_ADDR_NO_RANDOMIZE): New check.
* gcc.cc: Include sys/personality.h if
HOST_HAS_PERSONALITY_ADDR_NO_RANDOMIZE is defined.
(try_generate_repro): Call
personality (personality (0xU) | ADDR_NO_RANDOMIZE)
if HOST_HAS_PERSONALITY_ADDR_NO_RANDOMIZE is defined.
* config.in: Regenerate.
* configure: Regenerate.

(cherry picked from commit 5a32e85810d33dc46b1b5fe2803ee787d40709d5)

[Bug driver/119727] -freport-bug vs. ASLR

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11659-g2aa812386ad5950283f800257c37bdb78691e770
Author: Jakub Jelinek 
Date:   Sat Apr 12 13:15:13 2025 +0200

driver: Fix up -freport-bug for ASLR [PR119727]

With --enable-host-pie -freport-bug almost never prepares preprocessed
source and instead emits
The bug is not reproducible, so it is likely a hardware or OS problem.
message even for bogus which are 100% reproducible.
The way -freport-bug works is that it reruns it 3 times, capturing stdout
and stderr from each and then tries to compare the outputs in between
different runs.
The libbacktrace emitted hexadecimal addresses at the start of the lines
can differ between runs due to ASLR, either of the PIE executable, or
even if not PIE if there is some frame with e.g. libc function (say
crash in strlen/memcpy etc.).

The following patch fixes it by ignoring such differences at the start of
the lines.

2025-04-12  Jakub Jelinek  

PR driver/119727
* gcc.cc (files_equal_p): Rewritten using fopen/fgets/fclose
instead
of open/fstat/read/close.  At the start of lines, ignore lowercase
hexadecimal addresses followed by space.

(cherry picked from commit 8b2ceb421f045ee8b39d7941f39f1e9a67217583)

[Bug libgcc/119796] Atomic Operations Can Deadlock Without Hardware Support

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11663-g50bd360f9270e6656368a5bdf9426b4022780609
Author: Jakub Jelinek 
Date:   Wed Apr 16 17:21:39 2025 +0200

libatomic: Fix up libat_{,un}lock_n [PR119796]

As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
   acquired always in the order from addr_hash (ptr) up to
   locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
   so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
   case at pointer starting at page boundary and in another case at
   page boundary + 2048 bytes, the first thread can lock the first
   32 mutexes, the second thread can lock the last 32 mutexes and
   then first thread wait for the lock 32 held by second thread and
   second thread wait for the lock 0 held by the first thread;
   fixed below by always locking the locks in order of increasing
   index, if there is a wrap-around, by locking in 2 loops, first
   locking some locks at the start of the array and second at the
   end of it
2) the number of locks seems to be determined solely depending on the
   n value, I think that is wrong, we don't know the structure alignment
   on the libatomic side, it could very well be 1 byte aligned struct,
   and so how many cachelines are actually (partly or fully) occupied
   by the atomic access depends not just on the size, but also on
   ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
   should IMHO lock 2 locks because it occupies the first and second
   cacheline

Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.

2025-04-16  Jakub Jelinek  

PR libgcc/101075
PR libgcc/119796
* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE).  If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.

(cherry picked from commit 61dfb0747afcece3b7a690807b83b366ff34f329)

[Bug target/119870] New: `(vector8 unsigned) {0,0x80000000}` and `-0.0` constant formation could be better

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

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

Bug ID: 119870
   Summary: `(vector8 unsigned) {0,0x8000}` and `-0.0`
constant formation could be better
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
#define vector8 __attribute__((vector_size(8)))
vector8 unsigned native3(void) {
  double x = -0.0;
  vector8 unsigned t1;
  __builtin_memcpy(&t1, &x, sizeof(x));
  return t1;
}
```

Currently GCC produces:
```
adrpx0, .LC0
ldr d0, [x0, #:lo12:.LC0]
ret
```

That is a load from the constant pool.

But we should produce:
```
movid0, #0
fnegd0, d0
ret
```

Note For:
```
double native0(void) {
  double x = -0.0;
  return x;
}
```
GCC produces:
```
mov x0, -9223372036854775808
fmovd0, x0
ret
```

Which I also think it might be faster to stay in the fp registers and produce:
```
movid0, #0
fnegd0, d0
ret
```

[Bug libgcc/119796] Atomic Operations Can Deadlock Without Hardware Support

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:

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

commit r14-11664-gd490c5884bf0e5b8d8752969d2ee4dacea700be0
Author: Jakub Jelinek 
Date:   Wed Apr 16 17:22:49 2025 +0200

libatomic: Fix up libat_{,un}lock_n for mingw [PR119796]

Here is just a port of the previously posted patch to mingw which
clearly has the same problems.

2025-04-16  Jakub Jelinek  

PR libgcc/101075
PR libgcc/119796
* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE).  If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.

(cherry picked from commit 34fe8e90007afbc87941df9b01ffcf8747c11497)

[Bug c++/119871] New: Function parameters should never be name-independent

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

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

Bug ID: 119871
   Summary: Function parameters should never be name-independent
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 94404
  Target Milestone: ---

>From http://wg21.link/cwg3005 .

This means:
```
void f(int _) {
int _; // error
}
```
is invalid code because _ as a function paramater is not an name-independent
but rather an actual name of the function paramater so the use of _ below is
also a name because it is named already.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug tree-optimization/118947] Missed optimization: GCC forgets stack buffer contents across function call

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

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

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

https://gcc.gnu.org/g:94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1

commit r16-22-g94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1
Author: Andrew Pinski 
Date:   Thu Feb 20 16:09:05 2025 -0800

gimple-fold: Improve optimize_memcpy_to_memset to handle STRING_CST
[PR78408]

While looking into PR 118947, I noticed that optimize_memcpy_to_memset
didn't
handle STRING_CST which are also used for a memset of 0 but for char
arrays.
This fixes that and improves optimize_memcpy_to_memset to handle that case.

This fixes part of PR 118947 but not the whole thing; we still need to skip
over
vdefs in some cases.

Boostrapped and tested on x86_64-linux-gnu.

PR tree-optimization/78408
PR tree-optimization/118947

gcc/ChangeLog:

* gimple-fold.cc (optimize_memcpy_to_memset): Handle STRING_CST
case too.

gcc/testsuite/ChangeLog:

* gcc.dg/pr78408-3.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores

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

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

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

https://gcc.gnu.org/g:800b3977031dd4f14d09ced975276e09457dfff7

commit r16-25-g800b3977031dd4f14d09ced975276e09457dfff7
Author: Andrew Pinski 
Date:   Mon Apr 7 17:06:17 2025 -0700

DSE: Support triming of some more memset [PR87901]

DSE has support for trimming memset (and memset like) statements.
In this case we have `MEM  [(char * {ref-all})&z] = {};`
in
the IR and when we go to trim it, we call build_fold_addr_expr which leaves
around
a cast from one pointer type to another. This is due to
build_fold_addr_expr
being generic but in gimple you don't need these casts.

PR tree-optimization/87901

gcc/ChangeLog:

* tree-ssa-dse.cc (maybe_trim_constructor_store): Strip over
useless type
conversions after taking the address of the MEM_REF.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-dse-52.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/118947] Missed optimization: GCC forgets stack buffer contents across function call

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

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

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

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

commit r16-23-g7b4849ec79873fa6de98436deda47e19cbac32ef
Author: Andrew Pinski 
Date:   Mon Feb 24 12:33:32 2025 -0800

gimple-fold: Improve optimize_memcpy_to_memset by walking back until
aliasing says the ref is a may clobber. [PR118947]

The case here is we have:
```
char buf[32] = {};
void* ret = aaa();
__builtin_memcpy(ret, buf, 32);
```

And buf does not escape.  But we don't prop the zeroing from buf to the
memcpy statement
because optimize_memcpy_to_memset only looks back one statement. This can
be fixed to look back
until we get an statement that may clobber the reference.  If we get a phi
node, then we don't do
anything.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/118947

gcc/ChangeLog:

* gimple-fold.cc (optimize_memcpy_to_memset): Walk back until we
get a
statement that may clobber the read.

gcc/testsuite/ChangeLog:

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

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores

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

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

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

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

commit r16-26-g2d693c1ffd849e0c1df9cc6610a69a63ffcb2956
Author: Andrew Pinski 
Date:   Mon Apr 7 17:57:07 2025 -0700

DSE: Trim stores of 0 like triming stores of {} [PR87901]

This is the second part of the PR which comes from transformation
of memset into either stores of 0 (via an integral type) or stores
of {}. We already handle stores of `{}`, this just extends that to
handle of the constant 0 and treat it similarly.

PR tree-optimization/87901

gcc/ChangeLog:

* tree-ssa-dse.cc (maybe_trim_constructor_store): Add
was_integer_cst argument.
Check for was_integer_cst instead of `{}` when was_integer_cst is
true.
(maybe_trim_partially_dead_store): Handle INTEGER_CST stores of 0
as stores of `{}`.
Udpate call to maybe_trim_constructor_store for CONSTRUCTOR.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-dse-53.c: New test.
* gcc.dg/tree-ssa/ssa-dse-54.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR

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

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

Bug 87901 Summary: partial DSE of memset doesn't work for other kind of stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87901

   What|Removed |Added

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

[Bug tree-optimization/118947] Missed optimization: GCC forgets stack buffer contents across function call

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
Fixed for GCC 16.

[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Fixed for GCC 16.

[Bug c/78408] C loop initial declarations generate wrong code

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

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

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

https://gcc.gnu.org/g:94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1

commit r16-22-g94f275432f7ea4781ec7c05fa9d1d81ef6cb3fc1
Author: Andrew Pinski 
Date:   Thu Feb 20 16:09:05 2025 -0800

gimple-fold: Improve optimize_memcpy_to_memset to handle STRING_CST
[PR78408]

While looking into PR 118947, I noticed that optimize_memcpy_to_memset
didn't
handle STRING_CST which are also used for a memset of 0 but for char
arrays.
This fixes that and improves optimize_memcpy_to_memset to handle that case.

This fixes part of PR 118947 but not the whole thing; we still need to skip
over
vdefs in some cases.

Boostrapped and tested on x86_64-linux-gnu.

PR tree-optimization/78408
PR tree-optimization/118947

gcc/ChangeLog:

* gimple-fold.cc (optimize_memcpy_to_memset): Handle STRING_CST
case too.

gcc/testsuite/ChangeLog:

* gcc.dg/pr78408-3.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/118902] missing predicated VN due to Canonical order of comparison with invariant

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

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

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

https://gcc.gnu.org/g:16082bdc6beef1ca1485ed5ccdc0c52aabbe0f4c

commit r16-24-g16082bdc6beef1ca1485ed5ccdc0c52aabbe0f4c
Author: Andrew Pinski 
Date:   Thu Feb 13 20:23:48 2025 -0800

gimple: Canonical order for invariants [PR118902]

So unlike constants, address invariants are currently put first if
used with a SSA NAME.
It would be better if address invariants are consistent with constants
and this patch changes that.
gcc.dg/tree-ssa/pr118902-1.c is an example where this canonicalization
can help. In it if `p` variable was a global variable, FRE (VN) would have
figured
it out that `a` could never be equal to `&p` inside the loop. But without
the
canonicalization we end up with `&p == a.0_1` which VN does try to handle
for conditional
VN.

Bootstrapped and tested on x86_64.

PR tree-optimization/118902
gcc/ChangeLog:

* fold-const.cc (tree_swap_operands_p): Place invariants in the
first operand
if not used with constants.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr118902-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/118902] missing predicated VN due to Canonical order of comparison with invariant

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed for GCC 16.

[Bug c++/119866] New: constant evaluation failure with trivial function

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 119866
   Summary: constant evaluation failure with trivial function
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Not sure how to exactly title this bug.

This is a reproduction while trying to understand a compile failure with a
recent upgrade to {fmt}:

using size_t = decltype(sizeof(int));

constexpr char const* id(char const* s) { return s; }

template 
struct fixed_string {
char data[N] = {}; 

constexpr fixed_string(char const (&m)[N]) {
for (size_t i = 0; i != N; ++i) {
data[i] = m[i];
}
}   
};

int main() {
static constexpr char msg[] = "hello\n";
static_assert(__builtin_strlen(msg) == 6);  // ok
static_assert(__builtin_strlen(id(msg)) == 6);  // ok

static constexpr auto str = fixed_string("hello\n");
static_assert(__builtin_strlen(str.data) == 6); // ok
static_assert(__builtin_strlen(auto(str.data)) == 6);   // ok
static_assert(__builtin_strlen(id(str.data)) == 6); // error
}

The last assertion fails (on trunk c++26, but also lots of versions going
back):

:24:50: error: non-constant condition for static assertion
   24 | static_assert(__builtin_strlen(id(str.data)) == 6); // error
  |   ~~~^~~~
:24:35: error: '__builtin_strlen(((const char*)(&
str.fixed_string<7>::data)))' is not a constant expression
   24 | static_assert(__builtin_strlen(id(str.data)) == 6); // error
  |   ^~

id(x) is just x, it's not doing anything to the parameter. It's like the
constant evaluator loses track of the pointer.

[Bug c++/119866] constant evaluation failure with trivial function

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

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

--- Comment #1 from Andrew Pinski  ---
I am not sure if __builtin_strlen is supposed to be callable from constexpr at
all.

[Bug c++/119866] constant evaluation failure with trivial function

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

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

--- Comment #2 from Andrew Pinski  ---
Though __builtin_strlen might not be the issue here...

[Bug c++/119866] constant evaluation failure with trivial function

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Barry Revzin  ---
Well even gcc 4.7.1 accepted this

int main() {
static_assert(__builtin_strlen("hi") == 2, "!");
}

At this point lots of code relies on that working.

[Bug c++/119866] constexpr with __builtin_strlen does not always work

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

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

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

[Bug c++/119866] constexpr with __builtin_strlen does not always work

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

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

--- Comment #4 from Andrew Pinski  ---
And yes it is due to __builtin_strlen in some cases.

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

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

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

Bug 119866 Summary: constexpr with __builtin_strlen does not always work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119866

   What|Removed |Added

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

[Bug c++/106889] __builtin_strlen fails for some constexpr constructs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

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

[Bug c++/119866] constexpr with __builtin_strlen does not always work

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/119866] constexpr with __builtin_strlen does not always work

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 106889 ***

I should say bug 106889 is exactly the same as this one and yes it is
__builtin_strlen as shown by that bug report.

As mentioned in that bug report __builtin_strlen most likely should not be used
inside an const expr and all.

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Depends on||83282
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
   Last reconfirmed||2025-04-18
 Ever confirmed|0   |1
 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
A related bug that is on my list is pr83282.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
[Bug 83282] missing comma in format changes output