[Bug libstdc++/108797] [10/11 Regression] libstdc++: Inconsistent noexcept-specifier for valarray begin/end

[holger.k at elberer dot de via Gcc-bugs]

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

--- Comment #2 from Holger Kaelberer  ---
I expected that. Just for reference: Where can I find release-planning for
specific releases/xxx branches of gcc?

[Bug libstdc++/108797] [10/11 Regression] libstdc++: Inconsistent noexcept-specifier for valarray begin/end

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||10.3.0, 11.3.0, 12.1.0,
   ||9.4.0
Summary|libstdc++: Inconsistent |[10/11 Regression]
   |noexcept-specifier for  |libstdc++: Inconsistent
   |valarray  begin/end |noexcept-specifier for
   ||valarray  begin/end
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.5
  Known to fail||10.4.0, 9.5.0

--- Comment #1 from Andrew Pinski  ---
The last GCC 9.x was GCC 9.5 released 2022-05-27.
The ship has sailed to apply patches to the GCC 9 branch now too.

Just for reference GCC 10 branch was applied r10-10910-g32bbf76e4345a7
GCC 11: r11-9264-g423cd47cfc9640 .

[Bug libstdc++/108797] New: libstdc++: Inconsistent noexcept-specific for valarray begin/end

[holger.k at elberer dot de via Gcc-bugs]

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

Bug ID: 108797
   Summary: libstdc++: Inconsistent noexcept-specific for valarray
 begin/end
   Product: gcc
   Version: 9.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: holger.k at elberer dot de
  Target Milestone: ---

The inconsistent noexcept specifier on valarray begin/end introduced in 
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=12f7864eff882cba2720d8871d8b136bd7a1d3cd
on releases/gcc-9 (bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103022)
was fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b2d97fc545635a0f6aa9c9ee3b017394bc494b
on master and backported to all (active) release branches except releases/gcc-9

Pls cherry-pick to releases/gcc-9 -- if still supported.

[Bug target/108738] compile-time and memory-hog in mdreorg

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-5995-ge1dfac7e71056e879f101fef1c5ecb8ff6be1a1f
Author: Richard Biener 
Date:   Thu Feb 9 13:40:43 2023 +0100

target/108738 - optimize bit operations in STV

The following does low-hanging optimizations, combining bitmap
test and set and removing redundant operations.

PR target/108738
* config/i386/i386-features.cc (scalar_chain::add_to_queue):
Combine bitmap test and set.
(scalar_chain::add_insn): Likewise.
(scalar_chain::analyze_register_chain): Remove redundant
attempt to add to queue and instead strengthen assert.
Sink common attempts to mark the def dual-mode.
(scalar_chain::add_to_queue): Remove redundant insn bitmap
check.

[Bug target/108738] compile-time and memory-hog in mdreorg

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-5994-gec23e9e25eb64bb066dc408fd498861b8587bec8
Author: Richard Biener 
Date:   Thu Feb 9 11:03:25 2023 +0100

target/108738 - STV bitmap operations compile-time hog

When the set of candidates becomes very large then repeated
bit checks on it during the build of an actual chain can become
slow because of the O(n) nature of bitmap tests.  The following
switches the candidates bitmaps to the tree representation before
building the chains to get O(log n) amortized behavior.

For the testcase at hand this improves STV time by 50%.

PR target/108738
* config/i386/i386-features.cc (convert_scalars_to_vector):
Switch candidates bitmaps to tree view before building the chains.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 15 Feb 2023, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107096
> 
> --- Comment #11 from Hongtao.liu  ---
> 
> > 
> > There's no other way to do N bit to two N/2 bit hi/lo (un)packing
> > (there's a 2x N/2 bit -> N bit operation, for whatever reason).
> > There's also no way to transform the d rgroup mask into the
> > f rgroup mask for the first example aka duplicate bits in place,
> > { b0, b1, b2, ... bN } -> { b0, b0, b1, b1, b2, b2, ... bN, bN },
> > nor the reverse.
> > 
> 
> Can we just do VIEW_CONVERT_EXPR for vectype instead of mask_type.
> .i.e
> we can do VCE to tranform V8SI to V16HI, then use mask_load for V16HI with 
> same
> mask {b0, b0, b1, b1, b2, b2, .}, then VCE it to back to V8SI, it should be ok
> as long as duplicated bits in place.(or VCE V16HI to V8SI then use mask {b0,
> b1, b2, ..., bN}, and VCE V8SI back to V16HI after masked load/move).

Hmm, yes, if we arrange for the larger mask to be available that would
work for loads and stores I guess.  It wouldn't work for arithmetic
cond_* IFNs though.  It's also going to be a bit tricky within the
masking framework - I'm going to see whether that works though, it might
be a nice way to avoid an excessive number of masks for integer code
at least.

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Hongtao.liu  ---

> 
> There's no other way to do N bit to two N/2 bit hi/lo (un)packing
> (there's a 2x N/2 bit -> N bit operation, for whatever reason).
> There's also no way to transform the d rgroup mask into the
> f rgroup mask for the first example aka duplicate bits in place,
> { b0, b1, b2, ... bN } -> { b0, b0, b1, b1, b2, b2, ... bN, bN },
> nor the reverse.
> 

Can we just do VIEW_CONVERT_EXPR for vectype instead of mask_type.
.i.e
we can do VCE to tranform V8SI to V16HI, then use mask_load for V16HI with same
mask {b0, b0, b1, b1, b2, b2, .}, then VCE it to back to V8SI, it should be ok
as long as duplicated bits in place.(or VCE V16HI to V8SI then use mask {b0,
b1, b2, ..., bN}, and VCE V8SI back to V16HI after masked load/move).

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---

> 
> There's no other way to do N bit to two N/2 bit hi/lo (un)packing
> (there's a 2x N/2 bit -> N bit operation, for whatever reason).
> There's also no way to transform the d rgroup mask into the
> f rgroup mask for the first example aka duplicate bits in place,
> { b0, b1, b2, ... bN } -> { b0, b0, b1, b1, b2, b2, ... bN, bN },
> nor the reverse.
> 

Can we just do VIEW_CONVERT_EXPR for vectype instead of mask_type.
.i.e
we can do VCE to tranform V8SI to V16HI, then use mask_load for V16HI with same
mask {b0, b0, b1, b1, b2, b2, .}, then VCE it to back to V8SI, it should be ok
as long as duplicated bits in place.(or VCE V16HI to V8SI then use mask {b0,
b1, b2, ..., bN}, and VCE V8SI back to V16HI after masked load/move).

[Bug c++/69585] [C++ 11] parser errors mixing alignas, C++ 11 and GNU attributes on class declaration

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

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

--- Comment #6 from Andrew Pinski  ---
I see this only changed the C++ front-end. sudo just ran into a similar issue
for the C front-end, see PR 108796.

[Bug c/108796] Can't intermix C2x and GNU style attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|GCC 13 accepts [[noreturn]] |Can't intermix C2x and GNU
   |attribute without -std=c2x  |style attributes

--- Comment #5 from Andrew Pinski  ---
Simple testcase: 
__attribute__((noreturn)) [[noreturn]]
void foo(void) {
while(true);
}

The C++ front-end accepts this but not the C front-end.

[Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Actually in this case it is slightly different.
Let me reopen it for a second.

[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sam at gentoo dot org

--- Comment #7 from Sam James  ---
*** Bug 108796 has been marked as a duplicate of this bug. ***

[Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #3 from Sam James  ---


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

[Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #2 from Sam James  ---
Sorry, for completeness, I meant to include:
```
$ gcc-12 -O2 /tmp/foo.c # ditto with -std=c89
/tmp/foo.c:3:1: warning: 'noreturn' attribute ignored [-Wattributes]
3 | [[noreturn]] void foo(void) {
  | ^
``

[Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Sam James  ---
I asked on #gcc and this is intentional, it seems.

[Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 108796
   Summary: GCC 13 accepts [[noreturn]] attribute without -std=c2x
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
  Target Milestone: ---

Created attachment 54462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54462=edit
foo.i

GCC 13 (13.0.1 20230212) seems to accept [[noreturn]] as an attribute even when
not in C2x mode. This leads to a build failure with sudo-1.9.13
(https://github.com/sudo-project/sudo/issues/239) since
https://github.com/sudo-project/sudo/commit/e707ffe58b3ccfe5c72f54c38eac1d7069d5021e.

Clang 16.0.0_rc2 does not accept it unless passing -std=c2x.

Is this intentional or not? Thanks.

foo.c:
```
#include 

[[noreturn]] void foo(void) {
abort();
}

int main() {
foo();
}
```

```
$ gcc-13 --version
gcc-13 (Gentoo Hardened 13.0.1_pre20230212 p8) 13.0.1 20230212 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-13 -std=c2x -O2 /tmp/foo.c # fine
$ gcc-13 -std=c99 -O2 /tmp/foo.c # fine
$ gcc-13 -O2 /tmp/foo.c -o /tmp/foo # fine

$ clang-16 --version
clang version 16.0.0 # actually 16.0.0_rc2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/16/bin
Configuration file: /etc/clang/clang.cfg

$ clang-16 -O2 /tmp/foo.c -o /tmp/foo
/tmp/foo.c:3:2: error: expected expression
[[noreturn]] void foo(void) {
 ^
/tmp/foo.c:3:14: error: expected identifier or '('
[[noreturn]] void foo(void) {
 ^
/tmp/foo.c:8:2: error: call to undeclared function 'foo'; ISO C99 and later do
not support implicit function declarations [-Wimplicit-function-declaration]
foo();
^
3 errors generated.

$ clang-16 -std=c2x -O2 /tmp/foo.c -o /tmp/foo # fine
```

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

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

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

--- Comment #3 from Kewen Lin  ---
One more test case fail with abort on both LE & BE (with -Ofast -mcpu=power9):



#define N 16

unsigned long long vals[N];
unsigned int res[N];
unsigned int expects[N] = {0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0};

unsigned long long inputs[N]
  = {0xULL, 0x0001ULL, 0x8000ULL,
 0x0002ULL, 0x4000ULL, 0x0001ULL,
 0x8000ULL, 0xa5a5a5a5a5a5a5a5ULL, 0x5a5a5a5a5a5a5a5aULL,
 0xcafecafeULL, 0xcafecafeULL, 0xcafecafeULL,
 0x80706000ULL, 0xULL};

__attribute__ ((noipa)) void
init ()
{
  for (int i = 0; i < N; i++)
vals[i] = inputs[i];
}

__attribute__ ((noipa)) void
do_parity ()
{
  for (int i = 0; i < N; i++)
res[i] = __builtin_parityll (vals[i]);
}

int
main (void)
{
  init ();
  do_parity ();
  for (int i = 0; i < N; i++)
if (res[i] != expects[i])
  __builtin_abort();

  return 0;
}

[Bug c++/106675] [10 Regression] g++ crashes on funky operators

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Summary|[10/11/12/13 Regression]|[10 Regression] g++ crashes
   |g++ crashes on funky|on funky operators
   |operators   |
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:53512f0055186d5556e9859c1f8beb25d2d28530

commit r11-10525-g53512f0055186d5556e9859c1f8beb25d2d28530
Author: Marek Polacek 
Date:   Fri Feb 10 17:26:57 2023 -0500

c++: fix ICE in joust_maybe_elide_copy [PR106675]

joust_maybe_elide_copy checks that the last conversion in the ICS for
the first argument is ck_ref_bind, which is reasonable, because we've
checked that we're dealing with a copy/move constructor.  But it can
also happen that we couldn't figure out which conversion function is
better to convert the argument, as in this testcase: joust couldn't
decide if we should go with

  operator foo &()

or

  operator foo const &()

so we get a ck_ambig, which then upsets joust_maybe_elide_copy.  Since
a ck_ambig can validly occur, I think we should just return early, as
in the patch below.

PR c++/106675

gcc/cp/ChangeLog:

* call.c (joust_maybe_elide_copy): Return false for ck_ambig.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/overload-conv-5.C: New test.

(cherry picked from commit cce62625025380c2ea2a220deb10f8f355f83abf)

[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:1721d85708116a1edbe5ba30f055d47e6c1e29b6

commit r12-9174-g1721d85708116a1edbe5ba30f055d47e6c1e29b6
Author: Marek Polacek 
Date:   Fri Feb 10 17:26:57 2023 -0500

c++: fix ICE in joust_maybe_elide_copy [PR106675]

joust_maybe_elide_copy checks that the last conversion in the ICS for
the first argument is ck_ref_bind, which is reasonable, because we've
checked that we're dealing with a copy/move constructor.  But it can
also happen that we couldn't figure out which conversion function is
better to convert the argument, as in this testcase: joust couldn't
decide if we should go with

  operator foo &()

or

  operator foo const &()

so we get a ck_ambig, which then upsets joust_maybe_elide_copy.  Since
a ck_ambig can validly occur, I think we should just return early, as
in the patch below.

PR c++/106675

gcc/cp/ChangeLog:

* call.cc (joust_maybe_elide_copy): Return false for ck_ambig.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/overload-conv-5.C: New test.

(cherry picked from commit cce62625025380c2ea2a220deb10f8f355f83abf)

[Bug c++/106675] [10/11/12/13 Regression] g++ crashes on funky operators

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-5990-gcce62625025380c2ea2a220deb10f8f355f83abf
Author: Marek Polacek 
Date:   Fri Feb 10 17:26:57 2023 -0500

c++: fix ICE in joust_maybe_elide_copy [PR106675]

joust_maybe_elide_copy checks that the last conversion in the ICS for
the first argument is ck_ref_bind, which is reasonable, because we've
checked that we're dealing with a copy/move constructor.  But it can
also happen that we couldn't figure out which conversion function is
better to convert the argument, as in this testcase: joust couldn't
decide if we should go with

  operator foo &()

or

  operator foo const &()

so we get a ck_ambig, which then upsets joust_maybe_elide_copy.  Since
a ck_ambig can validly occur, I think we should just return early, as
in the patch below.

PR c++/106675

gcc/cp/ChangeLog:

* call.cc (joust_maybe_elide_copy): Return false for ck_ambig.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/overload-conv-5.C: New test.

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

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

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

--- Comment #21 from Gaius Mulley  ---
For clarity the "RTentity uninitialized Storage module" error has disappeared.

[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #20 from Gaius Mulley  ---
Created attachment 54461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54461=edit
Proposed fix

Here is a proposed fix which implements name mangling using named paths.
The new command line arguments -fm2-pathname=foo and -Im2-prefix=bar are
implemented.  The RTentity uninitialized Storage module has disappeared as both
sets of libraries (m2pim and m2iso) can now co-exist.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

--- Comment #10 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Marek Polacek from comment #7)
> > I know you can't jump into a statement expression but that's not what's
> > happening here.  The kernel uses this trick to get the current address for
> > error messages:
> > 
> > #define __this_address ({ __label__ __here; __here: barrier(); &&__here; })
> > 
> > and they will have to disable the warning completely because of it.  The
> > manual for -Wdangling-pointer also talks about pointers to *objects* and
> > labels aren't objects.
> 
> But that is undefined at what label or even where label would be located; it
> could be located anywhere. The kernel use of this extension should be
> removed as it is not using it to get an useful value at all. Maybe we should
> add another builtin to get the current PC.

Apparently it's worked for them.  XFS uses __this_address as defined above, the
rest of the kernel uses
#define _RET_IP_(unsigned long)__builtin_return_address(0)
#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })

Maybe we should have __builtin_current_pc but we don't.

> Also can't they turn off the warning inside the statement expression/around
> the macro?

That's a question for them.  I continue to think that warning about non-objects
is a flaw and not useful.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
It is true that if there is no edge to the label there is no guarantee where
exactly it will wind up, but we make quite a lot of effort to emit it as a
reasonable spot if possible (see NOTE_INSN_DELETED_LABEL etc.).

That said, -Wdangling-pointer* description is quite clear:
Warn about uses of pointers (or C++ references) to objects with automatic
storage duration after their lifetime has ended.

Labels aren't automatic storage duration objects, they are code addresses but
if anything, they could be more compared to static function-scope variables,
-Wdangling-pointer* doesn't warn about those either.

A lot of programs in the wild actually do use & for just printing
addresses, not just the kernel, and we shouldn't warn on it in any way,
especially not with completely unrelated warning.  We can warn if we can prove
somebody is actually trying to jump through them into statement expressions and
the like, but that is not what happens here.

The bug is clearly in
/* Return true of X is a DECL with automatic storage duration.  */

static inline bool
is_auto_decl (tree x)
{
  return DECL_P (x) && !DECL_EXTERNAL (x) && !TREE_STATIC (x);
}

That function should be killed and auto_var_p function should be used instead.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #7)
> I know you can't jump into a statement expression but that's not what's
> happening here.  The kernel uses this trick to get the current address for
> error messages:
> 
> #define __this_address ({ __label__ __here; __here: barrier(); &&__here; })
> 
> and they will have to disable the warning completely because of it.  The
> manual for -Wdangling-pointer also talks about pointers to *objects* and
> labels aren't objects.

But that is undefined at what label or even where label would be located; it
could be located anywhere. The kernel use of this extension should be removed
as it is not using it to get an useful value at all. Maybe we should add
another builtin to get the current PC.

Also can't they turn off the warning inside the statement expression/around the
macro?

[Bug target/108790] bpf: gcc emits malformed ldxdw instruction at -O2

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Faust :

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

commit r13-5989-gc348a717213b03c6661878934f197f4d261f0e56
Author: David Faust 
Date:   Tue Feb 14 11:23:01 2023 -0800

bpf: fix memory constraint of ldx/stx instructions [PR108790]

In some cases where the target memory address for an ldx or stx
instruction could be reduced to a constant, GCC could emit a malformed
instruction like:

ldxdw %r0,0

Rather than the expected form:

ldxdw %rX, [%rY + OFFSET]

This is due to the constraint allowing a const_int operand, which the
output templates do not handle.

Fix it by introducing a new memory constraint for the appropriate
operands of these instructions, which is identical to 'm' except that
it does not accept const_int.

gcc/

PR target/108790
* config/bpf/constraints.md (q): New memory constraint.
* config/bpf/bpf.md (zero_extendhidi2): Use it here.
(zero_extendqidi2): Likewise.
(zero_extendsidi2): Likewise.
(*mov): Likewise.

gcc/testsuite/

PR target/108790
* gcc.target/bpf/ldxdw.c: New test.

Re: XMM/YMM assembly bloat

[Andrew Pinski via Gcc-bugs]

On Tue, Feb 14, 2023 at 2:14 PM Owen Cook via Gcc-bugs
 wrote:
>
> Adding white space/newlines outside the function also affect the length of
> assembly.

Note -march=native is dependent on the machine which is being used.
IIRC godbolt uses a few different machines and that means the answer
which -march=native will change based on which machine it is run on.

So don't trust godbolt with -march=native at all.

Thanks,
Andrew

>
> On Tue, Feb 14, 2023 at 5:09 PM Owen Cook  wrote:
>
> > Within "unrollOptimizations.c" compiled on a Ryzen 5 2600 using x86-64 gcc
> > 12.2 "-O2 -march=native" gives vastly different assembler results given
> > some scope things I have found. If the for loop iterator name is both int i
> > in each loop, gcc seemingly spreads arrayA and arrayB into one single XMM
> > register, name them differently and you get usages over XMM and YMM.
> > Additionally, white space seems to be a variable to this as well. you can
> > have the for loops one newline away from each other and this results in XMM
> > YMM, but put them together and you get XMM. Changing float* a to float*
> > const a (same goes for float* b) also changes these values.
> >
> > Godbolt equivalent for simplicity
> > https://godbolt.org/z/4xWrGoPaE
> >

Re: XMM/YMM assembly bloat

[Owen Cook via Gcc-bugs]

Adding white space/newlines outside the function also affect the length of
assembly.

On Tue, Feb 14, 2023 at 5:09 PM Owen Cook  wrote:

> Within "unrollOptimizations.c" compiled on a Ryzen 5 2600 using x86-64 gcc
> 12.2 "-O2 -march=native" gives vastly different assembler results given
> some scope things I have found. If the for loop iterator name is both int i
> in each loop, gcc seemingly spreads arrayA and arrayB into one single XMM
> register, name them differently and you get usages over XMM and YMM.
> Additionally, white space seems to be a variable to this as well. you can
> have the for loops one newline away from each other and this results in XMM
> YMM, but put them together and you get XMM. Changing float* a to float*
> const a (same goes for float* b) also changes these values.
>
> Godbolt equivalent for simplicity
> https://godbolt.org/z/4xWrGoPaE
>

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

--- Comment #7 from Marek Polacek  ---
I know you can't jump into a statement expression but that's not what's
happening here.  The kernel uses this trick to get the current address for
error messages:

#define __this_address ({ __label__ __here; __here: barrier(); &&__here; })

and they will have to disable the warning completely because of it.  The manual
for -Wdangling-pointer also talks about pointers to *objects* and labels aren't
objects.

XMM/YMM assembly bloat

[Owen Cook via Gcc-bugs]

Within "unrollOptimizations.c" compiled on a Ryzen 5 2600 using x86-64 gcc
12.2 "-O2 -march=native" gives vastly different assembler results given
some scope things I have found. If the for loop iterator name is both int i
in each loop, gcc seemingly spreads arrayA and arrayB into one single XMM
register, name them differently and you get usages over XMM and YMM.
Additionally, white space seems to be a variable to this as well. you can
have the for loops one newline away from each other and this results in XMM
YMM, but put them together and you get XMM. Changing float* a to float*
const a (same goes for float* b) also changes these values.

Godbolt equivalent for simplicity
https://godbolt.org/z/4xWrGoPaE
#include 
#include 
#include 

const uint32_t array_A[] = {
4473924, 2236962, 1118481, 559240,
279620, 139810, 69905, 34952,
17476, 8738, 4369
};

const uint32_t array_B[] = {
4210752, 2105376, 1052688, 526344,
263172, 131586, 65793, 32896,
16448, 8224, 4112, 2056,
1028, 514, 257
};

void Setup(int exponent, float* a, float* b) {
exponent <<= 23;
float arrA[11];
float arrB[15];
memcpy(arrA, array_A, sizeof(arrA));
memcpy(arrB, array_B, sizeof(arrB));
for(int i = 0; i < 11; i++) {
uint32_t v = *(uint32_t*)_A[i];
v |= exponent;
arrA[i] = *(float*)
}
for(int i = 0; i < 15; i++) {
uint32_t v = *(uint32_t*)[i];
v |= exponent;
arrB[i] = *(float*)
}
memcpy(a, arrA, sizeof(arrA));
memcpy(b, arrB, sizeof(arrB));
}

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

--- Comment #6 from Andrew Pinski  ---
On the statement expression part, it is documented that jumping into statement
expression is not allowed too:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Statement-Exprs.html#Statement-Exprs

>Jumping into a statement expression with goto or using a switch statement 
>outside the statement expression with a case or default label inside the 
>statement expression is not permitted. Jumping into a statement expression 
>with a computed goto (see Labels as Values) has undefined behavior.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #3)
> I don't think we should be warning here at all and I have a patch to that
> effect.

I also disagree with the saying we should not be warning here. Address to
lables are undefined once they leave the function scope (or in the case of
statement expressions; out of the statement expression scope). We even document
that.

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Labels-as-Values.html#Labels-as-Values

> You may not use this mechanism to jump to code in a different function. If 
> you do that, totally unpredictable things happen. The best way to avoid this 
> is to store the label address only in automatic variables and never pass it 
> as an argument.

We should be warning about this case just because of the above wording in the
documentation.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #3)
> This came up in kernel: https://bugzilla.kernel.org/show_bug.cgi?id=215851
> which I've reduced to 
> 
> void
> foo (void **failaddr)
> {
>   *failaddr = ({ __label__ __here; __here: &&__here; });
> }
> 
> I don't think we should be warning here at all and I have a patch to that
> effect.

Actaully in the above case, there should be a warning as you should not be able
to jump into a statement expression.

[Bug middle-end/106080] Labels as values triggering -Wdangling-pointer

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
This came up in kernel: https://bugzilla.kernel.org/show_bug.cgi?id=215851
which I've reduced to 

void
foo (void **failaddr)
{
  *failaddr = ({ __label__ __here; __here: &&__here; });
}

I don't think we should be warning here at all and I have a patch to that
effect.

[Bug c++/108795] [10/11/12/13 Regression] ICE in prep_operand, at cp/call.cc:6325

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-14
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  g++-6:

$ xg++-6 -c 108795.C
108795.C: In instantiation of ‘T g(T) [with T = int]’:
108795.C:11:7:   required from here
108795.C:7:8: error: cannot call member function ‘g(T)::C::~C() [with T = int]’
without object
   C::~C();
   ~^~

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 96921 Summary: Failure to optimize combined boolean not patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96921

   What|Removed |Added

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

[Bug tree-optimization/108354] [13 Regression] Dead Code Elimination Regression at -O2 since r13-89-gb3e98eb3396e16

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

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

Bug 96921 Summary: Failure to optimize combined boolean not patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96921

   What|Removed |Added

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

[Bug tree-optimization/96921] Failure to optimize combined boolean not patterns

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to CVS Commits from comment #3)
> The trunk branch has been updated by Andrew Pinski :
Sorry I forgot to fix the commit message for the corrected bug #.

[Bug tree-optimization/108354] [13 Regression] Dead Code Elimination Regression at -O2 since r13-89-gb3e98eb3396e16

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/108355] [13 Regression] Dead Code Elimination Regression at -O2 since r13-2772-g9baee6181b4e42

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-5988-ga42ed1d9181d21d5cb02f131f641c0cf375eca9d
Author: Andrew Pinski 
Date:   Tue Jan 31 05:03:21 2023 +

Simplify "1 - bool_val" to "bool_val ^ 1"

For bool values, it is easier to deal with
xor 1 rather than having 1 - a. This is because
we are more likely to simplify the xor further in many
cases.

This is a special case for (MASK - b) where MASK
is a powerof2 - 1 and b <= MASK but only for bool
ranges ([0,1]) as that is the main case where the
difference comes into play.

Note this is enabled for gimple folding only
as the ranges are only know while doing gimple
folding and cfun is not always set when fold is called.

OK? Bootstrapped and tested on x86_64-linux-gnu with no
regressions.

gcc/ChangeLog:

PR tree-optimization/108355
PR tree-optimization/96921
* match.pd: Add pattern for "1 - bool_val".

gcc/testsuite/ChangeLog:

PR tree-optimization/108355
PR tree-optimization/96921
* gcc.dg/tree-ssa/bool-minus-1.c: New test.
* gcc.dg/tree-ssa/bool-minus-2.c: New test.
* gcc.dg/tree-ssa/pr108354-1.c: New test.

[Bug tree-optimization/96921] Failure to optimize combined boolean not patterns

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

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

--- Comment #10 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r13-5988-ga42ed1d9181d21d5cb02f131f641c0cf375eca9d
Author: Andrew Pinski 
Date:   Tue Jan 31 05:03:21 2023 +

Simplify "1 - bool_val" to "bool_val ^ 1"

For bool values, it is easier to deal with
xor 1 rather than having 1 - a. This is because
we are more likely to simplify the xor further in many
cases.

This is a special case for (MASK - b) where MASK
is a powerof2 - 1 and b <= MASK but only for bool
ranges ([0,1]) as that is the main case where the
difference comes into play.

Note this is enabled for gimple folding only
as the ranges are only know while doing gimple
folding and cfun is not always set when fold is called.

OK? Bootstrapped and tested on x86_64-linux-gnu with no
regressions.

gcc/ChangeLog:

PR tree-optimization/108355
PR tree-optimization/96921
* match.pd: Add pattern for "1 - bool_val".

gcc/testsuite/ChangeLog:

PR tree-optimization/108355
PR tree-optimization/96921
* gcc.dg/tree-ssa/bool-minus-1.c: New test.
* gcc.dg/tree-ssa/bool-minus-2.c: New test.
* gcc.dg/tree-ssa/pr108354-1.c: New test.

[Bug tree-optimization/107972] backward propagation of finite property not performed

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #3)
> The backwards propagation fixed, but neither:
<...>
> avoids the 4.2e+1 cases in the output, because in neither case we properly
> determine the ranges of res (that it is in foo/bar/baz/qux
> [-DBL_MAX,DBL_MAX]).
> For quux I think we don't have a way to represent that right now, we'd need
> a union of 2 ranges and after all, we also flush denormals to zero, so I
> think we'd need if (!(res < 1.0)) __builtin_unreachable (); or
> __attribute__((assume (res < 1.0))); so that we get [1.0, +INF] non-NAN
> range.
> Aldy/Andrew, any ideas what's going on?

Relooking at this, I am confused a bit.

First, how can we remove the 42.0 from the output?   I see no reason the caller
can't pass a NAN in for a or b, and then the first if will trigger and return
42?
Sure, once we get to the calculation of res and know its not a NAN, we also
know the first if wasn't necessary, but thats only true if we actually get past
that first If...?

Second, we do actually know res is is that range on the outgoing edge if the
if.. ie for quux:
   res_8 = a_7(D) / b_6(D);
_2 = res_8 unord res_8;
_3 = res_8 == 0.0;
_4 = _2 | _3;
if (_4 != 0)
  goto ; [INV]
else
  goto ; [INV]

4->5  (T) _4 :  [irange] _Bool [1, 1]
4->5  (T) b_6(D) :  [frange] double
[-1.79769313486231570814527423731704356798070567525844996599e+308
(-0x0.f8p+1024),
1.79769313486231570814527423731704356798070567525844996599e+308
(0x0.f8p+1024)]
4->5  (T) res_8 :   [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
+-NAN
4->6  (F) _2 :  [irange] _Bool [0, 0] NONZERO 0x0
4->6  (F) _3 :  [irange] _Bool [0, 0] NONZERO 0x0
4->6  (F) _4 :  [irange] _Bool [0, 0] NONZERO 0x0
4->6  (F) b_6(D) :  [frange] double
[-1.79769313486231570814527423731704356798070567525844996599e+308
(-0x0.f8p+1024),
1.79769313486231570814527423731704356798070567525844996599e+308
(0x0.f8p+1024)]
4->6  (F) a_7(D) :  [frange] double [-Inf, +Inf]
4->6  (F) res_8 :   [frange] double [-Inf, +Inf]

We know on the edge 4->6 res_8 can't be a NAN (I think we have no way to also
represent ~0.0 right now, true)

We don't set the global that way due to some restrictions of the way we
currently remove unreachable().  there are 2 uses of res_8 in the expressions
in that block which ranger is currently not comfortable propagating the [-Inf,
+Inf] into since they precede the condition itself... it currently only deals
with this situation if there is ONE use in a condtion.  Since this has 2, it
gives up on this release. 

On the reachable edge leading to the return, in each of the 4 cases we know res
is not a NAN.   we just dont reflect it in the global always.

Next release I plan to revamp the unreachable stuff... again.  so many nooks
and crannies :-)

[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #8 from nightstrike  ---
FYI, this is the same as the failure in gcc/testsuite/gcc.dg/stack-check-16.c:

(running this under Wine)

during RTL pass: final
gcc.dg/stack-check-16.c:36:1: internal compiler error: in
i386_pe_seh_unwind_emit, at config/i386/winnt.cc:1274^M
0x86f42f i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)^M
../../gcc/config/i386/winnt.cc:1274^M
0xbd4d87 final_scan_insn_1^M
../../gcc/final.cc:2851^M
0xbd515b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)^M
../../gcc/final.cc:2887^M
0xbd5347 final_1^M
../../gcc/final.cc:1979^M
0xbd5e36 rest_of_handle_final^M
../../gcc/final.cc:4240^M
0xbd5e36 execute^M
../../gcc/final.cc:4318^M
Please submit a full bug report, with preprocessed source (by using
-freport-bug).^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1

[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers

[zach-gcc at cs dot stanford.edu via Gcc-bugs]

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

--- Comment #5 from zach-gcc at cs dot stanford.edu ---
Thanks for the quick response, I've tried it out and it looks good to me!

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #14 from David Binderman  ---
After five hours of reduction, cvise has:

crc32_tab[256];
unsigned crc32_context = 4294967295;
void crc32_byte(b) {
  crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ b) & 255];
}
void transparent_crc(long val, char *vname) {
  crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ val) & 255];
  crc32_byte(val >> 8);
  crc32_byte(val >> 16);
  crc32_byte(val >> 24);
  crc32_byte(val >> 32);
  crc32_byte(val >> 40);
  crc32_byte(val >> 48);
  crc32_byte(val >> 56);
  printf("...checksum after hashing %s : %lX\n", vname,
 crc32_context ^ 4294967295);
}
g_21 = -8;
short g_41;
g_78;
static *g_451 = _78;
g_452;
func_11___trans_tmp_13;
main_i;
unsigned main_crc;
main_j;
void main() {
  for (; main_i < 256; main_i++) {
main_crc = main_i;
main_j = 8;
for (; main_j; main_j--)
  if (main_crc & 1)
main_crc = main_crc >> 1 ^ 3988292384;
  else
main_crc >>= 1;
crc32_tab[main_i] = main_crc;
  }
  int l_794;
  g_41 = 53935 & g_21;
  g_21 = -18;
  g_78 = 1;
  for (; g_78 >= 0; g_78 -= 1) {
g_452 = l_794 = 0;
for (; l_794 <= 3; l_794 += 1) {
  short l_895[1];
  if (g_452)
break;
  g_452 ^= func_11___trans_tmp_13;
}
  }
  *g_451 = 8 || 0;
  transparent_crc(g_21, "");
  transparent_crc(g_41, "");
  transparent_crc(2185655400, "");
  transparent_crc(g_78, "g_78");
}

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 54460 [details]
> gcc13-pr108787.patch

That patch is preapproved, but please add a comment (before umaddditi4)
saying we do not want maddditi4 as well (and why; just something short,
maybe reference this PR :-) )  Thanks!

> Patch that kills maddditi4 in addition to fixing umaddditi4.  As mentioned
> above, in the umaddditi4 case if we later on e.g. during combine find out
> that
> the high half of the last operand is zero, it will be nicely optimized to
> the optimal sequence.  Unfortunately, with maddditi4 it is really hard to
> find out at expansion time if the last operand is sign extended from DImode
> or narrower,
> there is no SSA_NAME on the pseudo to check say for value ranges, and
> looking at earlier already emitted instructions checking for one subreg of
> it set to something and the other to copies of its sign bit would be a total
> mess.
> And at combine time I'm afraid we'd need 5 instruction combination.
> So if we want to be able to optimize qux above, I'm afraid we'd need to add
> a new optab.

It is easy to optimise if operands[3] is a non-negative 64-bit thing.  I
expect combine can do it in that case :-)

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #8 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #6)
> we used to emit in GCC 12 4/4/4/5 instructions:
> mulld 9,3,4
> mulhdu 4,3,4
> addc 3,9,5
> adde 4,4,6
> and
> mulld 9,3,4
> mulhd 4,3,4
> addc 3,9,5
> adde 4,4,6
> and
> mulld 9,3,4
> mulhdu 4,3,4
> addc 3,9,5
> addze 4,4
> and
> mulld 9,3,4
> mulhd 4,3,4
> sradi 10,5,63
> addc 3,9,5
> adde 4,4,10

And it was 2/2/2/2 insns deep.

> Now, with the patch we get 3/5/3/6 instructions:
> maddhdu 9,3,4,5
> maddld 3,3,4,5
> add 4,9,6
> and
> maddhd 9,3,4,5
> srdi 10,5,63
> maddld 3,3,4,5
> add 9,9,10
> add 4,9,6
> and
> mr 9,3
> maddld 3,3,4,5
> maddhdu 4,9,4,5
> and
> maddhd 9,3,4,5
> srdi 8,5,63
> sradi 10,5,63
> maddld 3,3,4,5
> add 9,9,8
> add 4,9,10

And this is 2/3/2/3 so the signed are worse than what we had.

> So, unless we can somehow check for the sign extended operands[3], we
> shouldn't define maddditi3 or FAIL in it or expand it to equivalent of what
> we used to emit before.

I wouldn't define the signed version at all, we have no good way of
generating it.  We still can generate maddhd (and maddld of course), but
we shouldn't do this for maddditi4, just if e.g. combine comes up with the
correct RTL for it (there is no machine insn for it, it would require four
registers in, that is very expensive to do).

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 54460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54460=edit
gcc13-pr108787.patch

Patch that kills maddditi4 in addition to fixing umaddditi4.  As mentioned
above, in the umaddditi4 case if we later on e.g. during combine find out that
the high half of the last operand is zero, it will be nicely optimized to the
optimal sequence.  Unfortunately, with maddditi4 it is really hard to find out
at expansion time if the last operand is sign extended from DImode or narrower,
there is no SSA_NAME on the pseudo to check say for value ranges, and looking
at earlier already emitted instructions checking for one subreg of it set to
something and the other to copies of its sign bit would be a total mess.
And at combine time I'm afraid we'd need 5 instruction combination.
So if we want to be able to optimize qux above, I'm afraid we'd need to add a
new optab.

[Bug c++/108788] Lookup of injected class name should be type-dependent

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect this is related to the C++ paper:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html

[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to ktkachov from comment #3)
> Created attachment 54459 [details]
> Candidate patch
> 
> Patch that implements -mtp= similar to clang if you have the capability to
> try it out

My only comment is for the testcase, don't use .x for the common source. In
many other parts of the testsuite, .x is used for dejagnu commands for that
file.

[Bug tree-optimization/108793] [12/13 Regression] ICE: verify_gimple failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-14
   Target Milestone|--- |12.3

--- Comment #1 from Andrew Pinski  ---
Confirmed. Version without function pointers:
typedef int *p;
extern p a[], b[];
int f () {
  int n = 0;
  for (p* i = [0]; i > [0]; i++)
n++;
  return n;
}

[Bug c++/108795] New: [10/11/12/13 Regression] ICE in prep_operand, at cp/call.cc:6325

[gscfq--- via Gcc-bugs]

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

Bug ID: 108795
   Summary: [10/11/12/13 Regression] ICE in prep_operand, at
cp/call.cc:6325
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 :


$ cat z1.cc
template  T g (T x)
{
  class C
  {
__attribute__((transaction_safe)) ~C();
  };
  C::~C();
}
void f ()
{
  g (5);
}


$ gcc-13-20230212 -c z1.cc
z1.cc: In instantiation of 'T g(T) [with T = int]':
z1.cc:11:5:   required from here
z1.cc:7:6: internal compiler error: Segmentation fault
7 |   C::~C();
  |   ~~~^~
0xeb71af crash_signal
../../gcc/toplev.cc:314
0x7b242d prep_operand
../../gcc/cp/call.cc:6325
0x7c8d67 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.cc:6956
0x985d3d build_x_unary_op(unsigned int, tree_code, cp_expr, tree_node*, int)
../../gcc/cp/typeck.cc:6820
0x9237fb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:20496
0x924e34 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:20910
0x928e38 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19769
0x9279d1 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:18758
0x927cce tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:18730
0x928678 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19110
0x92b970 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:26707
0x92b970 instantiate_body
../../gcc/cp/pt.cc:26707
0x92c9df instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.cc:26997
0x9461db instantiate_pending_templates(int)
../../gcc/cp/pt.cc:27075
0x848f6a c_parse_final_cleanups()
../../gcc/cp/decl2.cc:4953
0x9f5be0 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1266

[Bug c++/108794] New: ICE in determine_visibility, at cp/decl2.cc:2839

[gscfq--- via Gcc-bugs]

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

Bug ID: 108794
   Summary: ICE in determine_visibility, at cp/decl2.cc:2839
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.cc
template  T g (T x)
{
  struct B b;
  struct B { struct A a; };
}
void f (int *x)
{
  g (x[1]);
}


$ gcc-13-20230212 -c z1.cc
z1.cc: In instantiation of 'struct g(int)::B':
z1.cc:3:12:   required from 'T g(T) [with T = int]'
z1.cc:8:5:   required from here
z1.cc:4:23: internal compiler error: Segmentation fault
4 |   struct B { struct A a; };
  |   ^
0xeb71af crash_signal
../../gcc/toplev.cc:314
0x84432d determine_visibility(tree_node*)
../../gcc/cp/decl2.cc:2839
0x8bf921 pushtag(tree_node*, tree_node*, TAG_how)
../../gcc/cp/name-lookup.cc:8007
0x93a8a8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.cc:10090
0x93af76 tsubst_aggr_type_1
../../gcc/cp/pt.cc:13940
0x930b8d tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15915
0x938336 tsubst_decl
../../gcc/cp/pt.cc:14949
0x931317 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15825
0x944cf5 instantiate_class_template(tree_node*)
../../gcc/cp/pt.cc:12278
0x97cd53 complete_type(tree_node*)
../../gcc/cp/typeck.cc:138
0x9387e5 tsubst_decl
../../gcc/cp/pt.cc:15237
0x931317 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15825
0x92a171 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:18857
0x927cce tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:18730
0x928678 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:19110
0x92b970 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:26707
0x92b970 instantiate_body
../../gcc/cp/pt.cc:26707
0x92c9df instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.cc:26997
0x9461db instantiate_pending_templates(int)
../../gcc/cp/pt.cc:27075
0x848f6a c_parse_final_cleanups()
../../gcc/cp/decl2.cc:4953

[Bug tree-optimization/108791] [12/13 Regression] ICE: verify_gimple failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||11.3.0
  Known to fail||12.1.0

--- Comment #2 from Andrew Pinski  ---
  vect__2.16_79 = MEM  [(int *)a_12(D) + ivtmp.31_52 * 1];
  vect__3.17_80 = [vec_unpack_lo_expr] vect__2.16_79;
  vect__3.17_81 = [vec_unpack_hi_expr] vect__2.16_79;
  _83 = BIT_FIELD_REF ;


into:

  _109 =   [(int *)a_12(D) + ivtmp.31_52 * 1];
  _11 = BIT_FIELD_REF  [(int *)_109], 32, 32>;

[Bug c++/108793] New: [12/13 Regression] ICE: verify_gimple failed

[gscfq--- via Gcc-bugs]

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

Bug ID: 108793
   Summary: [12/13 Regression] ICE: verify_gimple failed
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210822 and 20210905, at -O3 or -Ofast :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
typedef void (*p)();
extern "C" p a, b;
int f () {
  int n = 0;
  for (p* i =  i >  i++) {
n++;
  }
  return n;
}


$ gcc-13-20230212 -c z1.cc -Ofast
z1.cc: In function 'int f()':
z1.cc:3:5: error: non-trivial conversion in unary operation
3 | int f () {
  | ^
unsigned long
void (*p) (void) *
_3 = ~_1;
z1.cc:3:5: error: non-trivial conversion in unary operation
unsigned long
void (*p) (void) *
_24 = ~_23;
during GIMPLE pass: vect
z1.cc:3:5: internal compiler error: verify_gimple failed
0x12942be verify_gimple_in_cfg(function*, bool, bool)
../../gcc/tree-cfg.cc:5648
0x1135053 execute_function_todo
../../gcc/passes.cc:2091
0x1135ad2 execute_todo
../../gcc/passes.cc:2145

[Bug c++/108792] New: [10/11/12/13 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.cc:7147

[gscfq--- via Gcc-bugs]

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

Bug ID: 108792
   Summary: [10/11/12/13 Regression] ICE in
reset_sched_cycles_in_current_ebb, at
sel-sched.cc:7147
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10 between 20191110 and 20191117 (one week before pr97972),
at -O2+ and with special option -march=amdfam10 :

Testcase was derived from
llvm-project-llvmorg-14.0.6/openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_complex_structure.cpp


$ cat z1.cc
class A {
public:
  A() {
a = 1;
b = 2;
  }
  void show() {
__builtin_printf ("\n");
__builtin_printf ("%d %d\n", a, b);
  }
  int a;
  int b;
};
class B {
public:
  B() {
arr = new A[2];
len = 2;
  }
  void show() {
for (int i = 0; i < len; i++)
  arr[i].show();
  }
  A *arr;
  int len;
};
void foo (void) {
  B *x = new B[2];
  for (int i = 0; i < 2; i++)
x[i].show();
  return;
}


$ gcc-13-20230212 -c z1.cc -O2 -fnon-call-exceptions -fprofile-generate
-fsel-sched-pipelining -fselective-scheduling2
$
$ gcc-13-20230212 -c z1.cc -O2 -fnon-call-exceptions -fprofile-generate
-fsel-sched-pipelining -fselective-scheduling2 -march=amdfam10
during RTL pass: sched2
z1.cc: In member function 'void B::show()':
z1.cc:23:3: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.cc:7147
   23 |   }
  |   ^
0x11f60c5 reset_sched_cycles_in_current_ebb
../../gcc/sel-sched.cc:7147
0x11f60c5 sel_region_target_finish
../../gcc/sel-sched.cc:7220
0x11f60c5 sel_region_finish
../../gcc/sel-sched.cc:7276
0x11f60c5 sel_sched_region(int)
../../gcc/sel-sched.cc:7645
0x11f62f9 run_selective_scheduling()
../../gcc/sel-sched.cc:7720
0x11d2475 rest_of_handle_sched2
../../gcc/sched-rgn.cc:3743
0x11d2475 execute
../../gcc/sched-rgn.cc:3890

[Bug rtl-optimization/97972] [10/11/12/13 Regression] ICE in moving_insn_creates_bookkeeping_block_p, at sel-sched.c:2031 since r9-2064-gc4c5ad1d6d1e1e1f

[gscfq--- via Gcc-bugs]

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

--- Comment #7 from G. Steinmetz  ---
It gives an ICE for some target processors like -mtune=skylake,
but not for others like -mtune=sandybridge :


$ gcc-13-20230212 -c 20161124-1.c -O2 -mtune=skylake -fsanitize=undefined
-fvar-tracking-assignments -fselective-scheduling2
cc1: warning: var-tracking-assignments changes selective scheduling
during RTL pass: sched2
20161124-1.c: In function 'foo':
20161124-1.c:22:1: internal compiler error: Segmentation fault
   22 | }
  | ^
0xf295ff crash_signal
../../gcc/toplev.cc:314
0xeda737 moving_insn_creates_bookkeeping_block_p
../../gcc/sel-sched.cc:2031
0xeda737 moveup_expr
../../gcc/sel-sched.cc:2199
#...

[Bug tree-optimization/108791] [12/13 Regression] ICE: verify_gimple failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |12.3
 CC||pinskia at gcc dot gnu.org
   Keywords||ice-on-valid-code

[Bug c/108791] [12/13 Regression] ICE: verify_gimple failed

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu

--- Comment #1 from G. Steinmetz  ---

This variant gives an ICE for both -Ofast and -O3 : 

$ cat z2.c
int f (int *a(), int b, int *c, int *d)
{
  int s = 0;
  for (int *i = a; i < b; ++i, ++c)
s += *c * d[*i];
  return s;
}

[Bug c/108791] New: [12/13 Regression] ICE: verify_gimple failed

[gscfq--- via Gcc-bugs]

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

Bug ID: 108791
   Summary: [12/13 Regression] ICE: verify_gimple failed
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210801 and 20210808, at -Ofast :
(gcc configured with --enable-checking=yes)


$ cat z1.c
double f (int *a(), int b, double *c, double *d)
{
  double s = 0;
  for (int *i = a; i < b; ++i, ++c)
s += *c * d[*i];
  return s;
}


$ gcc-13-20230212 -c z1.c -Ofast
z1.c: In function 'f':
z1.c:4:17: warning: initialization of 'int *' from incompatible pointer type
'int * (*)()' [-Wincompatible-pointer-types]
4 |   for (int *i = a; i < b; ++i, ++c)
  | ^
z1.c:4:22: warning: comparison between pointer and integer
4 |   for (int *i = a; i < b; ++i, ++c)
  |  ^
z1.c:1:8: error: type mismatch in 'addr_expr'
1 | double f (int *a(), int b, double *c, double *d)
  |^
int * (*) ()

vector(4) int

_111 =   [(int *)a_14(D) + ivtmp.31_54 * 1];
during GIMPLE pass: forwprop
z1.c:1:8: internal compiler error: verify_gimple failed
0xf85e0e verify_gimple_in_cfg(function*, bool, bool)
../../gcc/tree-cfg.cc:5648
0xe1df43 execute_function_todo
../../gcc/passes.cc:2091
0xe1e9c2 execute_todo
../../gcc/passes.cc:2145

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #6 from Jakub Jelinek  ---
--- gcc/config/rs6000/rs6000.md.jj  2023-01-16 11:52:16.036734757 +0100
+++ gcc/config/rs6000/rs6000.md 2023-02-14 19:46:13.915782702 +0100
@@ -3231,20 +3231,38 @@
(plus:TI
  (mult:TI (any_extend:TI (match_operand:DI 1 "gpc_reg_operand"))
   (any_extend:TI (match_operand:DI 2 "gpc_reg_operand")))
- (any_extend:TI (match_operand:DI 3 "gpc_reg_operand"]
+ (match_operand:TI 3 "gpc_reg_operand")))]
   "TARGET_MADDLD && TARGET_POWERPC64"
 {
   rtx op0_lo = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 8 : 0);
   rtx op0_hi = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 0 : 8);
+  rtx op3_lo = gen_rtx_SUBREG (DImode, operands[3], BYTES_BIG_ENDIAN ? 8 : 0);
+  rtx op3_hi = gen_rtx_SUBREG (DImode, operands[3], BYTES_BIG_ENDIAN ? 0 : 8);
+  rtx hi_temp = gen_reg_rtx (DImode);

-  emit_insn (gen_maddlddi4 (op0_lo, operands[1], operands[2], operands[3]));
+  emit_insn (gen_maddlddi4 (op0_lo, operands[1], operands[2], op3_lo));

   if (BYTES_BIG_ENDIAN)
-emit_insn (gen_madddi4_highpart (op0_hi, operands[1], operands[2],
-   operands[3]));
+emit_insn (gen_madddi4_highpart (hi_temp, operands[1], operands[2],
+   op3_lo));
   else
-emit_insn (gen_madddi4_highpart_le (op0_hi, operands[1], operands[2],
-  operands[3]));
+emit_insn (gen_madddi4_highpart_le (hi_temp, operands[1], operands[2],
+  op3_lo));
+
+  if ( == SIGN_EXTEND)
+{
+  rtx sgn = gen_reg_rtx (DImode);
+  rtx hi_temp2 = gen_reg_rtx (DImode);
+
+  emit_insn (gen_lshrdi3 (sgn, op3_lo, GEN_INT (63)));
+
+  emit_insn (gen_adddi3 (hi_temp2, hi_temp, sgn));
+
+  hi_temp = hi_temp2;
+}
+
+  emit_insn (gen_adddi3 (op0_hi, hi_temp, op3_hi));
+
   DONE;
 })

gets it functionally correct.
But given
__attribute__((noipa)) unsigned __int128
foo (unsigned long long x, unsigned long long y, unsigned __int128 z)
{
  return (unsigned __int128) x * y + z;
}

__attribute__((noipa)) __int128
bar (long long x, long long y, __int128 z)
{
  return (__int128) x * y + z;
}

__attribute__((noipa)) unsigned __int128
baz (unsigned long long x, unsigned long long y, unsigned long long z)
{
  return (unsigned __int128) x * y + z;
}

__attribute__((noipa)) __int128
qux (long long x, long long y, long long z)
{
  return (__int128) x * y + z;
}
we used to emit in GCC 12 4/4/4/5 instructions:
mulld 9,3,4
mulhdu 4,3,4
addc 3,9,5
adde 4,4,6
and
mulld 9,3,4
mulhd 4,3,4
addc 3,9,5
adde 4,4,6
and
mulld 9,3,4
mulhdu 4,3,4
addc 3,9,5
addze 4,4
and
mulld 9,3,4
mulhd 4,3,4
sradi 10,5,63
addc 3,9,5
adde 4,4,10
Now, with the patch we get 3/5/3/6 instructions:
maddhdu 9,3,4,5
maddld 3,3,4,5
add 4,9,6
and
maddhd 9,3,4,5
srdi 10,5,63
maddld 3,3,4,5
add 9,9,10
add 4,9,6
and
mr 9,3
maddld 3,3,4,5
maddhdu 4,9,4,5
and
maddhd 9,3,4,5
srdi 8,5,63
sradi 10,5,63
maddld 3,3,4,5
add 9,9,8
add 4,9,10
So, unless we can somehow check for the sign extended operands[3], we shouldn't
define maddditi3 or FAIL in it or expand it to equivalent of what we used to
emit before.

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from Segher Boessenkool  ---
The maddhd insn does a sign-extend of the addend as well, so simply adding
the high part of it is not enough.

I don't see how to solve this with any machine code using the new madd* insns
that is at least as good code as the mulld;mulhd;addc;adde we would otherwise
generate.

We should still have machine patterns for the insn we have (it can be used
if operands[3] here is only one machine word for example), but we shouldn't
have a define_expand for maddditi4?  (For umaddditi4 we can of course, and
that is even useful if it results in better generated code).

[Bug target/108790] New: bpf: gcc emits malformed ldxdw instruction at -O2

[david.faust at oracle dot com via Gcc-bugs]

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

Bug ID: 108790
   Summary: bpf: gcc emits malformed ldxdw instruction at -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.faust at oracle dot com
CC: cupertino.miranda at oracle dot com
  Target Milestone: ---
Target: bpf

With -O2 GCC emits a malformed ldxdw instruction in some cases:

$ cat ldxdw.c
unsigned long long test () {
  return *((unsigned long long *) 0x4000);
}

$ bpf-unknown-none-gcc -c -O2 ldxdw.c -o ldxdw.o
/tmp/ccsuVj7l.s: Assembler messages:
/tmp/ccsuVj7l.s:7: Error: unrecognized form of instruction `ldxdw %r0,16384'

ldxdw (and all other {ldx,stx}{b,h,w,dw} insns should have a form like

ldxdw %rX, [%rY + OFFSET]

Looks like we need a better constraint on the memory operand in *mov.

Testing a patch for this now.

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
long random (void);

__attribute__((noipa)) unsigned __int128
foo (unsigned long long x, unsigned long long y, unsigned __int128 z)
{
  return (unsigned __int128) x * y + z;
}

__attribute__((noipa)) __int128
bar (long long x, long long y, __int128 z)
{
  return (__int128) x * y + z;
}

unsigned long long
baz (void)
{
  return (random () & 0x7fff) + ((random () & 0x7fffLL) << 31) +
((random () & 0x3ULL) << 62);
}

unsigned __int128
qux (void)
{
  return ((unsigned __int128) baz () << 64) + baz ();
}

int
main ()
{
  for (int i = 0; i < 1000; ++i)
{
  volatile unsigned __int128 x, y;
  unsigned __int128 z;
  x = baz ();
  y = baz ();
  z = qux ();
  if (foo (x, y, z) != (x * y) + z)
__builtin_printf ("U 0x%016llx * 0x%016llx + 0x%016llx%016llx\n",
(unsigned long long) x, (unsigned long long) y, (unsigned long long) (z >> 64),
(unsigned long long) z);
}
  for (int i = 0; i < 1000; ++i)
{
  volatile unsigned __int128 x, y;
  unsigned __int128 z;
  x = (long long) baz ();
  y = (long long) baz ();
  z = qux ();
  if (bar (x, y, z) != (x * y) + z)
__builtin_printf ("S 0x%016llx * 0x%016llx + 0x%016llx%016llx\n",
(unsigned long long) x, (unsigned long long) y, (unsigned long long) (z >> 64),
(unsigned long long) z);
}
  return 0;
}

shows that while it is correct for umaddditi4, it is not correct for maddditi4.
Example of bar arguments which result in different result:
0x834a97f995de5fd5 * 0x878d5777da196ad2 +
0x630036472f469716e5be2424d91183d8
which computes 0x9dad19ebe2fba1e2351c16459af75292 but should compute
0x9dad19ebe2fba1e3351c16459af75292 instead.
In fact, the incorrect signed results are exactly all those where z has bit
0x8000ULL set and the result is ((unsigned __int128) 1) << 64
smaller than it should in that case.

Segher, is it worth adding something more complicated for the maddditi4 case or
shall we just drop maddditi4 and only support maddditi4?

[Bug target/108673] ICE with -fstack-clash-protection and noreturn attribute on x86_64-w64-mingw32

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #5 from Eric Botcazou  ---
-fstack-clash-protection must simply not be used on Windows, as Windows has had
builtin stack clash protection since the beginning.

[Bug target/108673] ICE with -fstack-clash-protection and noreturn attribute on x86_64-w64-mingw32

[franke at computer dot org via Gcc-bugs]

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

--- Comment #4 from Christian Franke  ---
I get similar results with x86_64-pc-cygwin-gcc (aka gcc) 11.3.0 and
x86_64-w64-mingw32-gcc 11.3.0, both from current Cygwin distro and with
x86_64-w64-mingw32-gcc (aka gcc) 12.2.0 from current MSYS2 distro.

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #3 from Jakub Jelinek  ---
--- gcc/config/rs6000/rs6000.md.jj  2023-01-16 11:52:16.036734757 +0100
+++ gcc/config/rs6000/rs6000.md 2023-02-14 18:53:25.071014954 +0100
@@ -3231,20 +3231,26 @@
(plus:TI
  (mult:TI (any_extend:TI (match_operand:DI 1 "gpc_reg_operand"))
   (any_extend:TI (match_operand:DI 2 "gpc_reg_operand")))
- (any_extend:TI (match_operand:DI 3 "gpc_reg_operand"]
+ (match_operand:TI 3 "gpc_reg_operand")))]
   "TARGET_MADDLD && TARGET_POWERPC64"
 {
   rtx op0_lo = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 8 : 0);
   rtx op0_hi = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 0 : 8);
+  rtx op3_lo = gen_rtx_SUBREG (DImode, operands[3], BYTES_BIG_ENDIAN ? 8 : 0);
+  rtx op3_hi = gen_rtx_SUBREG (DImode, operands[3], BYTES_BIG_ENDIAN ? 0 : 8);
+  rtx hi_temp = gen_reg_rtx (DImode);

-  emit_insn (gen_maddlddi4 (op0_lo, operands[1], operands[2], operands[3]));
+  emit_insn (gen_maddlddi4 (op0_lo, operands[1], operands[2], op3_lo));

   if (BYTES_BIG_ENDIAN)
-emit_insn (gen_madddi4_highpart (op0_hi, operands[1], operands[2],
-   operands[3]));
+emit_insn (gen_madddi4_highpart (hi_temp, operands[1], operands[2],
+   op3_lo));
   else
-emit_insn (gen_madddi4_highpart_le (op0_hi, operands[1], operands[2],
-  operands[3]));
+emit_insn (gen_madddi4_highpart_le (hi_temp, operands[1], operands[2],
+  op3_lo));
+
+  emit_insn (gen_adddi3 (op0_hi, hi_temp, op3_hi));
+
   DONE;
 })


seems to fix this, but I have yet to check if it is the right thing also for
the signed case.

[Bug middle-end/108789] __builtin_(add|mul)_overflow methods generate duplicate operations if both operands are const

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
The middle-end is not adding a SAVE_EXPR in the const case which causes the
duplication which is not optimized back.

[Bug c/108789] New: __builtin_(add|mul)_overflow methods generate duplicate operations if both operands are const

[dpejesh at yahoo dot com via Gcc-bugs]

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

Bug ID: 108789
   Summary: __builtin_(add|mul)_overflow methods generate
duplicate operations if both operands are const
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dpejesh at yahoo dot com
  Target Milestone: ---

#include 
#include 
#include 

bool add(uint8_t *r, const uint8_t *a, const uint8_t *b) {
  return __builtin_add_overflow(*a, *b, r);
}

bool mul(uint8_t *r, const uint8_t *a, const uint8_t *b) {
  return __builtin_mul_overflow(*a, *b, r);
}

int main() {
  uint8_t x;

  /* 64 + 64 should not overflow */
  x = 64;
  if (add(, , ))
printf("false positive: x=%i\n", x);

  /* 4 * 4 should not overflow */
  x = 4;
  if (mul(, , ))
printf("false positive: x=%i\n", x);

  /* 128 + 128 should overflow */
  x = 128;
  if (!add(, , ))
printf("false negative: x=%i\n", x);

  /* 16 * 16 should overflow */
  x = 16;
  if (!mul(, , ))
printf("false negative: x=%i\n", x);

  return 0;
}

$ gcc -g3 -O1 -o test test.c; ./test
false positive: x=128
false positive: x=16
false negative: x=0
false negative: x=0

The generated assembly correctly adds a with b and stores in r but
then it does the operation again before testing for carry and
returning.  If r is also one of the operands then the erroneous
second operation will use the computed value of r in place of the
original operand leading to an incorrect overflow result.

00400895 :
;   return __builtin_add_overflow(*a, *b, r);
  400895: 0f b6 02  movzbl  (%rdx), %eax
  400898: 02 06 addb(%rsi), %al
  40089a: 88 07 movb%al, (%rdi)
  40089c: 0f b6 02  movzbl  (%rdx), %eax  <<
  40089f: 02 06 addb(%rsi), %al   <<
  4008a1: 0f 92 c0  setb%al
; }
  4008a4: c3retq

004008a5 :
;   return __builtin_mul_overflow(*a, *b, r);
  4008a5: 0f b6 06  movzbl  (%rsi), %eax
  4008a8: f6 22 mulb(%rdx)
  4008aa: 88 07 movb%al, (%rdi)
  4008ac: 0f b6 06  movzbl  (%rsi), %eax  <<
  4008af: f6 22 mulb(%rdx)<<
  4008b1: 0f 90 c0  seto%al
; }
  4008b4: c3retq

This only seems to be triggered when both a *and* b are const.
Removing const from either or both operands generates the correct
assembly.

00400855 :
;   return __builtin_add_overflow(*a, *b, r);
  400855: 0f b6 02  movzbl  (%rdx), %eax
  400858: 02 06 addb(%rsi), %al
  40085a: 88 07 movb%al, (%rdi)
  40085c: 0f 92 c0  setb%al
; }
  40085f: c3retq

00400860 :
;   return __builtin_mul_overflow(*a, *b, r);
  400860: 0f b6 06  movzbl  (%rsi), %eax
  400863: f6 22 mulb(%rdx)
  400865: 88 07 movb%al, (%rdi)
  400867: 0f 90 c0  seto%al
; }
  40086a: c3retq

Tested on the following systems:

$ uname -srm; gcc12 --version
FreeBSD 13.1-RELEASE-p2 amd64
gcc12 (FreeBSD Ports Collection) 12.2.0

$ uname -smr; gcc --version
Linux 6.1.2-1-MANJARO-ARM aarch64
gcc (GCC) 12.1.0

$ uname -srm; gcc --version
MINGW64_NT-10.0-22000 3.4.5.x86_64 x86_64
gcc.exe (Rev10, Built by MSYS2 project) 12.2.0

Poking around godbolt indicates this was likely introduced in 9.4.

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

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

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

--- Comment #2 from Segher Boessenkool  ---
Right, it needs a vpopcntb or similar first.

[Bug target/108673] ICE with -fstack-clash-protection and noreturn attribute on x86_64-w64-mingw32

[amy.mclaughlin at iar dot com via Gcc-bugs]

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

amy.mclaughlin at iar dot com changed:

   What|Removed |Added

 CC||amy.mclaughlin at iar dot com

--- Comment #3 from amy.mclaughlin at iar dot com ---
Regarding Comment 1, the bug in Cygwin's gcc (11.3.0) can't be worked around
with `-fno-ipa-pure-const`. The workaround also fails for the msys2 msys build
of gcc (also 11.3.0) but succeeds for the mingw64 build.

So I suspect that the bug reproduced with x86_64-pc-cygwin-gcc may not be the
same bug as the one in this report, despite the similar symptoms.

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #2 from Jakub Jelinek  ---
In *.optimized dump it looks correct:
  d_16 = h2_14(D) w* s1_15(D);
  _19 = WIDEN_MULT_PLUS_EXPR ;
  d0_17 = WIDEN_MULT_PLUS_EXPR ;
where WIDEN_MULT_EXPR has 2 64-bit unsigned operands and 128-bit result, and
the 2 WIDEN_MULT_PLUS_EXPR which as documented have 2 64-bit unsigned operands
and 128-bit result as well as last argument.
But the actual rs6000.md implementation looks broken in several ways.

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

--- Comment #1 from Jakub Jelinek  ---
Correction, -fPIC isn't important.  Even more reduced testcase:
__attribute__((noipa)) unsigned __int128
foo (unsigned long long h0, unsigned long long h1, unsigned long long h2,
unsigned long long r0, unsigned long long s1, unsigned long long s2)
{
  unsigned __int128 d0, d;
  d0 = ((unsigned __int128) h0 * r0);
  d = ((unsigned __int128) h1 * s2);
  d0 += d;
  d = ((unsigned __int128) h2 * s1);
  d0 += d;
  return d0;
}

int
main ()
{
  if (__CHAR_BIT__ != 8 || __SIZEOF_LONG_LONG__ != 8 || __SIZEOF_INT128__ !=
16)
return 0;
  unsigned __int128 x = foo (0x3efe88da491ULL, 0xd105e9b4a44ULL,
0x4efa677b3dbULL, 0x42c052bac7bULL, 0x99638a13199cULL, 0x56b640d064ULL);
  if ((unsigned long long) (x >> 64) != 0x0309ff93ULL
  || (unsigned long long) x != 0xbd5c98fdf2bdbcafULL)
__builtin_abort ();
  return 0;
}

The high 64-bits of the result are miscomputed.

[Bug c++/108788] New: Lookup of injected class name should be type-dependent

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 108788
   Summary: Lookup of injected class name should be type-dependent
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following code fails to compile on any gcc version. Works on all clang
versions.

It looks like inside template function get_templ_base the lookup of
v.templ_base::a is done eagerly, and finds templ_base at the global scope, and
hence errors out because the template parameters are missing.
But at this point qualified name "templ_base::a" should be type-dependent, so
lookup should be delayed until template instantiation, where 'templ_base' is an
injected class name, so template paremeters shouldn't be required.

g++ -std=c++11

struct base
{
int a = 1;
};

template 
struct templ_base
{
int a = 2;
};

namespace bar
{

struct base2
{
int a = 3;
};

template 
struct templ_base2
{
int a = 4;
};


}

struct foo : base, bar::templ_base2, templ_base, bar::base2
{
int base = 5;
int templ_base = 6;
int base2 = 7;
int templ_base2 = 8;
int a = 9;
};

static_assert(foo{}.base::a == 1, "");
static_assert(foo{}.templ_base::a == 2, "");
static_assert(foo{}.base2::a == 3, "");
static_assert(foo{}.templ_base2::a == 4, "");


template 
int get_base(T&& v)
{
return v.base::a;
}

template 
int get_templ_base(T&& v)
{
return v.templ_base::a; // fails in all gcc versions
}

template 
int get_base2(T&& v)
{
return v.base2::a; // fails for gcc <= 11
}

template 
int get_templ_base2(T&& v)
{
return v.templ_base2::a;  // fails for gcc <= 11
}

int a = get_base(foo{});
int b = get_templ_base(foo{});
int c = get_base2(foo{});
int d = get_templ_base2(foo{});

[Bug target/108787] [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Priority|P3  |P1

[Bug target/108787] New: [13 Regression] libsodium miscompilation on power9 starting with r13-2107

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

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

Bug ID: 108787
   Summary: [13 Regression] libsodium miscompilation on power9
starting with r13-2107
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase is miscompiled with -mcpu=power9 -mtune=power9 starting
with
r13-2107-gdefa08a33672d200edbdd7f87ed7afa442249261 .  Doesn't reproduce without
-fPIC though.

/* { dg-do run { target int128 } } */
/* { dg-options "-O2" } */
/* { dg-additional-options "-fPIC" { target fpic } } */

typedef unsigned __int128 uint128_t;

static inline unsigned long long
foo (const unsigned char src[8])
{
  unsigned long long w;
  __builtin_memcpy (, src, sizeof w);
  return w;
}

typedef struct S {
  unsigned long long r[3], h[3];
  unsigned char final;
} S;

__attribute__((noipa)) static void
poly1305_blocks (S *st, const unsigned char *m,
 unsigned long long bytes)
{
  const unsigned long long hibit = st->final ? 0ULL : (1ULL << 40);
  unsigned long long r0, r1, r2;
  unsigned long long s1, s2;
  unsigned long long h0, h1, h2;
  unsigned long long c;
  uint128_t d0, d1, d2, d;

  r0 = st->r[0];
  r1 = st->r[1];
  r2 = st->r[2];
  h0 = st->h[0];
  h1 = st->h[1];
  h2 = st->h[2];
  s1 = r1 * (5 << 2);
  s2 = r2 * (5 << 2);
  while (bytes >= 16)
{
  unsigned long long t0, t1;

  t0 = foo ([0]);
  t1 = foo ([8]);
  h0 += t0 & 0xfff;
  h1 += ((t0 >> 44) | (t1 << 20)) & 0xfff;
  h2 += (((t1 >> 24)) & 0x3ff) | hibit;
  d0 = ((uint128_t) h0 * r0);
  d = ((uint128_t) h1 * s2);
  d0 += d;
  d = ((uint128_t) h2 * s1);
  d0 += d;
  d1 = ((uint128_t) h0 * r1);
  d = ((uint128_t) h1 * r0);
  d1 += d;
  d = ((uint128_t) h2 * s2);
  d1 += d;
  d2 = ((uint128_t) h0 * r2);
  d = ((uint128_t) h1 * r1);
  d2 += d;
  d = ((uint128_t) h2 * r0);
  d2 += d;
  c = (unsigned long long) (d0 >> (44));
  h0 = (unsigned long long) (d0) & 0xfff;
  d1 += c;
  c = (unsigned long long) (d1 >> (44));
  h1 = (unsigned long long) (d1) & 0xfff;
  d2 += c;
  c = (unsigned long long) (d2 >> (42));
  h2 = (unsigned long long) (d2) & 0x3ff;
  h0 += c * 5;
  c = (h0 >> 44);
  h0 = h0 & 0xfff;
  h1 += c;
  m += 16;
  bytes -= 16;
}
  st->h[0] = h0;
  st->h[1] = h1;
  st->h[2] = h2;
}

int
main ()
{
  if (sizeof (unsigned long long) != 8 || sizeof (uint128_t) != 16)
return 0;
  S st = { .r = { 0x42c052bac7bULL, 0x7ab6080f47bULL, 0x455e9a405ULL },
   .h = { 0x3efe88da491ULL, 0xd10577b4a44ULL, 0x3efa677b3dbULL } };
  unsigned long long l[2] = { 0, 0x72ULL };
  poly1305_blocks (, (unsigned char *) [0], sizeof (l));
  if (st.h[0] != 0xef4cd4260ULL || st.h[1] != 0x5d0e836abb6ULL || st.h[2] !=
0x171e724427ULL)
__builtin_abort ();
  return 0;
}

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[paul_robinson at playstation dot sony.com via Gcc-bugs]

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

--- Comment #7 from Paul Robinson  
---
Okay. I'm persuaded this is not a great idea, and I'll solve the customer's
problem another way.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #13 from David Binderman  ---
I tried adding flag 1 to the run of the two binaries. Here is 
the bash history:

 1003  gcc bug880.c
 1004  ./a.out > /tmp/0
 1005  ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c -o
b.out
 1006  ./b.out > /tmp/1
 1007  diff /tmp/0 /tmp/1
 1008  ./a.out 1 > /tmp/0
 1009  ./b.out 1 > /tmp/1
 1010  diff /tmp/0 /tmp/1

and got this:

4,12c4,12
< ...checksum after hashing g_78 : 42AE7A83
< ...checksum after hashing g_86 : EA4E5BB
< ...checksum after hashing g_87 : 829B71B1
< ...checksum after hashing g_93 : 454CD723
< ...checksum after hashing g_105 : 589C9AA7
< ...checksum after hashing g_111 : D1C885DD
< ...checksum after hashing g_132 : A790B35F
< ...checksum after hashing g_133 : A9573918
< ...checksum after hashing g_134[i] : 9B3BD0DE
---
> ...checksum after hashing g_78 : 8E047A1D
> ...checksum after hashing g_86 : A0CC742A
> ...checksum after hashing g_87 : 3BE1496
> ...checksum after hashing g_93 : B496D289
> ...checksum after hashing g_105 : F7D808E0
> ...checksum after hashing g_111 : EC796901
> ...checksum after hashing g_132 : BA05A088
> ...checksum after hashing g_133 : 2662148D
> ...checksum after hashing g_134[i] : 3530834A

So someplace in g_78 looks to be the culprit.

[Bug ipa/108679] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:656 since r13-4685-g4834e9360f7bf42f

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

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

--- Comment #4 from Martin Jambor  ---
I have proposed the fix on the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611978.html

[Bug middle-end/108786] bitmap_first_set_bit misses a bitmap_clear_first_bit

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-14
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug middle-end/108786] New: bitmap_first_set_bit misses a bitmap_clear_first_bit

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

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

Bug ID: 108786
   Summary: bitmap_first_set_bit misses a bitmap_clear_first_bit
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We have a repeated pattern for worklists doing

  unsigned idx = bitmap_first_set_bit (b);
  bitmap_clear_bit (b, idx);

but bitmap_clear_bit is more expensive and in particular prone to
clobber ->current which will pessimize other accesses to the same
bitmap.

bitmap_clear_first_bit would return the bit number cleared so it can
be used to pop an item from a worklist efficiently.

If the order doesn't matter a pick-one API also is missing which would
be more efficient for the tree form.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #10 from Marek Polacek  ---
Sorry.  A patch is on review.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[ecurtin at redhat dot com via Gcc-bugs]

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

ecurtin at redhat dot com changed:

   What|Removed |Added

 CC||ecurtin at redhat dot com

--- Comment #9 from ecurtin at redhat dot com ---
This is still causing problems in Fedora 38 onwards

[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers

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

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Created attachment 54459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54459=edit
Candidate patch

Patch that implements -mtp= similar to clang if you have the capability to try
it out

[Bug c++/71954] template partial specialization for constexpr error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85282
   Last reconfirmed|2016-07-22 00:00:00 |2023-2-14

--- Comment #7 from Jonathan Wakely  ---
I wonder if this can be fixed as part of PR 85282.

[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc

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

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

--- Comment #5 from Richard Biener  ---
Btw, the limbo DIE is created via

#0  new_die (tag_value=DW_TAG_variable, parent_die=, 
t=)
at /home/rguenther/src/trunk/gcc/dwarf2out.cc:5882
#1  0x00e006ad in gen_variable_die (
decl=, origin=, 
context_die=)
at /home/rguenther/src/trunk/gcc/dwarf2out.cc:24574
#2  0x00e08766 in gen_decl_die (decl=, 
origin=, ctx=0x0, context_die=)
at /home/rguenther/src/trunk/gcc/dwarf2out.cc:27108
#3  0x00e09a73 in dwarf2out_decl (decl=)
at /home/rguenther/src/trunk/gcc/dwarf2out.cc:27598
#4  0x00e08dce in dwarf2out_late_global_decl (
decl=)
at /home/rguenther/src/trunk/gcc/dwarf2out.cc:27286
#5  0x01944222 in varpool_node::assemble_decl (
this=)
at /home/rguenther/src/trunk/gcc/varpool.cc:603
#6  0x01944a08 in symbol_table::output_variables (this=0x7626a000)
at /home/rguenther/src/trunk/gcc/varpool.cc:764

when compiling without -flto we do not get any DIE for __tag.  In the LTRANS
unit the decl is

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x762803f0 precision:8 min  max

pointer_to_this >
readonly constant addressable asm_written used public static QI t.ii:8:27
size  unit-size 
align:8 warn_if_not_align:0 context 
initial 
(mem/u/c:QI (symbol_ref:DI ("_ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag")
) [0 __tag+0 S1 A8])>

at compile time the symbol is

_ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag/0 (constexpr const char __tag)
  Type: variable definition analyzed 
  Visibility: semantic_interposition public weak comdat
comdat_group:_ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag one_only
  References: 
  Referring: _ZNSt23_Sp_counted_ptr_inplace14_M_get_deleterERKi/9 (addr)
  Availability: not-ready
  Varpool flags: initialized read-only const-value-known

at WPA time

_ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag/0 (__tag)
  Type: variable definition analyzed
  Visibility: externally_visible semantic_interposition
prevailing_def_ironly_exp public weak comdat
comdat_group:_ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag one_only
  References: 
  Referring: _ZNSt23_Sp_counted_ptr_inplace14_M_get_deleterERKi/9 (addr)
  Read from file: a-t.o
  Availability: available
  Varpool flags: initialized read-only const-value-known


When without -flto we reach varpool_node::assemble_decl we see

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76295690 precision:8 min  max

pointer_to_this >
readonly constant addressable used public static tree_1 tree_2 tree_6 weak
read decl_5 decl_6 decl_8 QI t.ii:8:27 size 
unit-size 
align:8 warn_if_not_align:0 context 
initial 
(mem/u/c:QI (symbol_ref/i:DI ("_ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag")
) [0 __tag+0 S1 A8])>

but dwarf2out_late_global_decl just does nothing for this node since
there was no DIE created early for it - we never call early_global_decl
on it, instead we rely on the containing function, _S_ti, to eventually
create a DIE for it, but even that doesn't get one.

I suppose this is all a disconnect between how we handle -g1 with -flto,
and for -g1 dwarf2out_late_global_decl should not fall into

  /* Fill-in any location information we were unable to determine
 on the first pass.  */
  if (VAR_P (decl))
{
  dw_die_ref die = lookup_decl_die (decl);

  /* We may have to generate full debug late for LTO in case debug
 was not enabled at compile-time or the target doesn't support
 the LTO early debug scheme.  */
  if (! die && in_lto_p)
dwarf2out_decl (decl);

another possibility would be to stream "no DIE" info for not late
created decls or experiment with simply removing this path entirely?

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-14
 CC||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Kewen Lin  ---
Confirmed.

This is due to one latent bug. When specifying -Os, it doesn't try to use
SImode parity any more, but tries to use wider mode TImode parity instead, it
resulted in the wrong result.

The current vector parity (including TImode) support is wrong:

;; Vector parity
(define_insn "*p9v_parity2"
  [(set (match_operand:VParity 0 "register_operand" "=v")
(parity:VParity (match_operand:VParity 1 "register_operand" "v")))]
  "TARGET_P9_VECTOR"
  "vprtyb %0,%1"
  [(set_attr "type" "vecsimple")])

The vprtyb[dwq] is for byte parity, it doesn't match the RTL parity semantic
directly.

[Bug tree-optimization/108782] [13 Regression] ICE in add_phi_arg, at tree-phinodes.cc:359

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I'm going to test this.

[Bug tree-optimization/108782] [13 Regression] ICE in add_phi_arg, at tree-phinodes.cc:359

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:994224236e0231807681b62e880d3c2772c69521

commit r13-5983-g994224236e0231807681b62e880d3c2772c69521
Author: Richard Biener 
Date:   Tue Feb 14 11:10:56 2023 +0100

tree-optimization/108782 - nested first order recurrence vectorization

First order recurrence vectorization isn't possible for nested
loops.

PR tree-optimization/108782
* tree-vect-loop.cc (vect_phi_first_order_recurrence_p):
Make sure we're not vectorizing an inner loop.

* gcc.dg/torture/pr108782.c: New testcase.

[Bug target/108729] gcc.target/powerpc/bfp/scalar-test-data-class-12.c fails on power 9 BE

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

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

--- Comment #3 from Kewen Lin  ---
PR108731 has another test case gcc.target/powerpc/bfp/vec-test-data-class-9.c
which needs to be updated too.

[Bug target/108729] gcc.target/powerpc/bfp/scalar-test-data-class-12.c fails on power 9 BE

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

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

--- Comment #2 from Kewen Lin  ---
*** Bug 108731 has been marked as a duplicate of this bug. ***

[Bug testsuite/108731] gcc.target/powerpc/bfp/vec-test-data-class-9.c fails on power 9 BE

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

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
  Component|target  |testsuite

--- Comment #2 from Kewen Lin  ---
Dup.

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

[Bug target/108731] gcc.target/powerpc/bfp/vec-test-data-class-9.c fails on power 9 BE

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-14
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
Confirmed, it's similar to PR108729, need the has_arch_ppc64 checking for used
bif scalar_insert_exp.

[Bug target/108729] gcc.target/powerpc/bfp/scalar-test-data-class-12.c fails on power 9 BE

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed||2023-02-14
 Status|UNCONFIRMED |NEW
 CC||linkw at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Kewen Lin  ---
Confirmed.

Error message is:

gcc/testsuite/gcc.target/powerpc/bfp/scalar-test-data-class-12.c:31:3: error:
‘__builtin_vsx_scalar_insert_exp’ requires the ‘-mcpu=power9’ option and either
the ‘-m64’ or ‘-mpowerpc64’ option

The test case needs:

  /* { dg-require-effective-target has_arch_ppc64 } */

as it uses bif scalar_insert_exp which is only available on 64 bit.

[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1

[elver at google dot com via Gcc-bugs]

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

--- Comment #8 from Marco Elver  ---
Thanks for the quick turnaround!

[Bug sanitizer/108777] Add support for --param asan-kernel-mem-intrinsic-prefix=1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Implemented for GCC 13.1 (to be released in April/May this year).