[Bug target/117722] RISC-V: Failed to vectorize x264_pixel_sad_4x4

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

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

--- Comment #18 from Robin Dapp  ---
> But the point here really here is we don't need the widening semantics, more
> twice. The min+max+sub in loops with a final reducing sum should do the
> trick.

OK I guess it can be argued that
  minus (max (a, b), min (a, b))
is generally a preferable "absdiff" expansion over
  max (neg (minus (convert (a), convert (b.

The former is not better but also not worse if a two-operand widening minus is
available and equally fast as a regular minus.  When widening sub and add are
slower it's always better.

So if we want to get rid of the widening ops I'd say defining an [us]abd3
expander is the way to go.  On our uarch widening ops aren't worse than regular
ops so it wouldn't matter but as uarchs differ we could do that.

Something like (untested):
(define_expand "uabd3"
  [(match_operand:V_VLSI 0 "register_operand")
   (match_operand:V_VLSI 1 "register_operand")
   (match_operand:V_VLSI 2 "register_operand")]
  "TARGET_VECTOR"
{
  rtx mx = gen_reg_rtx (mode);
  rtx mn = gen_reg_rtx (mode);
  emit_move_insn (mx, gen_rtx_UMAX (mode, operands[1], operands[2]));
  emit_move_insn (mn, gen_rtx_UMIN (mode, operands[1], operands[2]));
  emit_move_insn (operands[0], gen_rtx_MINUS (mode, mx, mn));
  DONE;
})

[Bug rtl-optimization/117999] New: libgo regressions on arm after g:75e7d1600f47859df40b2ac0feff5a71e0dbb040

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

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

Bug ID: 117999
   Summary: libgo regressions on arm after
g:75e7d1600f47859df40b2ac0feff5a71e0dbb040
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
CC: vmakarov at redhat dot com
  Target Milestone: ---
Target: arm

After commit g:75e7d1600f47859df40b2ac0feff5a71e0dbb040 , the Linaro CI
detected regressions in libgo tests on arm-linux-gnueabihf:

FAIL: crypto/tls 
FAIL: crypto/x509 

the log says:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf755abbe]

goroutine 1 [running]:
crypto_1elliptic_1internal_1nistec.P521Point.Set
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/elliptic/internal/nistec/p521.go:70
crypto_1elliptic_1internal_1nistec.NewP521Generator
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/elliptic/internal/nistec/p521.go:65
crypto_1elliptic.p521Curve.ScalarBaseMult
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/elliptic/p521.go:147
crypto/x509.parseECPrivateKey
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/x509/sec1.go:117
crypto_1x509.ParseECPrivateKey
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/x509/sec1.go:35
crypto_1tls..import
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest3208790/test/handshake_test.go:451
FAIL: crypto/tls
--- FAIL: TestPKCS8 (0.01s)
panic: runtime error: invalid memory address or nil pointer dereference
[recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x47a58]

goroutine 65 [running]:
testing.tRunner..func3
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/testing/testing.go:1425
testing.tRunner..func1
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/testing/testing.go:1342
panic
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/runtime/panic.go:714
crypto_1elliptic_1internal_1nistec.P521Point.Set
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/elliptic/internal/nistec/p521.go:70
crypto_1elliptic_1internal_1nistec.NewP521Generator
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/elliptic/internal/nistec/p521.go:65
crypto_1elliptic.p521Curve.ScalarBaseMult
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/crypto/elliptic/p521.go:147
crypto/x509.parseECPrivateKey
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest3211815/test/sec1.go:117
crypto_1x509.ParsePKCS8PrivateKey
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest3211815/test/pkcs8.go:58
crypto_1x509.TestPKCS8
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/armv8l-unknown-linux-gnueabihf/libgo/gotest3211815/test/pkcs8_test.go:96
testing.tRunner
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/testing/testing.go:1475
created by testing.T.Run
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libgo/go/testing/testing.go:1522
+0x19c
FAIL: crypto/x509

[Bug tree-optimization/117997] [15 regression] libgo regressions on aarch64 after g:4d2b9202fe94c54e63fb07d48293a78da3d82532

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|go  |tree-optimization
Summary|libgo regressions on|[15 regression] libgo
   |aarch64 after   |regressions on aarch64
   |g:4d2b9202fe94c54e63fb07d48 |after
   |293a78da3d82532 |g:4d2b9202fe94c54e63fb07d48
   ||293a78da3d82532
   Keywords||wrong-code
URL|https://linaro.atlassian.ne |
   |t/browse/GNU-1445   |
   Target Milestone|--- |15.0
   Assignee|ian at airs dot com|unassigned at gcc dot 
gnu.org
   See Also||https://linaro.atlassian.ne
   ||t/browse/GNU-1445

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

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

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

--- Comment #54 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #53)
> Couldn't you avoid the launder by returning static_cast(memmove(p, p,
> sizeof(T))) instead? That pointer _does_ point to the new object, doesn't
> it? ... huh, no, memcpy and memmove do not return a pointer to a suitable
> created object. Seems like they could/should.

Hmm, https://eel.is/c++draft/cstring.syn#3 says they implicitly create objects,
but a void* can't be a pointer to a suitable created object.

And then I read https://eel.is/c++draft/expr#static.cast-13 as saying that the
static_cast above returns a pointer to such an implicitly-created object.

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

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

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

Jennifer Schmitz  changed:

   What|Removed |Added

 CC||jschmitz at gcc dot gnu.org

--- Comment #10 from Jennifer Schmitz  ---
We are also optimizing ABS expressions and improving codegen for the following
types of test cases (for T in {uint8_t, int8_t, uint16_t, int16_t, uint32_t,
int32_t, uint64_t, int64_t, __uint128_t, __int128_t}):

T src(T x, T y)
{
T diff1 = x - y;
T diff2 = y - x;
return x > y ? diff1 : diff2;
}

T tgt(T x, T y)
{
T diff = x - y;
return x > y ? diff : -diff;
}

This seems to be a subset of the transformations described here, so it would
be good to coordinate the work: We have code ready that covers our test cases,
but would also be happy to look at other optimizations mentioned above.

[Bug driver/117992] gcc -flto -fharden leads to warning

[uwu at icenowy dot me via Gcc-bugs]

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

--- Comment #7 from Icenowy Zheng  ---
Does -flto imply -pie ? I cannot understand the discussion here now...

[Bug driver/117992] gcc -flto -fharden leads to warning

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

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

--- Comment #8 from Jakub Jelinek  ---
No, but maybe you've configured your gcc to default to -pie.

[Bug middle-end/117987] Function multiversioning does not respect decl asms

[Alfie.Richards at arm dot com via Gcc-bugs]

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

--- Comment #1 from Alfie Richards  ---
Of note for this specifically, is that there is currently ongoing discussion as
to where the definitive information about a multi-versioned function should and
can be specified in the Arm C Language Extension, which could alter what the
correct behavior for this is.
Definitely a bug to not error/warn and do the wrong thing currently though.

[Bug other/116253] RFE: support for nested diagnostics

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:331226fd87c2010928329ef35b6d4f680d9234d1

commit r15-6115-g331226fd87c2010928329ef35b6d4f680d9234d1
Author: David Malcolm 
Date:   Wed Dec 11 10:21:35 2024 -0500

diagnostics: tweak output for nested messages [PR116253]

When printing nested messages with
-fdiagnostics-set-output=text:experimental-nesting=yes
avoid printing a line such as the "cc1plus:" in the following:
⢠note: set â-fconcepts-diagnostics-depth=â to at least 2 for
more detail
  cc1plus:
for "special" locations such as UNKNOWN_LOCATION.

gcc/ChangeLog:
PR other/116253
* diagnostic-format-text.cc (on_report_diagnostic): When showing
locations for nested messages on new lines, don't print
UNKNOWN_LOCATION or BUILTINS_LOCATION.

Signed-off-by: David Malcolm 

[Bug driver/117992] gcc -flto -fharden leads to warning

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

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

--- Comment #9 from Xi Ruoyao  ---
(In reply to Icenowy Zheng from comment #7)
> Does -flto imply -pie ? I cannot understand the discussion here now...

No, but if your GCC is configured --with-default-pie (it's enabled by almost
all Linux distros), during LTO gcc will be invoked with an explicit -pie in the
command line.

Without -flto, there's no explicit -fpie flag and the bug is not triggered by
the default PIE configuration alone.  So it appears triggered by -flto.

[Bug driver/117992] gcc -flto -fharden leads to warning

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

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #9)

> Without -flto, there's no explicit -fpie flag

Sorry I mean -pie, not -fpie.

[Bug other/116253] RFE: support for nested diagnostics

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:7435d1dbae8ae1db239228811b1e1f2452674704

commit r15-6117-g7435d1dbae8ae1db239228811b1e1f2452674704
Author: David Malcolm 
Date:   Wed Dec 11 10:26:17 2024 -0500

diagnostics: suppress "note: " prefix in nested diagnostics [PR116253]

This patch is a followup to:
  "c++: use diagnostic nesting [PR116253]"

This patch tweaks how text output with experimental-nesting=yes
prints nested diagnostics, by omitting the leading "note: " from
nested notes.

This reduces the amount of visual cruft the user has to ignore when
reading C++ template errors; see the examples in the testsuite.

This doesn't affect the output for users who have not opted-in
to nested diagnostic-printing.

gcc/ChangeLog:
PR other/116253
* diagnostic-format-text.cc (build_prefix): Don't add the
"note: " prefix when showing nested diagnostics.

gcc/testsuite/ChangeLog:
PR other/116253
* g++.dg/concepts/nested-diagnostics-1-truncated.C: Update
expected output.
* g++.dg/concepts/nested-diagnostics-1.C: Likewise.
* g++.dg/concepts/nested-diagnostics-2.C: Likewise.
*
gcc.dg/plugin/diagnostic-test-nesting-text-indented-show-levels.c:
Likewise.
* gcc.dg/plugin/diagnostic-test-nesting-text-indented-unicode.c:
Likewise.
* gcc.dg/plugin/diagnostic-test-nesting-text-indented.c: Likewise.

Signed-off-by: David Malcolm 

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

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

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

--- Comment #55 from Jonathan Wakely  ---
https://cplusplus.github.io/LWG/issue4064 clarifies that launder is
unnecessary.

[Bug c++/117993] [15 regression] this->x is being rejected in a nested template class with a base of class of the outer templated class since r15-2117

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Patrick Palka  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3) 
> > I suspect for some reason we think the current instantiation does not have a
> > dependent base for some reason.
> 
> That is any_dependent_bases_p is returning false for `struct B::C`
> type.
Indeed, so it seems any_dependent_bases_p should recursively consider indirect
bases.

Or for

  template
  struct B { template struct C; };

  template
  template
  struct B::C : B { }

should BINFO_DEPENDENT_BASE_P be set on the base B?

[Bug c++/117993] [15 regression] this->x is being rejected in a nested template class with a base of class of the outer templated class since r15-2117

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

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

--- Comment #7 from Patrick Palka  ---
(In reply to Patrick Palka from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Andrew Pinski from comment #3) 
> > > I suspect for some reason we think the current instantiation does not 
> > > have a
> > > dependent base for some reason.
> > 
> > That is any_dependent_bases_p is returning false for `struct B::C`
> > type.
> Indeed, so it seems any_dependent_bases_p should recursively consider
> indirect bases.
> 
> Or for
> 
>   template
>   struct B { template struct C; };
Whoops, this should be e.g.

  struct B : T { template struct C; };

[Bug target/118000] New: [avr] memcpy from __flash1 clobbers RAMPZ on EBI devices

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

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

Bug ID: 118000
   Summary: [avr] memcpy from __flash1 clobbers RAMPZ on EBI
devices
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59832&action=edit
flash1.c: GNU-C99 test case

The attached flash1.c aborts on ATxmega128A1 because in

void copyf1 (void)
{
s2 = sf1;
const int *pz = &zval;
__asm ("" : "+z" (pz));
if (*pz != 1234)
__builtin_abort ();
}

the implicit memcpy clobbers RAMPZ, and then *pz reads garbage since the hhi8
part of the address isn't zero.

[Bug driver/117992] gcc -flto -fharden leads to warning

[uwu at icenowy dot me via Gcc-bugs]

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

--- Comment #11 from Icenowy Zheng  ---
Checked gcc -v, there's really enable-default-pie, and in the output of "gcc
main.c -fhardened -O2 -flto -v", the COLLECT_GCC_OPTIONS lists really include
"-pie".

Thus the explanation by Ruoyao looks reasonable. Thanks.

[Bug c++/117993] [15 regression] this->x is being rejected in a nested template class with a base of class of the outer templated class since r15-2117

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

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

--- Comment #8 from Jason Merrill  ---
(In reply to Patrick Palka from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Andrew Pinski from comment #3) 
> > > I suspect for some reason we think the current instantiation does not 
> > > have a
> > > dependent base for some reason.
> > 
> > That is any_dependent_bases_p is returning false for `struct B::C`
> > type.
> Indeed, so it seems any_dependent_bases_p should recursively consider
> indirect bases.

Yes, at least if the direct base is currently_open_class.

> Or for
> 
>   template
>   struct B { template struct C; };
> 
>   template
>   template
>   struct B::C : B { }
> 
> should BINFO_DEPENDENT_BASE_P be set on the base B?

No, we want to look into B, it refers to the current instantiation.

[Bug target/118001] New: [avr] Support __flashx as 24-bit named address space

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

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

Bug ID: 118001
   Summary: [avr] Support __flashx as 24-bit named address space
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Currently, __memx is the only address space that can read from any flash
address, and that supports reading across the 64 KiB flash segment boundaries.

Though __memx may also read from generic space / RAM which makes it more
complicated than required when it's known in advance that only flash locations
will be read.

This can be fixed by a new 24-bit address space __flashx that reads from any
program memory address.  __flashx objects should be allocated to .progmemx.data
so that it doesn't eat up the precious lower addresses from, say, progmem.data.

[Bug target/118001] [avr] Support __flashx as 24-bit named address space

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||addr-space
   Severity|normal  |enhancement
 Target||avr

[Bug c++/118002] New: Padding bits still not cleared in empty classes

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

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

Bug ID: 118002
   Summary: Padding bits still not cleared in empty classes
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I think
struct S {};
struct T { S a, b, c, d, e, f, g, h; };
struct U { T i, j, k, l, m, n, o, p; };

[[gnu::noipa]] void
foo (struct U *)
{
}

[[gnu::noipa]] void
bar ()
{
  U u[4];
  __builtin_memset (&u, -1, sizeof (U) * 4);
  foo (&u[0]);
}

[[gnu::noipa]] void
baz ()
{
  U u = U ();
  foo (&u);
  for (int i = 0; i < sizeof (U); ++i)
if (((char *) &u)[i] != 0)
  __builtin_abort ();
}

int
main ()
{
  bar ();
  baz ();
}

is valid and should pass, but it doesn't because we optimize away all stores to
empty classes.
I think we need to make an exception for CONSTRUCTOR_ZERO_PADDING_BITS rhs.

[Bug c++/118002] Padding bits still not cleared in empty classes

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 59833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59833&action=edit
gcc15-pr118002.patch

Untested fix.

[Bug c++/116416] Missing optimization: compile time evaluation of prvalue

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

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 59834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59834&action=edit
gcc15-pr116416-opt.patch

I've tried to implement a simple optimization (on top of the PR118002 fix),
where we clear just a subobject that needs padding or other uninitialized bits
cleared rather than the whole object.
On the pr78687.C testcase, this results (in gimple dump) in:
-  D.10177 = {};
+  D.10177._storage.D.9582.D.9163._tail.D.9221._tail.D.9280._head = {};
because as I wrote, the single byte option_2() is the only part of the object
that actually needs to have padding bits cleared, rather than the rather large
whole object.
Though, SRA still punts even on that.

[Bug c++/116416] Missing optimization: compile time evaluation of prvalue

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

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

--- Comment #12 from Jakub Jelinek  ---
struct S { int a; };
struct T { struct S b; int c; struct S d; };
struct U { struct T e; int f; struct T g; };
void f0 (struct U *);

void
f1 (void)
{
  struct U u = { { {}, 1, {} }, 2, { {}, 3, {} } };
  f0 (&u);
}

void
f2 (void)
{
  struct U u = { { { 1 }, 2, { 3 } }, 4, { { 5 }, 6, {} } };
  f0 (&u);
}

void
f3 (void)
{
  struct U u = { { { }, 2, { } }, 4, { { 5 }, 6, { 7 } } };
  f0 (&u);
}

is a C23 testcase showing what it can do, for f1 there is no difference, for f2
-  u = {};
   u.e.b.a = 1;
   u.e.c = 2;
   u.e.d.a = 3;
   u.f = 4;
   u.g.b.a = 5;
   u.g.c = 6;
+  u.g.d = {};
   f0 (&u);
and for f3:
-  u = {};
+  u.e = {};
   u.e.c = 2;
   u.f = 4;
   u.g.b.a = 5;
...

[Bug c++/117614] [14/15 Regression] Cannot change active member of anonymous union in constant expression since r14-4771-g1d260ab0e39ea6

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

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

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

https://gcc.gnu.org/g:337815c8bbd0fb5034223ad0e7899d1493e958a2

commit r15-6119-g337815c8bbd0fb5034223ad0e7899d1493e958a2
Author: Jakub Jelinek 
Date:   Wed Dec 11 17:28:47 2024 +0100

c++: allow stores to anon union vars to change current union member in
constexpr [PR117614]

Since r14-4771 the FE tries to differentiate between cases where the lhs
of a store allows changing the current union member and cases where it
doesn't, and cases where it doesn't includes everything that has gone
through the cxx_eval_constant_expression path on the lhs.
As the testcase shows, DECL_ANON_UNION_VAR_P vars were handled like that
too, even when stores to them are the only way how to change the current
union member in the sources.

So, the following patch just handles that case manually without calling
cxx_eval_constant_expression and without setting evaluated to true.

2024-12-11  Jakub Jelinek  

PR c++/117614
* constexpr.cc (cxx_eval_store_expression): For stores to
DECL_ANON_UNION_VAR_P vars just continue with DECL_VALUE_EXPR
of it, without setting evaluated to true or full
cxx_eval_constant_expression.

* g++.dg/cpp2a/constexpr-union8.C: New test.

[Bug c++/117614] [14 Regression] Cannot change active member of anonymous union in constant expression since r14-4771-g1d260ab0e39ea6

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14/15 Regression] Cannot   |[14 Regression] Cannot
   |change active member of |change active member of
   |anonymous union in constant |anonymous union in constant
   |expression since|expression since
   |r14-4771-g1d260ab0e39ea6|r14-4771-g1d260ab0e39ea6

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

[Bug tree-optimization/117979] [12/13/14/15 Regression] ICE on x86_64-linux-gnu: in verify_loop_structure, at cfgloop.cc:1742 at -Os and above and returns twice since r12-5301

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |ICE on x86_64-linux-gnu: in |ICE on x86_64-linux-gnu: in
   |verify_loop_structure, at   |verify_loop_structure, at
   |cfgloop.cc:1742 at -Os and  |cfgloop.cc:1742 at -Os and
   |above and returns twice |above and returns twice
   ||since r12-5301
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #2 from Jakub Jelinek  ---
Slightly cleaned up testcase (the const attribute still seems really weird,
only if say one expects to call the function only with 0 argument and foo has
no side-effects except that it isn't marked so).

int a, b;
void foo (void);
int __attribute__((returns_twice)) bar (int);

int __attribute__((const))
baz (int f)
{
  if (f)
{
  l:;
  for (f = 0; f < 6; ++f)
if (bar (b))
  goto l;
  for (;; a--)
;
}
  foo ();
  return 0;
}

And indeed, started to ICE with
r12-5301-g045206450386bcd774db3bde0c696828402361c6

[Bug go/117997] New: libgo regressions on aarch64 after g:4d2b9202fe94c54e63fb07d48293a78da3d82532

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

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

Bug ID: 117997
   Summary: libgo regressions on aarch64 after
g:4d2b9202fe94c54e63fb07d48293a78da3d82532
   Product: gcc
   Version: 15.0
   URL: https://linaro.atlassian.net/browse/GNU-1445
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: clyon at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com
  Target Milestone: ---
Target: aarch64

After commit g:4d2b9202fe94c54e63fb07d48293a78da3d82532 the Linaro CI has
detected regressions in libgo tests on aarch64:

Running libgo:gcc.git~master/libgo/libgo.exp ...
FAIL: crypto/rsa 
FAIL: hash 

libgo.log says:
PASS: crypto/rc4
panic: bzip2 data invalid: block checksum mismatch

goroutine 33 [running]:
crypto/rsa.TestPSSGolden..func1
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/gcc-gcc.git~master-stage2/aarch64-unknown-linux-gnu/libgo/gotest1830895/test/pss_test.go:124
created by crypto_1rsa.TestPSSGolden
   
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/gcc-gcc.git~master-stage2/aarch64-unknown-linux-gnu/libgo/gotest1830895/test/pss_test.go:95
+0x1e4
FAIL: crypto/rsa
[...]
--- FAIL: TestMarshalHash (0.01s)
--- FAIL: TestMarshalHash/crc32 (0.00s)
marshal_test.go:86: MarshalBinary = 637263010eb1cc44c956d3e8, want
63726301ca87914dc956d3e8
FAIL
FAIL: hash

[Bug target/117835] wrong code with -O -favoid-store-forwarding -mno-push-args --param=store-forwarding-max-distance=0

[konstantinos.eleftheriou at vrull dot eu via Gcc-bugs]

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

--- Comment #1 from Konstantinos Eleftheriou  ---
I have reproduced this and I'm working on finding the cause.

[Bug tree-optimization/115869] [13/14/15 Regression] Wrong constant evaluation with vector of struct due to loop interchange

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Doesn't reproduce with array instead of vector.

[Bug tree-optimization/115869] [13/14/15 Regression] Wrong constant evaluation with vector of struct due to loop interchange

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #6 from Jakub Jelinek  ---
Started with r13-1268-g8c99e307b20c502e55c425897fb3884ba8f05882

[Bug libfortran/117819] Formatted READ with BZ in format fails

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

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

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

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

commit r14-11079-g2d9dbaf06e4cd83125781d1eb760f5404da3d175
Author: Jerry DeLisle 
Date:   Mon Dec 9 20:11:23 2024 -0800

Fortran: Fix READ with padding in BLANK ZERO mode.

PR fortran/117819

libgfortran/ChangeLog:

* io/read.c (read_decimal): If the read value is short of the
specified width and pad mode is PAD yes, check for BLANK ZERO
and adjust the value accordingly.
(read_radix): Likewise.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr117819.f90: New test.

(cherry picked from commit cf406a6c79ce404c45f99bcf2df3293269dbb462)

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

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

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

--- Comment #21 from GCC Commits  ---
The master branch has been updated by Filip Kastl :

https://gcc.gnu.org/g:56946c801a7cf3a831a11870b7e11ba08bf9bd87

commit r15-6120-g56946c801a7cf3a831a11870b7e11ba08bf9bd87
Author: Filip Kastl 
Date:   Wed Dec 11 19:57:04 2024 +0100

gimple: Add limit after which slower switchlower algs are used [PR117091]
[PR117352]

This patch adds a limit on the number of cases of a switch.  When this
limit is exceeded, switch lowering decides to use faster but less
powerful algorithms.

In particular this means that for finding bit tests switch lowering
decides between the old dynamic programming O(n^2) algorithm and the
new greedy algorithm that Andi Kleen recently added but then reverted
due to PR117352.  It also means that switch lowering may bail out on
finding jump tables if the switch is too large  (Btw it also may not
bail!  It can happen that the greedy algorithms finds some bit tests
which then basically split the switch into multiple smaller switches and
those may be small enough to fit under the limit.)

The limit is implemented as --param switch-lower-slow-alg-max-cases.
Exceeding the limit is reported through -Wdisabled-optimization.

This patch fixes the issue with the greedy algorithm described in
PR117352.  The problem was incorrect usage of the is_beneficial()
heuristic.

gcc/ChangeLog:

PR middle-end/117091
PR middle-end/117352
* doc/invoke.texi: Add switch-lower-slow-alg-max-cases.
* params.opt: Add switch-lower-slow-alg-max-cases.
* tree-switch-conversion.cc (jump_table_cluster::find_jump_tables):
Note in a comment that we are looking for jump tables in
case sequences delimited by the already found bit tests.
(bit_test_cluster::find_bit_tests): Decide between
find_bit_tests_fast() and find_bit_tests_slow().
(bit_test_cluster::find_bit_tests_fast): New function.
(bit_test_cluster::find_bit_tests_slow): New function.
(switch_decision_tree::analyze_switch_statement): Report
exceeding the limit.
* tree-switch-conversion.h: Add find_bit_tests_fast() and
find_bit_tests_slow().

Co-Authored-By: Andi Kleen 
Signed-off-by: Filip Kastl 

[Bug middle-end/117352] [15 Regression] switch bit test conversion makes comparison code worse on aarch64 and x86_64 with APX due to not generating ccmp

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Filip Kastl :

https://gcc.gnu.org/g:56946c801a7cf3a831a11870b7e11ba08bf9bd87

commit r15-6120-g56946c801a7cf3a831a11870b7e11ba08bf9bd87
Author: Filip Kastl 
Date:   Wed Dec 11 19:57:04 2024 +0100

gimple: Add limit after which slower switchlower algs are used [PR117091]
[PR117352]

This patch adds a limit on the number of cases of a switch.  When this
limit is exceeded, switch lowering decides to use faster but less
powerful algorithms.

In particular this means that for finding bit tests switch lowering
decides between the old dynamic programming O(n^2) algorithm and the
new greedy algorithm that Andi Kleen recently added but then reverted
due to PR117352.  It also means that switch lowering may bail out on
finding jump tables if the switch is too large  (Btw it also may not
bail!  It can happen that the greedy algorithms finds some bit tests
which then basically split the switch into multiple smaller switches and
those may be small enough to fit under the limit.)

The limit is implemented as --param switch-lower-slow-alg-max-cases.
Exceeding the limit is reported through -Wdisabled-optimization.

This patch fixes the issue with the greedy algorithm described in
PR117352.  The problem was incorrect usage of the is_beneficial()
heuristic.

gcc/ChangeLog:

PR middle-end/117091
PR middle-end/117352
* doc/invoke.texi: Add switch-lower-slow-alg-max-cases.
* params.opt: Add switch-lower-slow-alg-max-cases.
* tree-switch-conversion.cc (jump_table_cluster::find_jump_tables):
Note in a comment that we are looking for jump tables in
case sequences delimited by the already found bit tests.
(bit_test_cluster::find_bit_tests): Decide between
find_bit_tests_fast() and find_bit_tests_slow().
(bit_test_cluster::find_bit_tests_fast): New function.
(bit_test_cluster::find_bit_tests_slow): New function.
(switch_decision_tree::analyze_switch_statement): Report
exceeding the limit.
* tree-switch-conversion.h: Add find_bit_tests_fast() and
find_bit_tests_slow().

Co-Authored-By: Andi Kleen 
Signed-off-by: Filip Kastl 

[Bug target/117970] [15 regression] RISC-V: xtreme-header failed to read compiled module: Bad file data

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #5 from Edwin Lu  ---
this testcase also appears to be flakey for these three targets:
- rv32imac-ilp32d
- rv64imac-lp64d
- rv64imc_zicsr_zifencei-lp64d

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

[Bug middle-end/117352] [15 Regression] switch bit test conversion makes comparison code worse on aarch64 and x86_64 with APX due to not generating ccmp

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

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

Filip Kastl  changed:

   What|Removed |Added

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

--- Comment #6 from Filip Kastl  ---
With the patch this no longer happens to Andi's algorithm. So I think we can
mark this as fixed.

[Bug fortran/117901] [15 regression] class_transformational_1.f90 with -O3 and -fcheck=bounds gives ICE in make_ssa_name_fn

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r15-6121-gbbb7c53d32ece75ec0c336663ec37df9e63652d3
Author: Paul Thomas 
Date:   Wed Dec 11 16:14:05 2024 +

Fortran: Add DECL_EXPR for variable length assoc name [PR117901]

2024-12-11  Paul Thomas  

gcc/fortran
PR fortran/117901
* trans-stmt.cc (trans_associate_var): A variable character
length array associate name must generate a DECL expression for
the data pointer type.

gcc/testsuite/
PR fortran/117901
* gfortran.dg/pr117901.f90: New test.

[Bug libstdc++/118003] New: std::filesystem::remove_all() hangs on Windows on directories containing a deep tree with long paths

[martin at martin dot st via Gcc-bugs]

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

Bug ID: 118003
   Summary: std::filesystem::remove_all() hangs on Windows on
directories containing a deep tree with long paths
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at martin dot st
  Target Milestone: ---

To reproduce - create a deep tree where the total path name to the deepest
folders exceed the normal MAX_PATH. E.g. in msys2, do this:

$ mkdir -p
/tmp/file-system-test-ed4fa1/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss/DirNameWith19Charss

Then build the following test program, that tries to remove this directory
tree:

#include 
#include 

int main(int argc, char* argv[]) {
  if (argc < 2) {
std::cout << argv[0] << " dir" << std::endl;
return 0;
  }
  std::filesystem::path Path(argv[1]);
  std::error_code EC;
  std::cout << "Path " << Path << std::endl;
  std::filesystem::remove_all(Path, EC);
  return 0;
}

Running this in msys2 like this:
$ ./fs-removeall.exe /tmp/file-system-test-ed4fa1
Path "C:/msys64/tmp/file-system-test-ed4fa1"

At this point, the program hangs, and doesn't complete. If we remove one level
of directories, so that the deepest point of the directory tree no longer
exceeds MAX_PATH, the program succeeds.


This situation was observed in an LLVM test, when attempting to use
std::filesystem::remove_all() for such operations, in
https://github.com/llvm/llvm-project/pull/119146.

The same operation succeeds with libc++ and MS STL.

[Bug ada/117956] assertion failure on 'Old in post-condition with -gnat2022

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #4 from simon at pushface dot org ---
(In reply to simon from comment #1)
> It’s the -gnatX.

It seems to be the combination of -gnata with either -gnat2022 or -gnatX -- and
this package doesn’t need either!

[Bug tree-optimization/118004] New: missing -Wuninitialized for printf

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

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

Bug ID: 118004
   Summary: missing -Wuninitialized for printf
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic, false-negative
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 24639
  Target Milestone: ---

Take:
```
void f2() {
  char not_secret[7];
   __builtin_printf("f2 %s\n", not_secret);
}
```

There is missing Wuninitialized variable warning for not_secret here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/118004] missing -Wuninitialized for printf

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

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

--- Comment #1 from Andrew Pinski  ---
Forgot to mention this is forwarded from
https://www.reddit.com/r/gcc/comments/1hbxudm/no_warning_when_using_uninitialized_local_variable/
.

[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG

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

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

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

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

commit r15-6124-ge95bda027e0b81922c1bf44770674190bdf787e8
Author: Jonathan Wakely 
Date:   Mon Dec 9 17:35:24 2024 +

libstdc++: Skip redundant assertions in std::span construction [PR117966]

As PR c++/117966 shows, the Debug Mode checks cause a compilation error
for a global constexpr std::span. Those debug checks are redundant when
constructing from an array or a range, because we already know we have a
valid range and we know its size. Instead of delegating to the
std::span(contiguous_iterator, contiguous_iterator) constructor, just
initialize the data members directly.

libstdc++-v3/ChangeLog:

PR libstdc++/117966
* include/std/span (span(T (&)[N])): Do not delegate to
constructor that performs redundant checks.
(span(array&), span(const array&)): Likewise.
(span(Range&&), span(const span&)): Likewise.
* testsuite/23_containers/span/117966.cc: New test.

[Bug c++/85944] Address of temporary at global scope not considered constexpr

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

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

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

https://gcc.gnu.org/g:9616deb23a17ebe81ad89ede191d7f9f752abdec

commit r15-6126-g9616deb23a17ebe81ad89ede191d7f9f752abdec
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG

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

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

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

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

commit r15-6125-g3aeb2edee2f9fc39ab77c7e020f09d7204b167ac
Author: Jonathan Wakely 
Date:   Mon Dec 9 17:35:24 2024 +

libstdc++: Skip redundant assertions in std::array equality [PR106212]

As PR c++/106212 shows, the Debug Mode checks cause a compilation error
for equality comparisons involving std::array prvalues in constant
expressions. Those Debug Mode checks are redundant when
comparing two std::array objects, because we already know we have a
valid range. We can also avoid the unnecessary step of using
std::__niter_base to do __normal_iterator unwrapping, which isn't needed
because our std::array iterators are just pointers. Using
std::__equal_aux1 instead of std::equal avoids the redundant checks in
std::equal and std::__equal_aux.

libstdc++-v3/ChangeLog:

PR libstdc++/106212
* include/std/array (operator==): Use std::__equal_aux1 instead
of std::equal.
* testsuite/23_containers/array/comparison_operators/106212.cc:
New test.

[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:9616deb23a17ebe81ad89ede191d7f9f752abdec

commit r15-6126-g9616deb23a17ebe81ad89ede191d7f9f752abdec
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:9616deb23a17ebe81ad89ede191d7f9f752abdec

commit r15-6126-g9616deb23a17ebe81ad89ede191d7f9f752abdec
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:9616deb23a17ebe81ad89ede191d7f9f752abdec

commit r15-6126-g9616deb23a17ebe81ad89ede191d7f9f752abdec
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

[Bug libstdc++/109976] error: is not a constant expression in std::equal() with _GLIBCXX_DEBUG

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

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

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

https://gcc.gnu.org/g:9616deb23a17ebe81ad89ede191d7f9f752abdec

commit r15-6126-g9616deb23a17ebe81ad89ede191d7f9f752abdec
Author: Jonathan Wakely 
Date:   Tue Dec 10 10:56:41 2024 +

libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517]

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.

[Bug rtl-optimization/110791] [12/13/14/15 Regression] arm: Wrong code with -Os -march=armv8.1-m.main (maybe fmodulo-sched related)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Wilco from comment #6)
> 
> The bug happens on all targets with -fmodulo-sched -Os, eg. AArch64:

fmodulo-sched requires doloop form loops so on arm and aarch64, doloop is only
enabled with fmodulo-sched. I wonder if this was fixed with the fix for doloop:
r15-5940 (PR113994).

[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check sometimes missing since r12-151

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 59835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59835&action=edit
gcc15-pr115127.patch

Untested fix.

[Bug rtl-optimization/117999] libgo regressions on arm after g:75e7d1600f47859df40b2ac0feff5a71e0dbb040

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

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #1 from Vladimir Makarov  ---
GCC GO is/was broken on ARM.  There were a lot of other GO test failures
including some crypto too.

I think start commit (not given one) resulted in the first GO test failure
should be a starting point to work on the failures.

[Bug rtl-optimization/116778] [lra][avr] Wrong code with -mlra (bitfld-lra.c)

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r15-6122-gfca0ab08cd936464b152e9b45356f625eba27575
Author: Vladimir N. Makarov 
Date:   Wed Dec 11 15:36:21 2024 -0500

[PR116778][LRA]: Check pseudos assigned to FP after rematerialization to
build live ranges

This is a better fix of the PR permitting to avoid building live
ranges after rematerialization.  It checks that FP can not be
eliminated now and that pseudos assigned to FP will be spilled.  In
this case we need to build live ranges after rematerialization for
correct assignments of stack slots to spilled pseudos involved in
rematerialization.

gcc/ChangeLog:

PR rtl-optimization/116778
* ira-int.h (x_ira_class_hard_reg_index): Fix comment typo.
* lra-eliminations.cc (lra_fp_pseudo_p): New function.
* lra-int.h (lra_fp_pseudo_p): External declaration.
* lra-spills.cc (lra_need_for_spills_p): Fix formatting.
* lra.cc (lra): Use lra_fp_pseudo_p in lra_create_live_range after
lra_remat.

[Bug ada/117956] assertion failure on 'Old in post-condition with -gnat2022

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|assertion failure in|assertion failure on 'Old
   |precondition of Sinfo.Nodes |in post-condition with
   |with -gnatX |-gnat2022
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
  Build|x86_64-apple-darwin |
   Keywords|ice-checking|
   Host|x86_64-apple-darwin |
 Target|x86_64-apple-darwin |
 Status|NEW |ASSIGNED

--- Comment #3 from Eric Botcazou  ---
In fact -gnat2022 is already sufficient.  Investigating.

[Bug tree-optimization/114932] IVopts inefficient handling of signed IV used for addressing.

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

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

--- Comment #18 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r15-6104-g3c32575e5b6370270d38a80a7fa8eaa144e083d0
Author: Tamar Christina 
Date:   Wed Dec 11 11:45:36 2024 +

middle-end: refactor type to be explicit in operand_equal_p  [PR114932]

This is a refactoring with no expected behavioral change.
The goal with this is to make the type of the expressions being used
explicit.

I did not change all the recursive calls to operand_equal_p () to recurse
directly to the new function but instead this goes through the top level
call
which re-extracts the types.

This was done because in most of the cases where we recurse type == arg.
The second patch makes use of this new flexibility to implement an overload
of operand_equal_p which checks for equality under two's complement.

gcc/ChangeLog:

PR tree-optimization/114932
* fold-const.cc (operand_compare::operand_equal_p): Split into one
that
takes explicit type parameters and use that in public one.
* fold-const.h (class operand_compare): Add operand_equal_p private
overload.

[Bug fortran/102689] Segfault with RESHAPE of CLASS as actual argument

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
The new test class_transformational_2.f90 fails on arm-linux-gnueabihf:
FAIL: gfortran.dg/class_transformational_2.f90 -O1  execution test
FAIL: gfortran.dg/class_transformational_2.f90 -O2  execution test
FAIL: gfortran.dg/class_transformational_2.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/class_transformational_2.f90 -O3 -g  execution test


The log says:
STOP 12
FAIL: gfortran.dg/class_transformational_2.f90   -O1  execution test
etc...

[Bug regression/117995] Regression in libphobos tests on arm after g:0547dbb725b6d8e878a79e28a2e171eafcfbc1aa

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
See PR117832

[Bug ada/117996] New: Failed precondition when computing Eigenvalues (using "-gnata")

[reinert.korsnes at online dot no via Gcc-bugs]

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

Bug ID: 117996
   Summary: Failed precondition when computing Eigenvalues (using
"-gnata")
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reinert.korsnes at online dot no
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

I use gnat_native=13.2.1

Given the following program:
---
pragma Ada_2022;
with ada.numerics.generic_real_arrays;
with Ada.Text_IO;
procedure test1 is
  package gra is new ada.numerics.generic_real_arrays (real => float);
  use gra;
  a : constant real_matrix(1..2,1..2) := [[1.0, 0.0], [0.0, 2.0]];
  e : constant real_vector :=  Eigenvalues(a);
begin
  for i in e'Range loop
 Ada.Text_IO.Put_Line(i'Image & e(i)'Image);
  end loop;
end test1;
---

Compiling with the options:
for Default_Switches ("ada") use ("-gnatwa", "-gnata", "-gnatX0");

I get:
raised ADA.ASSERTIONS.ASSERTION_ERROR : failed precondition from
s-gearop.ads:549 instantiated at a-ngrear.adb:78 instantiated at test1.adb:5

[Bug libstdc++/117998] New: : views::counted misses difference casting for contiguous_iterator case

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 117998
   Summary: : views::counted misses difference casting for
contiguous_iterator case
   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: ---

template
  constexpr auto
  operator() [[nodiscard]] (_Iter __i, iter_difference_t<_Iter> __n) const
  {
if constexpr (contiguous_iterator<_Iter>)
  return span(std::to_address(__i), __n);


We should static_cast n to type size_t:

https://godbolt.org/z/eM6cWsTeq

#include 

struct ContiguousIter {
  using iterator_category = std::contiguous_iterator_tag;
  using difference_type = std::ranges::__detail::__max_diff_type;
  using element_type = char;
  element_type& operator*() const;
  ContiguousIter& operator++();
  ContiguousIter operator++(int);
  ContiguousIter& operator--();
  ContiguousIter operator--(int);
  ContiguousIter& operator+=(difference_type);
  ContiguousIter& operator-=(difference_type);
  element_type* operator->() const;
  element_type& operator[](difference_type) const;
  friend ContiguousIter operator+(ContiguousIter, difference_type);
  friend ContiguousIter operator+(difference_type, ContiguousIter);
  friend ContiguousIter operator-(ContiguousIter, difference_type);
  friend difference_type operator-(ContiguousIter, ContiguousIter);
  auto operator<=>(const ContiguousIter&) const = default;
};

int main() {
  ContiguousIter it;
  std::ranges::contiguous_range auto r = std::views::counted(it, 42);
}

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r15-6109-gb6242bd122757ec6c75c73a4921f24a9a382b090
Author: Victor Do Nascimento 
Date:   Wed Dec 11 12:00:58 2024 +

middle-end: Add initial support for poly_int64 BIT_FIELD_REF in expand pass
[PR96342]

While `poly_int64' has been the default representation of  bitfield size
and offset for some time, there was a lack of support for the use of
non-constant `poly_int64' values for those values throughout the
compiler, limiting the applicability of the BIT_FIELD_REF rtl expression
for variable length vectors, such as those used by SVE.

This patch starts work on extending the functionality of relevant
functions in the expand pass such as to enable their use by the compiler
for such vectors.

gcc/ChangeLog:

PR target/96342
* expr.cc (store_constructor): Enable poly_{u}int64 type usage.
(get_inner_reference): Ditto.

Co-authored-by: Tamar Christina 

[Bug preprocessor/117977] [12/13/14/15 Regression] duplicated warnings output for _Pragma GCC warning with macros

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think getting the warning twice is correct when the macro uses it twice.

[Bug tree-optimization/114932] IVopts inefficient handling of signed IV used for addressing.

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

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

--- Comment #19 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:9403b035befe3537c343f7430e321468c0f2c28b

commit r15-6105-g9403b035befe3537c343f7430e321468c0f2c28b
Author: Tamar Christina 
Date:   Wed Dec 11 11:47:49 2024 +

middle-end: use two's complement equality when comparing IVs during
candidate selection  [PR114932]

IVOPTS normally uses affine trees to perform comparisons between different
IVs,
but these seem to have been missing in two key spots and instead normal
tree
equivalencies used.

In some cases where we have a two-complements equivalence but not a strict
signedness equivalencies we end up generating both a signed and unsigned IV
for
the same candidate.

This patch implements a new OEP flag called OEP_ASSUME_WRAPV.  This flag
will
check if the operands would produce the same bit values after the
computations
even if the final sign is different.

This happens quite a lot with Fortran but can also happen in C because this
came
code is unable to figure out when one expression is a multiple of another.

As an example in the attached testcase we get:

Initial set of candidates:
  cost: 24 (complexity 3)
  reg_cost: 9
  cand_cost: 15
  cand_group_cost: 0 (complexity 3)
  candidates: 1, 6, 8
   group:0 --> iv_cand:6, cost=(0,1)
   group:1 --> iv_cand:1, cost=(0,0)
   group:2 --> iv_cand:8, cost=(0,1)
   group:3 --> iv_cand:8, cost=(0,1)
  invariant variables: 6
  invariant expressions: 1, 2

:
inv_expr 1: stride.3_27 * 4
inv_expr 2: (unsigned long) stride.3_27 * 4

These end up being used in the same group:

Group 1:
cand  costcompl.  inv.expr.   inv.vars
1 0   0   NIL;6
2 0   0   NIL;6
3 0   0   NIL;6

which ends up with IV opts picking the signed and unsigned IVs:

Improved to:
  cost: 24 (complexity 3)
  reg_cost: 9
  cand_cost: 15
  cand_group_cost: 0 (complexity 3)
  candidates: 1, 6, 8
   group:0 --> iv_cand:6, cost=(0,1)
   group:1 --> iv_cand:1, cost=(0,0)
   group:2 --> iv_cand:8, cost=(0,1)
   group:3 --> iv_cand:8, cost=(0,1)
  invariant variables: 6
  invariant expressions: 1, 2

and so generates the same IV as both signed and unsigned:

;;   basic block 21, loop depth 3, count 214748368 (estimated locally, freq
58.2545), maybe hot
;;prev block 28, next block 31, flags: (NEW, REACHABLE, VISITED)
;;pred:   28 [always]  count:23622320 (estimated locally, freq
6.4080) (FALLTHRU,EXECUTABLE)
;;25 [always]  count:191126046 (estimated locally, freq
51.8465) (FALLTHRU,DFS_BACK,EXECUTABLE)
  # .MEM_66 = PHI <.MEM_34(28), .MEM_22(25)>
  # ivtmp.22_41 = PHI <0(28), ivtmp.22_82(25)>
  # ivtmp.26_51 = PHI 
  # ivtmp.28_90 = PHI 

...

;;   basic block 24, loop depth 3, count 214748366 (estimated locally, freq
58.2545), maybe hot
;;prev block 22, next block 25, flags: (NEW, REACHABLE, VISITED)'
;;pred:   22 [always]  count:95443719 (estimated locally, freq
25.8909) (FALLTHRU)
;;21 [33.3% (guessed)]  count:71582790 (estimated locally,
freq 19.4182) (TRUE_VALUE,EXECUTABLE)
;;31 [33.3% (guessed)]  count:47721860 (estimated locally,
freq 12.9455) (TRUE_VALUE,EXECUTABLE)
# .MEM_22 = PHI <.MEM_44(22), .MEM_31(21), .MEM_79(31)>
ivtmp.22_82 = ivtmp.22_41 + 1;
ivtmp.26_72 = ivtmp.26_51 + _80;
ivtmp.28_98 = ivtmp.28_90 + _39;

These two IVs are always used as unsigned, so IV ops generates:

  _73 = stride.3_27 * 4;
  _80 = (unsigned long) _73;
  _54 = (unsigned long) stride.3_27;
  _39 = _54 * 4;

Which means that in e.g. exchange2 we generate a lot of duplicate code.

This is because candidate 6 and 8 are equivalent under two's complement but
have
different signs.

This patch changes it so that if you have two IVs that are affine
equivalent to
just pick one over the other.  IV already has code for this, so the patch
just
uses affine trees instead of tree for the check.

With it we get:

:
inv_expr 1: stride.3_27 * 4

:
Group 0:
  cand  costcompl.  inv.expr.   inv.vars
  5 0   2   NIL;NIL;
  6 0   3   NIL;NIL;

Group 1:
  cand  costcompl.  inv.expr.   inv.vars
  1 0   0   NIL;6
  2 0   0   NIL;6
  3 0   0   NIL;6
  4 0   0   NIL;6

Initial set of candidates:
  cost: 16 (complexity 3)
  reg_cost: 6
  cand_cost: 10
  cand_group_cost: 0 (complexity 3)
  candidates: 1, 6
   group:0 --> iv_cand:6, cost=(0,3)
   group:1 --> iv_cand:1, cost=(0,0)
  invariant variables

[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior

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

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

--- Comment #53 from Jonathan Wakely  ---
(In reply to Ed Catmur from comment #9)
> If I'm reading P0593 correctly (I may not be), this would be a valid
> implementation of start_lifetime_as:
> 
> template
> inline T* start_lifetime_as(void* p) {
> std::byte storage[sizeof(T)];
> std::memcpy(storage, p, sizeof(T));
> auto q = new (p) std::byte[sizeof(T)];
> std::memcpy(q, storage, sizeof(T));
> auto t = reinterpret_cast(q);
> return std::launder(t);
> }


I don't think this is correct, because it accesses the bytes (reading and
writing them) which is not allowed ("the storage is not accessed). Implementing
it this way would be a data race if two threads both use start_lifetime_as on
the same memory at the same time.

All of s1, s2 and s3 in the OP have the same problem.

(In reply to Richard Smith from comment #20)
> No, the new objects are allowed to replace existing objects. For example,
> this implementation would also be correct:
> 
> std::uint64_t* s3(double* p) {
> std::memmove(p, p, sizeof(double));
> return std::launder(reinterpret_cast(p));
> }

This works if and only if memmove(p, p, n) is optimized to not actually read or
write any bytes (but still has the correct semantics of implicitly creating
objects). If it's not optimized to not access the storage then it's a data
race, and can't be used for the std::start_lifetime_as(const T*) overload.

> ... on the basis that it has defined behavior if the memmove implicitly
> creates an 'uint64_t' object in the underlying storage after it (notionally)
> copies the contents elsewhere and before it (notionally) copies the contents
> back again. (The 'launder' is necessary in order to form a pointer to the
> implicitly-created uint64_t object, because p doesn't point to that object.)

Couldn't you avoid the launder by returning static_cast(memmove(p, p,
sizeof(T))) instead? That pointer _does_ point to the new object, doesn't it?
... huh, no, memcpy and memmove do not return a pointer to a suitable created
object. Seems like they could/should.

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r15-6108-gd069eb91d5696a8642bd5fc44a6d47fd7f74d18b
Author: Victor Do Nascimento 
Date:   Wed Dec 11 12:00:09 2024 +

middle-end: add vec_init support for variable length subvector
concatenation. [PR96342]

For architectures where the vector-length is a compile-time variable,
rather representing a runtime constant, as is the case with SVE it is
perfectly reasonable that such vector be made up of two (or more) subvector
components of a compatible sub-length variable.

One example of this would be the concatenation of two VNx4QI vectors
into a single VNx8QI vector.

This patch adds initial support for the enablement of this feature in
the middle-end, removing the `.is_constant()' constraint on the vector's
number of elements, instead making the constant no. of elements the
multiple of the number of subvectors (which must then also be of
variable length, such that their polynomial ratio then results in a
compile-time constant) required to fill the vector.

gcc/ChangeLog:

PR target/96342
* expr.cc (store_constructor): add support for variable-length
vectors.

Co-authored-by: Tamar Christina 

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:240cbd2f26c0f1c1f83cfc3b69cc0271b56172e2

commit r15-6107-g240cbd2f26c0f1c1f83cfc3b69cc0271b56172e2
Author: Victor Do Nascimento 
Date:   Wed Dec 11 11:58:55 2024 +

middle-end: Fix mask length arg in call to vect_get_loop_mask [PR96342]

When issuing multiple calls to a simdclone in a vectorized loop,
TYPE_VECTOR_SUBPARTS(vectype) gives the incorrect number when compared
to the TYPE_VECTOR_SUBPARTS result we get from the mask type derived
from the relevant `rgroup_controls' entry within `vect_get_loop_mask'.

By passing `masktype' instead, we are able to get the correct number of
vector subparts and thu eliminate the ICE in the call to
`vect_get_loop_mask' when the data type for which we retrieve the mask
is wider than the one used when defining the mask at mask registration
time.

gcc/ChangeLog:

PR target/96342
* tree-vect-stmts.cc (vectorizable_simd_clone_call):
s/vectype/masktype/ in call to vect_get_loop_mask.

[Bug target/96342] [SVE] Add support for "omp declare simd"

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:561ef7c8477ba58ea64de259af9c2d0870afd9d4

commit r15-6106-g561ef7c8477ba58ea64de259af9c2d0870afd9d4
Author: Andre Vieira 
Date:   Wed Dec 11 11:50:22 2024 +

middle-end: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE [PR96342]

This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the
target can reject a simd_clone based on the vector mode it is using.
This is needed because for VLS SVE vectorization the vectorizer accepts
Advanced SIMD simd clones when vectorizing using SVE types because the
simdlens
might match.  This will cause type errors later on.

Other targets do not currently need to use this argument.

gcc/ChangeLog:

PR target/96342
* target.def (TARGET_SIMD_CLONE_USABLE): Add argument.
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Pass stmt_info
to
call TARGET_SIMD_CLONE_USABLE.
* config/aarch64/aarch64.cc (aarch64_simd_clone_usable): Add
argument
and use it to reject the use of SVE simd clones with Advanced SIMD
modes.
* config/gcn/gcn.cc (gcn_simd_clone_usable): Add unused argument.
* config/i386/i386.cc (ix86_simd_clone_usable): Likewise.
* doc/tm.texi: Regenerate

Co-authored-by: Victor Do Nascimento 
Co-authored-by: Tamar Christina 

[Bug c++/96977] mangling ‘typeof’ or use ‘decltype’

[2002luvabbaluvu at gmail dot com via Gcc-bugs]

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

Swudu Susuwu <2002luvabbaluvu at gmail dot com> changed:

   What|Removed |Added

 CC||2002luvabbaluvu at gmail dot 
com

--- Comment #1 from Swudu Susuwu <2002luvabbaluvu at gmail dot com> ---
Had to switch from `typeof` to `decltype` due to this:
https://github.com/SwuduSusuwu/SubStack/commit/a109efbe4ff8336b062e17ce63bdde9732d3d43d
shows regular expression + before and after comparisons of code, hope that has
use to you.

[Bug c++/96977] mangling ‘typeof’ or use ‘decltype’

[2002luvabbaluvu at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Swudu Susuwu <2002luvabbaluvu at gmail dot com> ---
If the diff won't load, here is te regular expression which was used to fix
this;
`%s/typeof \(.*\)/decltype(\1)/`. The general form is `%s/typeof
\(.*<.*>\)/decltype(\1)/`

[Bug gcov-profile/116743] [12/13/14/15 regression] Commit r12-5817-g3d9e6767939e96 causes ~10% perf regression w AutoFDO

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #21 from Rama Malladi  ---
Hi Eugene,
We verified that the GCC patch restores the PGO performance gain. The HammerDB
workload shows an 11% PGO performance gain with the fix, compared to a 2% gain
without the fix.

Thanks for the fix. Can you please commit this change and back-port to 12, 13,
14?
-Rama

[Bug libfortran/117819] Formatted READ with BZ in format fails

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
Fixed on 14 branch. The cherry pick was manually merged because the 14 branch
does not include the unsigned integer portion which is new in 15.

[Bug gcov-profile/116743] [12/13/14/15 regression] Commit r12-5817-g3d9e6767939e96 causes ~10% perf regression w AutoFDO

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #22 from Eugene Rozenfeld  ---
Rama, thank you for confirming this fixes your perf regression. I'll be on
vacation for the rest of December but will get this completed and ported after
New Year.

[Bug c++/117985] [12/13/14/15 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3308

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

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

--- Comment #4 from Marek Polacek  ---
I think this uncovered a latent bug, one probably fixable by:

--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -5109,6 +5109,8 @@ build_vec_init (tree base, tree maxindex, tree init,
 {
   if (!saw_non_const)
{
+ if (cleanup_flags)
+   vec_safe_truncate (*cleanup_flags, 0);
  tree const_init = build_constructor (atype, const_vec);
  return build2 (INIT_EXPR, atype, obase, const_init);
}

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Jennifer Schmitz from comment #10)

See PR 113265 for a start of a patch. I didn't have time to finish it up yet.

[Bug target/117994] New: New failures on arm since g:f55cc57c6e3bcb36279682254b9b532049ff3f9d

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

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

Bug ID: 117994
   Summary: New failures on arm since
g:f55cc57c6e3bcb36279682254b9b532049ff3f9d
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
CC: azoff at gcc dot gnu.org
  Target Milestone: ---

Since commit
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f55cc57c6e3bcb36279682254b9b532049ff3f9d
 we have noticed new failures when testing for cortex-m0, m23, m33, m3, m55 and
m7.

These tests were unsupported before the patch, so this is not a regression.

FAIL: gcc.target/arm/small-multiply-m0-1.c scan-assembler-not [\\t ]+mul
FAIL: gcc.target/arm/small-multiply-m0-3.c scan-assembler-not [\\t ]+mul
FAIL: gcc.target/arm/small-multiply-m0plus-1.c scan-assembler-not [\\t ]+mul
FAIL: gcc.target/arm/small-multiply-m0plus-3.c scan-assembler-not [\\t ]+mul
FAIL: gcc.target/arm/small-multiply-m1-1.c scan-assembler-not [\\t ]+mul
FAIL: gcc.target/arm/small-multiply-m1-3.c scan-assembler-not [\\t ]+mul

[Bug driver/117992] gcc -flto -fharden leads to warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The warning is weird, any_link_options_p is set when -r, -shared, -no-pie or
-pie is seen and static_p is set when -static is seen.  And when any of that is
seen (defaulted or not), -Whardened warns.
Now, surely LD_PIE_SPEC shouldn't be added if any of those are seen.
Why isn't -z now and/or -z relro added when -static isn't seen isn't clear to
me, those
options make perfect sense even for -shared, or -no-pie or explicit (or
defaulted) -pie.  -r doesn't really need those.
Warning that we didn't add -pie because one supplied it explicitly is just
weird.
Similarly warning when -shared is seen, -shared doesn't remove any of the
hardening properties.  Similarly -r.  So I'd just warn if -static or -no-pie
was seen.
Do we warn with -fhardened if one uses explicit -fstack-protector-strong with
it?

[Bug driver/117992] gcc -flto -fharden leads to warning

[icenowy at aosc dot io via Gcc-bugs]

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

--- Comment #4 from Icenowy Zheng  ---
I don't think this issue is similar to 117739 , because in my case I didn't
pass any parameters that are known to be negated by -fhardened -- there's at
least no document that -fhardened will affect -flto.

```
icenowy@edelgard [ ~ ] $ gcc --help=hardened
The following options are enabled by -fhardened:
  -D_FORTIFY_SOURCE=3 (or =2 for glibc < 2.35)
  -D_GLIBCXX_ASSERTIONS
  -ftrivial-auto-var-init=zero
  -fPIE  -pie
  -Wl,-z,now
  -Wl,-z,relro
  -fstack-protector-strong
  -fstack-clash-protection
  -fcf-protection=full
```

Nothing here should clash with -flto, right?

[Bug driver/117992] gcc -flto -fharden leads to warning

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---
The root cause is:

$ LANG= gcc hw.c -Whardened -fhardened -O2 -pie
cc: warning: linker hardening options not enabled by '-fhardened' because other
link options were specified on the command line

Hmm why should -pie (not -no-pie) suppress -fhardened?

[Bug c++/117983] [13/14 Regression] -Wstringop-overflow false positive for __builtin_memmove from vector::insert

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

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

--- Comment #3 from Jonathan Wakely  ---
Yes that was my first thought too

[Bug c++/117993] [15 regression] this->x is being rejected in a nested template class with a base of class of the outer templated class since r15-2117

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/117993] [15 regression] this->x is being rejected in a nested template class with a base of class of the outer templated class since r15-2117

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[15 regression] this->x is  |[15 regression] this->x is
   |being rejected in a nested  |being rejected in a nested
   |template class with a base  |template class with a base
   |of class of the outer   |of class of the outer
   |templated class |templated class since
   ||r15-2117
 CC||ppalka at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #5 from Jakub Jelinek  ---
Indeed, this started with r15-2117-g313afcfdabeab3e6705ac0bd1273627075be0023

[Bug regression/117995] New: Regression in libphobos tests on arm after g:0547dbb725b6d8e878a79e28a2e171eafcfbc1aa

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

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

Bug ID: 117995
   Summary: Regression in libphobos tests on arm after
g:0547dbb725b6d8e878a79e28a2e171eafcfbc1aa
   Product: gcc
   Version: 15.0
   URL: https://linaro.atlassian.net/browse/GNU-1444
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
CC: jakub at redhat dot com
  Target Milestone: ---
Target: arm

As reported in
https://gcc.gnu.org/pipermail/gcc-regression/2024-December/081418.html , the
Linaro CI detected a regression on arm in libphobos tests after commit
g:0547dbb725b6d8e878a79e28a2e171eafcfbc1aa

Running libphobos:libphobos.phobos/phobos.exp ...
FAIL: libphobos.phobos/std/experimental/allocator/showcase.d execution test

on arm-linux-gnueabihf, the logs say:
PASS: libphobos.phobos/std/experimental/allocator/showcase.d (test for excess
errors)
Setting LD_LIBRARY_PATH to
.:/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/gcc:/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/armv8l-unknown-linux-gnueabihf/./libphobos/src/.libs:.:/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/gcc:/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gcc-gcc.git~master-stage2/armv8l-unknown-linux-gnueabihf/./libphobos/src/.libs:
Execution timeout is: 300
Running on tcwg-local: timeout -k 30s 330s ./showcase.exe 
spawn [open ...]
core.exception.AssertError@/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/testsuite/../src/std/experimental/allocator/showcase.d(92):
unittest failure

/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/deh.d:51
_d_createTrace [0x20139]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/gcc/deh.d:484
_d_throw [0x1a46f]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/core/exception.d:587
onAssertErrorMsg [0x1db7b]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/core/exception.d:604
onUnittestErrorMsg [0x1db99]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/core/exception.d:826
_d_unittest [0x1dbeb]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/testsuite/../src/std/experimental/allocator/showcase.d:92
void std.experimental.allocator.showcase.__unittest_L88_C9() [0x18789]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/core/runtime.d:657
__foreachbody6 [0x29c3b]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/minfo.d:591
__foreachbody2 [0x21dd9]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/gcc/sections/elf.d:106
int gcc.sections.elf.DSO.opApply(scope int delegate(ref gcc.sections.elf.DSO))
[0x1b4d1]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/minfo.d:584
int rt.minfo.moduleinfos_apply(scope int
delegate(immutable(object.ModuleInfo*))) [0x22891]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/object.d:2458
int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x24ddd]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/core/runtime.d:645
runModuleUnitTests [0x2a02d]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/dmain2.d:506
runAll [0x1b0af]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/dmain2.d:473
tryExec [0x1b24b]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/dmain2.d:544
_d_run_main2 [0x1b24b]
/home/tcwg-buildslave/workspace/tcwg_gnu_5/abe/snapshots/gcc.git~master/libphobos/libdruntime/rt/dmain2.d:324
_d_run_main [0x1b32b]
../sysdeps/nptl/libc_start_call_main.h:58 __libc_start_call_main [0xf7ded7d5]
./csu/libc-start.c:392 __libc_start_main_impl [0xf7ded885]
1/1 modules FAILED unittests
FAIL: libphobos.phobos/std/experimental/allocator/showcase.d execution test

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #6 from Alejandro Colomar  ---
(In reply to Sam James from comment #3)
> The boundary doesn't exist if it's being inlined.

[[gnu::noipa]] is stronger and prevents any inlining (it's basically telling
the compiler to ignore 'inline').  So, [[gnu::noipa]] enforces the boundary,
even if I'm using the inline keyword.

[Bug c/118005] New: Incorrect diagnostic combining [[gnu::noipa]] and inline

[alx at kernel dot org via Gcc-bugs]

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

Bug ID: 118005
   Summary: Incorrect diagnostic combining [[gnu::noipa]] and
inline
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alx at kernel dot org
  Target Milestone: ---

Hi,

I use [[gnu::noipa]] in (C99) inline functions for the following reasons:

Within my library, the functions are inline, for an optimized library.
In the exported headers, I add the [[gnu::noipa]] attribute to the inline
functions, so that users don't get anything inline, which provides a strong
interface boundary, so that if any bugs are found in the library, fixing the
.so is enough, and the world doesn't need to be recompiled.

So, I provide inline definitions, but in the user code, a macro will add the
attribute to invalidate 'inline'.

This results in the following diagnostic:

$ gcc --version | head -n1
gcc (Debian 14.2.0-8) 14.2.0
$ cat inline.c 
[[gnu::noipa]] inline int f(void);

inline int f(void)
{
return 42;
}
$ gcc -Wall -Wextra -S inline.c 
inline.c:1:27: warning: inline function ‘f’ given attribute ‘noinline’
[-Wattributes]
1 | [[gnu::noipa]] inline int f(void);
  |   ^
inline.c:4:1: warning: inline declaration of ‘f’ follows declaration with
attribute ‘noinline’ [-Wattributes]
4 | {
  | ^
inline.c:1:27: note: previous declaration of ‘f’ with type ‘int(void)’
1 | [[gnu::noipa]] inline int f(void);
  |   ^


This diagnostic is wrong, because it thinks I'm using [[gnu::noinline]], while
I'm actually using [[gnu::noipa]].

Also, I would like to have a more precise know to disable this diagnostic,
without having to turn off the entire -Wattributes.  How about
-Wattributes-noinline-on-inline-func and/or -Wattributes-noipa-on-inline-func?

Or maybe just remove this diagnostic?  I don't think it's very useful.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #10 from Alejandro Colomar  ---
(In reply to Sam James from comment #9)
> If they're internals, building the library with LTO and correct visibility
> annotations should handle that for you if you mean "I want inlining
> internally, but not for consumers".

I prefer inline over LTO.  inline gives extra information to static analyzers,
which gives me more confidence in the correctness of the code.  LTO only gives
optimization, while I consider inline most important due to the diagnostics,
and only secondarily as an optimization feature.

Yeah, -fanalyzer might be able to warn about some things when combined with
LTO, but that's much less powerful than compile-time analyzers with inline
functions.

And yes, I'm using visibility attributes as appropriate.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

--- Comment #3 from Sam James  ---
The boundary doesn't exist if it's being inlined.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

--- Comment #7 from Sam James  ---
(In reply to Alejandro Colomar from comment #6)
> (In reply to Sam James from comment #3)
> > The boundary doesn't exist if it's being inlined.
> 
> [[gnu::noipa]] is stronger and prevents any inlining (it's basically telling
> the compiler to ignore 'inline').  So, [[gnu::noipa]] enforces the boundary,
> even if I'm using the inline keyword.

Then it's not inline. My point is that your original intention is invalid, it
doesn't make any sense.

Now, should we diagnose noipa+inline explicitly? Yes. But your original usecase
doesn't make sense at all.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #12 from Alejandro Colomar  ---
(In reply to Sam James from comment #11)
> Perhaps it makes sense to only set these when building under a static
> analyser then.

GCC does itself have some static analysing features via compiler diagnostics,
so I want it to have as much information as possible.  (This is also why I
compile in a loop at all different optimization levels, to have more of them.)

Also, I don't consider it a good idea to analyze code that is different than
the one being actually compiled.  Thus, I very much prefer having inline all
the time.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

--- Comment #11 from Sam James  ---
Perhaps it makes sense to only set these when building under a static analyser
then.

[Bug rtl-optimization/117999] [15 regression] libgo regressions on arm after g:75e7d1600f47859df40b2ac0feff5a71e0dbb040

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||needs-bisection

[Bug d/117995] [15 regression] Regression in libphobos tests on arm after g:0547dbb725b6d8e878a79e28a2e171eafcfbc1aa

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||testsuite-fail
Summary|Regression in libphobos |[15 regression] Regression
   |tests on arm after  |in libphobos tests on arm
   |g:0547dbb725b6d8e878a79e28a |after
   |2e171eafcfbc1aa |g:0547dbb725b6d8e878a79e28a
   ||2e171eafcfbc1aa

[Bug rtl-optimization/118006] New: ICE when building rr-5.8.0 with -fstrub=all (RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1499)

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

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

Bug ID: 118006
   Summary: ICE when building rr-5.8.0 with -fstrub=all (RTL
check: expected elt 2 type 'B', have '0' (rtx barrier)
in BLOCK_FOR_INSN, at rtl.h:1499)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-checking
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

```
$ gcc ./CMakeFiles/rrpreload_32.dir/32/preload/syscallbuf.c.i -m32 -c
-fstrub=all -O2
during RTL pass: expand
/var/tmp/portage/dev-util/rr-5.8.0/work/rr-5.8.0_build/32/preload/syscallbuf.c:
In function ‘privileged_traced_raise.constprop’:
/var/tmp/portage/dev-util/rr-5.8.0/work/rr-5.8.0_build/32/preload/syscallbuf.c:428:1:
internal compiler error: RTL check: expected elt 2 type 'B', have '0' (rtx
barrier) in BLOCK_FOR_INSN, at rtl.h:1499
  428 | }
  | ^
0x55a58173d1c6 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x55a58163a3e8 internal_error(char const*, ...)
???:0
0x55a580e1ef84 rtl_check_failed_type1(rtx_def const*, int, int, char const*,
int, char const*)
???:0
0x55a58192a001 verify_flow_info()
???:0
0x55a581b53d5b cleanup_cfg(int)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

---

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

[Bug rtl-optimization/118006] ICE when building rr-5.8.0 with -fstrub=all (RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1499)

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

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

--- Comment #1 from Sam James  ---
Created attachment 59836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59836&action=edit
syscallbuf.c.i.xz

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #2 from Alejandro Colomar  ---
(In reply to Andrew Pinski from comment #1)
> So noipa implies noinline.

Hmmm, I thought it could be considered something like
, where you're showing an
internal transformation.  Although in this case it doesn't hurt, since users of
noipa actually know that it implies noinline, so I guess it's okay-ish.

> The diagnostic is correct and is wanted.
> 
> On the question of using -Wattribute or it's own flag, I think we don't want
> to do that. Since the fix is to remove inline keywords.

Do you mean that I should never write a function is both inline and noipa?
Please allow me to disagree.  My actual code is something like the following:


// :
#if (FOO_INTERNAL)
#define foo_inline  inline
#else
#define foo_inline  inline [[gnu::noipa]]
#endif

foo_inline int foo(void);

inline int
foo(void)
{
return 42;
}


// foo.c
#define FOO_INTERNAL
#include "foo.h"

extern inline int foo(void);

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #4 from Alejandro Colomar  ---
Maaaybe I could do the following instead, I guess.  I will probably do it
anyway, for compatibility with old GCC versions.  I little bit more cpp(1), but
that's okay-ish too, I guess.


// :
#if (FOO_INTERNAL)
#define foo_inline  inline
#else
#define foo_inline
#endif

foo_inline int foo(void);

#if (FOO_INTERNAL)
inline int
foo(void)
{
return 42;
}
#endif


// foo.c
#define FOO_INTERNAL
#include "foo.h"

extern inline int foo(void);

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Incorrect diagnostic|Diagnostic for mixing noipa
   |combining [[gnu::noipa]]|and inline mentions nonline
   |and inline  |rather noipa

--- Comment #1 from Andrew Pinski  ---
So noipa implies noinline.

The diagnostic is correct and is wanted.

On the question of using -Wattribute or it's own flag, I think we don't want to
do that. Since the fix is to remove inline keywords.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Alejandro Colomar from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > So noipa implies noinline.
> 
> Hmmm, I thought it could be considered something like
> , where you're showing
> an internal transformation.  Although in this case it doesn't hurt, since
> users of noipa actually know that it implies noinline, so I guess it's
> okay-ish.


It is documented to imply it too.
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Function-Attributes.html#index-noipa-function-attribute

This attribute implies noinline, noclone and no_icf attributes.

[Bug target/117926] [14 Regression] emits 3dnow (MMX) instruction from autovectorized GIMPLE without emms at -O2 since r14-2786-gade30fad6669e5

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail|14.2.1  |14.2.0
  Known to work||14.2.1

--- Comment #12 from Sam James  ---
All done. Thanks!

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

--- Comment #13 from Andrew Pinski  ---
We have been warning about noinline and inline since the noinline attribute was
added back in r0-37987-g9162542e3d0cd2 .

When noipa was added (r8-2213-g036ea39917b0ef) we had the same warning there.

Since it is documented that noipa implies noinline attribute I am not sure if
there is anything to be done for this diagnostic either.


As far as the original thing dealing with boundaries go, having an function in
a public header even though marked as noipa and inline, the boundary does not
exist then because folks will do stuff to cause the noipa NOT being added.

[Bug c/118005] Diagnostic for mixing noipa and inline mentions nonline rather noipa

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

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

--- Comment #14 from Andrew Pinski  ---
You could put all of the internal functions in a header file which only gets
included for the internal case and not install that header file ...

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

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

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

--- Comment #22 from Sam James  ---
Are we keeping this one open for the improvement mentioned in
https://inbox.sourceware.org/gcc-patches/z1gdhpphod-5m...@fkdesktop.suse.cz/?

[Bug rtl-optimization/117999] [15 regression] libgo regressions on arm after r15-5997-g75e7d1600f4785

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |ra
Summary|[15 regression] libgo   |[15 regression] libgo
   |regressions on arm after|regressions on arm after
   |g:75e7d1600f47859df40b2ac0f |r15-5997-g75e7d1600f4785
   |eff5a71e0dbb040 |

--- Comment #2 from Andrew Pinski  ---
r15-5997-g75e7d1600f4785