[Bug testsuite/115443] aarch64: Test gcc.dg/vect/pr99102.c FAIL

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
Version|unknown |15.0

--- Comment #1 from Richard Biener  ---
I assume you are reporting against trunk ...

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #18 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

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

commit r15-1199-g2d6874ac667e215604ad1521e25eed9d12c98956
Author: Gerald Pfeifer 
Date:   Wed Jun 12 09:00:40 2024 +0200

doc: Update Cygwin web link

gcc:
PR target/69374
* doc/install.texi (Specific) <*-*-cygwin>: Update web link.

[Bug tree-optimization/115382] Wrong code with in-order conditional reduction and masked loops

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

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

--- Comment #6 from Richard Biener  ---
Thanks.  It seems to be latent on the branch as well, right?

[Bug c++/115445] [15 Regression] [modules] ICE when repeating an export of function declared in GMF

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug analyzer/115436] False positive with -Wanalyzer-malloc-leak

[rickobranimir at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Branimir Ričko  ---
```
I think there *might* be a true positive here for the case where s->cap ==
0x8000, so that s->cap * 2 becomes 0 due to overflow; should my_str_realloc
be checking for s->str being null for the "needs malloc" case?
```

Yea, you are right. When I was making the example shorter, I must have made it
too short...

This should not be affected by overflows: https://godbolt.org/z/dhPcz8Kj4

Analyzer says that on first call to push, *len* is >= *cap*.
That means that cap is 0.
And then it mallocs on first call.
But then it also deduces that on second call *len* can be >= *cap*.
This can not be because *cap* was set to 8 on the first call and *len* to
1.

```
(b) there's a definite bug in binding_map, where __analyzer_dump () shows an
overlapping concrete binding:

clusters within root region
  cluster for: (*INIT_VAL(s_2(D)))
ESCAPED
key:   {bytes 0-7}
value: 'char *' {UNKNOWN(char *)}
key:   {bytes 0-23}
value: 'struct my_str' {UNKNOWN(struct my_str)}
key:   {bytes 16-23}
value: 'unsigned int' {UNKNOWN(unsigned int)}

where the binding for bytes 0-23 overlaps that for bytes 0-7.
```

Idk what this is or should be, but to me it looks like `struct my_str` should
overlap with `char *`.
`struct my_str` is *s
and
`char *` is `s->str`

Or am I missing something?

[Bug fortran/98769] ICE for gfortran.dg/associate_26.f90 with -fcoarray=lib

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME
  Known to work||13.3.1
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #2 from Andre Vehreschild  ---
Can not reproduce. Seems to have been fixed some when before 13.3.1. Closing.

[Bug fortran/100813] Function of array of pointers to abstract class returning an array since r6-202-gf3b0bb7a560be0f0

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

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

Andre Vehreschild  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104430
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Andre Vehreschild  ---
Reported to be working now. Closing.

[Bug fortran/103112] ICE in gfc_get_descriptor_field for gfortran.dg/coarray_alloc_comp_4.f08 caf single since r7-5771-gde91486c745d5ff6

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

--- Comment #3 from Andre Vehreschild  ---
Duplicate of PR96418. At least the patch for that PR fixes this issue, too.

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

[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #9 from Andre Vehreschild  ---
*** Bug 103112 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/115382] Wrong code with in-order conditional reduction and masked loops

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

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

--- Comment #7 from Robin Dapp  ---
Ah yes, I'm going to push the patch to 14 still.

[Bug c/115456] New: ICE: unrecognizable insn with march=rv64gcv_zvfhmin

[sh.chiang04 at gmail dot com via Gcc-bugs]

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

Bug ID: 115456
   Summary: ICE: unrecognizable insn with march=rv64gcv_zvfhmin
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sh.chiang04 at gmail dot com
  Target Milestone: ---
Target: riscv64*-*-*

The fail test is extract from
gcc.target/riscv/rvv/autovec/vls-vlmax/compress_run-2.c


compile option: 
  -march=rv64gcv_zvfhmin -mabi=lp64d -ftree-vectorize -O3 -mrvv-max-lmul=m1
-mrvv-vector-bits=scalable -fno-vect-cost-model -ffast-math

test case:

#include 
#include 

typedef _Float16 vnx4f __attribute__ ((vector_size (8)));

vnx4f __attribute__ ((noinline, noclone))
test_5 (vnx4f x, vnx4f y)
{
  return __builtin_shufflevector (x, y, 1, 3, 6, 7);
}

int
main (void)
{
  vnx4f test_5_x = {0, 1, 3, 4};
  vnx4f test_5_y = {4, 5, 6, 7};
  vnx4f test_5_except = {1, 4, 6, 7};
  vnx4f test_5_real;
  test_5_real = test_5 (test_5_x, test_5_y);
  for (int i = 0; i < 4; i++)
assert (test_5_real[i] == test_5_except[i]);

  return 0;
}

error message:

compress_run-2.c:27:1: error: unrecognizable insn:
   27 | }
  | ^
(insn 19 18 20 2 (set (reg:HF 150 [ _13 ])
(unspec:HF [
(vec_select:HF (reg:V4HF 134 [ _1 ])
(parallel [
(const_int 0 [0])
]))
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)) "compress_run-2.c":24:5 -1
 (nil))
during RTL pass: vregs
compress_run-2.c:27:1: internal compiler error: in extract_insn, at
recog.cc:2812
0x1a627ef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc/gcc/rtl-error.cc:108
0x1a62834 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../gcc/gcc/rtl-error.cc:116
0x1a0f356 extract_insn(rtx_insn*)
../../../gcc/gcc/recog.cc:2812
0x159ee61 instantiate_virtual_regs_in_insn
../../../gcc/gcc/function.cc:1612
0x15a04aa instantiate_virtual_regs
../../../gcc/gcc/function.cc:1995
0x15a058e execute
../../../gcc/gcc/function.cc:2042

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Torbjorn Svensson :

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

commit r15-1201-gcf5f9171bae1f5f3034dc9a055b77446962f1a8c
Author: Torbjörn SVENSSON 
Date:   Fri Jun 7 10:42:22 2024 +0200

testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.

gcc/testsuite/ChangeLog:

PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Torbjorn Svensson :

https://gcc.gnu.org/g:65bd0655ece268895e5018e393bafb769e201c78

commit r15-1200-g65bd0655ece268895e5018e393bafb769e201c78
Author: Torbjörn SVENSSON 
Date:   Thu Jun 6 17:12:11 2024 +0200

arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog processing of sign extension.

This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.

gcc/ChangeLog:

PR target/115253
* config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
Sign extend for Thumb1.
(thumb1_expand_prologue): Add zero/sign extend.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Torbjorn Svensson :

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

commit r15-1201-gcf5f9171bae1f5f3034dc9a055b77446962f1a8c
Author: Torbjörn SVENSSON 
Date:   Fri Jun 7 10:42:22 2024 +0200

testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.

gcc/testsuite/ChangeLog:

PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 

[Bug target/115452] ICE when dump stv2 for gcc.target/i386/pr70322-2.c with -march=cascadelake

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to Hongtao Liu from comment #0)
> cut from i386-features.cc:1056---
> 
>   if (dump_file)
> fprintf (dump_file, "  Preloading operand for insn %d into r%d\n",
>  INSN_UID (insn), REGNO (tmp));
> --cut end---
> 
> Looks like tmp is SUBREG.

reg_or_subregno should take care for this.

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

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

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

commit r14-10306-ga657148995e1c46178637c8de82d1fab5474a37d
Author: Torbjörn SVENSSON 
Date:   Thu Jun 6 17:12:11 2024 +0200

arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog processing of sign extension.

This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.

gcc/ChangeLog:

PR target/115253
* config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
Sign extend for Thumb1.
(thumb1_expand_prologue): Add zero/sign extend.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit 65bd0655ece268895e5018e393bafb769e201c78)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

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

https://gcc.gnu.org/g:9100e78ba28b1b69d1362d18088e897ca0f99594

commit r14-10307-g9100e78ba28b1b69d1362d18088e897ca0f99594
Author: Torbjörn SVENSSON 
Date:   Fri Jun 7 10:42:22 2024 +0200

testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.

gcc/testsuite/ChangeLog:

PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit cf5f9171bae1f5f3034dc9a055b77446962f1a8c)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Torbjorn Svensson
:

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

commit r13-8844-gbf3ffb44355ca8aeea18c95a2b027023b3dab569
Author: Torbjörn SVENSSON 
Date:   Thu Jun 6 17:12:11 2024 +0200

arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog processing of sign extension.

This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.

gcc/ChangeLog:

PR target/115253
* config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
Sign extend for Thumb1.
(thumb1_expand_prologue): Add zero/sign extend.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit 65bd0655ece268895e5018e393bafb769e201c78)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Torbjorn Svensson
:

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

commit r13-8845-gdfab6851eb557a47a5e61d00ad4c519072a69f61
Author: Torbjörn SVENSSON 
Date:   Fri Jun 7 10:42:22 2024 +0200

testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.

gcc/testsuite/ChangeLog:

PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit cf5f9171bae1f5f3034dc9a055b77446962f1a8c)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Torbjorn Svensson
:

https://gcc.gnu.org/g:55c1687d542e40f0d4ad1d3dc624695a1854d967

commit r12-10550-g55c1687d542e40f0d4ad1d3dc624695a1854d967
Author: Torbjörn SVENSSON 
Date:   Thu Jun 6 17:12:11 2024 +0200

arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog processing of sign extension.

This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.

gcc/ChangeLog:

PR target/115253
* config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
Sign extend for Thumb1.
(thumb1_expand_prologue): Add zero/sign extend.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit 65bd0655ece268895e5018e393bafb769e201c78)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Torbjorn Svensson
:

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

commit r12-10551-g3d9e4eedb6b1f43e5d0cd46c9aa06caf7c2d3500
Author: Torbjörn SVENSSON 
Date:   Fri Jun 7 10:42:22 2024 +0200

testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.

gcc/testsuite/ChangeLog:

PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit cf5f9171bae1f5f3034dc9a055b77446962f1a8c)

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #6 from Arthur Cohen  ---
Sigh... sorry everyone. Clearly autotools/shell scripting requires skills that
I'm not even close to possessing.

(In reply to Andrew Pinski from comment #4)
> (In reply to Sam James from comment #3)
> > Also, a typo: it has ac_cv_search_pthread_crate (not create).
> 
> Someone had rust crate on their mind when they did the patch :).

Yes haha. Thanks for the heads-up Sam, good catch :)

(In reply to Andrew Pinski from comment #5)
> Also it is not just old glibc but most non-"modern" libc out there (e.g.
> Solaris I think). So maybe don't reference glibc in the comments in
> configure.ac either. Just say some libc.

Thanks! Did not know that!

The patch I'm proposing should hopefully fix things and contains an update to
the comment to not mention glibc specifically.

(In reply to Andrew Pinski from comment #2)
> Note when this gets fixed, Make sure that this gets synced over toto
> gdb-binutils repo too since toplevel configure is shared.

Do you mean that I should send this patch there as well?

Here is the patch to configure.ac. I'll obviously regenerate configure as well
when sending it.

>From 2fffac310b4a9cb7ba44d87983e8687fada2753b Mon Sep 17 00:00:00 2001
From: Arthur Cohen 
Date: Wed, 12 Jun 2024 12:37:28 +0200
Subject: [PATCH] configure.ac: Initial patch

---
 configure.ac | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index adb738ac346..0befcc01cd6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2036,7 +2036,7 @@ fi

 AC_SUBST(PICFLAG)

-# Rust requires -ldl and -lpthread if you are using an old glibc that does not
include them by
+# Rust requires -ldl and -lpthread if you are using a libc which does not
include them by
 # default, so we check for them here

 missing_rust_dynlibs=none
@@ -2044,15 +2044,15 @@ missing_rust_dynlibs=none
 AC_SEARCH_LIBS([dlopen], [dl])
 AC_SEARCH_LIBS([pthread_create], [pthread])

-if test $ac_cv_search_dlopen = -ldl; then
+if test "$ac_cv_search_dlopen" = -ldl; then
 CRAB1_LIBS="$CRAB1_LIBS -ldl"
-elif test $ac_cv_search_dlopen = no; then
+elif test "$ac_cv_search_dlopen" = no; then
 missing_rust_dynlibs="libdl"
 fi

-if test $ac_cv_search_pthread_create = -lpthread; then
+if test "$ac_cv_search_pthread_create" = -lpthread; then
 CRAB1_LIBS="$CRAB1_LIBS -lpthread"
-elif test $ac_cv_search_pthread_crate = no; then
+elif test "$ac_cv_search_pthread_create" = no; then
 missing_rust_dynlibs="$missing_rust_dynlibs, libpthread"
 fi

-- 
2.42.0

[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8

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

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

--- Comment #7 from Arthur Cohen  ---
Created attachment 58411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58411&action=edit
Proposed patch for fixing quoting in Rust's dlopen/pthread_create configure
checks

[Bug middle-end/40317] verify_flow_info ICE with nested functions and non-local goto/labels

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

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

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

[Bug tree-optimization/115455] ICE: verify_flow_info failed during GIMPLE pass: cfg with non-local goto from an inner most nested function to an outer nested function

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/115457] New: AArch64 should define __ARM_FEATURE_BF16

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

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

Bug ID: 115457
   Summary: AArch64 should define __ARM_FEATURE_BF16
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

According to the ACLE:
https://github.com/ARM-software/acle/blob/main/main/acle.md#arm_bf16h
GCC should define __ARM_FEATURE_BF16 to allow users to check if the
 header is available.
Since GCC provides that header it should define __ARM_FEATURE_BF16.
LLVM does implement this, so it's an inconsistency between the compilers

[Bug target/115457] AArch64 should define __ARM_FEATURE_BF16

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-12
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Hmm, patch for the arm target was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642184.html

I wonder why aarch64 was not done.

[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms

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

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

--- Comment #5 from Jonathan Wakely  ---
I think
https://github.com/llvm/llvm-project/commit/3b9a1bb1af90db9472340ef2122d3855eb9ba3fc#r142768040
is the real cause of the problem. They wanted to avoid -Wundef errors, so
changed all the macro tests to use #ifdef instead of #if

That is what requires a change to how _PSTL_USAGE_WARNINGS is defined. It also
caused other problems elsewhere downstream:
https://github.com/oneapi-src/oneDPL/issues/1602

[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Pilar Latiesa from comment #3)
> It seems that what is missing is a corresponding change in the macro
> definition logic. It should have been changed to:
> 
> // Check the user-defined macro for warnings
> #if defined(PSTL_USAGE_WARNINGS)
> #define _PSTL_USAGE_WARNINGS
> #endif
> 
> See
> https://github.com/llvm/llvm-project/blob/
> 5ccf19ded09f68bef43275c81c20b0e65f7c0b75/pstl/include/pstl/internal/
> pstl_config.h#L26

The upstream change breaks the previous API though.

It looks like users were able to define PSTL_USAGE_WARNINGS=0 or
PSTL_USAGE_WARNINGS=1 to request warnings to be off or on, respectively. But
the LLVM change means that it only matters whether it's defined or not. This
seems to have been a misguided change to make sure *all* macros are used with
#ifdef not #if. But that breaks the intended use for some of them.

So I think we should either revert the change later in the file which checks
_PSTL_USAGE_WARNINGS, or we should take the user-facing macro's value into
account when deciding whether to define it:

// Check the user-defined macro for warnings
#if defined(PSTL_USAGE_WARNINGS) && PSTL_USAGE_WARNINGS != 0
#define _PSTL_USAGE_WARNINGS
#endif

[Bug c++/86689] [11 Regression] Some combination of SFINAE, overloading, and type deduction showing version inconsistency

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12 Regression] Some |[11 Regression] Some
   |combination of SFINAE,  |combination of SFINAE,
   |overloading, and type   |overloading, and type
   |deduction showing version   |deduction showing version
   |inconsistency   |inconsistency
  Known to fail||12.2.0
  Known to work||12.3.0

--- Comment #7 from Richard Biener  ---
This is also fixed in 12.3.

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

[schwab--- via Gcc-bugs]

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

Bug ID: 115458
   Summary: [15 regression] [RISC-V] ICE in
lra_split_hard_reg_for, at lra-assigns.cc:1868 unable
to find a register to spill
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: riscv64-*-*

Created attachment 58412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58412&action=edit
if_test.cc.ii

$ ./xgcc -B. -O2 -std=c++17 -march=rv64gcv1p0 if_test.cc.ii -S -fno-exceptions
/home/abuild/rpmbuild/BUILD/highway-1.2.0/hwy/tests/if_test.cc: In function
‘void hwy::N_RVV::TestIfNegativeThenNegOrUndefIfZero::operator()(T, D) [with T
= short int; D = hwy::N_RVV::Simd]’:
/home/abuild/rpmbuild/BUILD/highway-1.2.0/hwy/tests/if_test.cc:268:3: error:
unable to find a register to spill
/home/abuild/rpmbuild/BUILD/highway-1.2.0/hwy/tests/if_test.cc:268:3: error:
this is the insn:
(insn 47 613 689 2 (set (reg:RVVM8HI 284)
(if_then_else:RVVM8HI (unspec:RVVMF2BI [
(reg:RVVMF2BI 285 [orig:152 _19 ] [152])
(reg:DI 134 [ _1 ])
(const_int 2 [0x2])
(const_int 0 [0]) repeated x2
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(minus:RVVM8HI (reg:RVVM8HI 374 [orig:145 _12 ] [145])
(reg:RVVM8HI 287 [orig:143 _10 ] [143]))
(reg:RVVM8HI 284)))
"/home/abuild/rpmbuild/BUILD/highway-1.2.0/hwy/tests/if_test.cc":251:19 discrim
1 4899 {pred_subrvvm8hi}
 (expr_list:REG_DEAD (reg:RVVM8HI 374 [orig:145 _12 ] [145])
(expr_list:REG_DEAD (reg:RVVM8HI 287 [orig:143 _10 ] [143])
(expr_list:REG_DEAD (reg:RVVMF2BI 285 [orig:152 _19 ] [152])
(nil)
during RTL pass: reload
/home/abuild/rpmbuild/BUILD/highway-1.2.0/hwy/tests/if_test.cc:268:3: internal
compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868

Only happens with -fno-exceptions.

[Bug c/93537] [11/12 Regression] gcc 9.2 takes a Segmentation Violation when attached file is compiled

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2020-02-01 00:00:00 |2024-6-12
   Priority|P3  |P2
  Known to work||13.1.0, 8.4.0

--- Comment #6 from Richard Biener  ---
Re-confirmed on the 12 branch.

(gdb) up
#3  0x00c5650e in pp_c_enumeration_constant (pp=0x3eef950, 
e=)
at /space/rguenther/src/gcc-12-branch/gcc/c-family/c-pretty-print.cc:1068
1068  if (tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e))
(gdb) l
1063
1064  /* Find the name of this constant.  */
1065  if ((pp->flags & pp_c_flag_gnu_v3) == 0)
1066for (value = TYPE_VALUES (type); value != NULL_TREE;
1067 value = TREE_CHAIN (value))
1068  if (tree_int_cst_equal (DECL_INITIAL (TREE_VALUE (value)), e))
1069break;
1070
1071  if (value != NULL_TREE)
1072pp->id_expression (TREE_PURPOSE (value));
(gdb) p debug_tree (value)
 
VOID /tmp/t.c:2:28
align:1 warn_if_not_align:0 initial >>
value 
constant 99>>

I'd say we likely get the enumeral type wrong, we assume a CONST_DECL but
have

  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:-155847024 alias-set -1 canonical-type
0x76b70540 precision:32 min  max 
values >
value >
chain >

[Bug libstdc++/93672] [11/12 Regression] std::basic_istream::ignore hangs if delim MSB is set

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/113376] [14/15 Regression] Confusing notes when using C++17 parallel algorithms

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||14.1.0, 15.0
  Known to work||13.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |14.2
Summary|Confusing notes when using  |[14/15 Regression]
   |C++17 parallel algorithms   |Confusing notes when using
   ||C++17 parallel algorithms

[Bug target/109137] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12 regression] Compiling   |Compiling ffmpeg with -m32
   |ffmpeg with -m32 on |on x86_64-pc-linux-gnu
   |x86_64-pc-linux-gnu hangs   |hangs on
   |on libavcodec/h264_cabac.c  |libavcodec/h264_cabac.c
   |since   |since
   |r12-9086-g489c81db7d4f75|r12-9086-g489c81db7d4f75
   Target Milestone|12.4|---

[Bug tree-optimization/115447] GCC fails to tail call unless variable wrapped in a block

[mikolajpirog at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mikołaj Piróg  ---
Oh, right, my bad, I forgot about that. Thanks for the clarification!

[Bug middle-end/111009] [12 regression] -fno-strict-overflow erroneously elides null pointer checks and causes SIGSEGV on perf from linux-6.4.10

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/110731] [11/12 Regression] Wrong-code because of wide-int division since r5-424

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||11.4.0, 12.3.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

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

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

commit r11-11478-gbf9c877c4c9939274520a3f694037a9921ba9878
Author: Torbjörn SVENSSON 
Date:   Fri Jun 7 10:42:22 2024 +0200

testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

For Armv8.1-M, the clearing of the registers is handled differently than
for Armv8-M, so update the test case accordingly.

gcc/testsuite/ChangeLog:

PR target/115253
* gcc.target/arm/cmse/extend-return.c: Update test case
condition for Armv8.1-M.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit cf5f9171bae1f5f3034dc9a055b77446962f1a8c)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Torbjorn Svensson
:

https://gcc.gnu.org/g:319081d614dec354ae415472121e0e8ebc4b1402

commit r11-11477-g319081d614dec354ae415472121e0e8ebc4b1402
Author: Torbjörn SVENSSON 
Date:   Thu Jun 6 17:12:11 2024 +0200

arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Properly handle zero and sign extension for Armv8-M.baseline as
Cortex-M23 can have the security extension active.
Currently, there is an internal compiler error on Cortex-M23 for the
epilog processing of sign extension.

This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.

gcc/ChangeLog:

PR target/115253
* config/arm/arm.c (cmse_nonsecure_call_inline_register_clear):
Sign extend for Thumb1.
(thumb1_expand_prologue): Add zero/sign extend.

Signed-off-by: Torbjörn SVENSSON 
Co-authored-by: Yvan ROUX 
(cherry picked from commit 65bd0655ece268895e5018e393bafb769e201c78)

[Bug target/115253] [14/15 regression] New tests added by r14-10122-gad45086178d833 fail on Cortex M23 and M55 bare metal targets

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

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

Torbjorn SVENSSON  changed:

   What|Removed |Added

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

--- Comment #15 from Torbjorn SVENSSON  ---
Both the Cortex-M23 and the Cortex-M55 issues was resolved with the commits
listed in comment 5 though comment 14 (including the backporting to GCC11,
GCC12, GCC13 and GCC14 branches).

[Bug middle-end/54052] [11/12 Regression] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

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

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

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

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

commit r12-10552-g1edc6a71feeb8460fbd4938b8926b5692fbab43f
Author: Richard Biener 
Date:   Mon Feb 19 11:10:50 2024 +0100

rtl-optimization/54052 - RTL SSA PHI insertion compile-time hog

The following tries to address the PHI insertion compile-time hog in
RTL fwprop observed with the PR54052 testcase where the loop computing
the "unfiltered" set of variables possibly needing PHI nodes for each
block exhibits quadratic compile-time and memory-use.

It does so by pruning the local DEFs with LR_OUT of the block, removing
regs that can never be LR_IN (defined by this block) in the dominance
frontier.

PR rtl-optimization/54052
* rtl-ssa/blocks.cc (function_info::place_phis): Filter
local defs by LR_OUT.

(cherry picked from commit c7151283dc747769d4ac4f216d8f519bda2569b5)

[Bug rtl-optimization/114924] [11/12 Regression] Wrong update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71

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

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

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

https://gcc.gnu.org/g:33663c0701a723846527f9bf2ea01d67d7033c0b

commit r12-10555-g33663c0701a723846527f9bf2ea01d67d7033c0b
Author: Alex Coplan 
Date:   Fri May 3 09:23:59 2024 +0100

cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]

The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up
replacing it with the underlying MEM_REF.  This leads to an
inconsistency in the MEM_EXPR information, and could lead to wrong code.

While the walk down to the MEM_REF is necessary to update
MR_DEPENDENCE_CLIQUE, we should use the outer tree expression for the
MEM_EXPR.  This patch does that.

gcc/ChangeLog:

PR rtl-optimization/114924
* cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs,
don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR.

(cherry picked from commit fe40d525619eee9c2821126390df75068df4773a)

[Bug middle-end/111497] [11/12 Regression] ICE building mariadb on i686 since r8-470

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

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

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

https://gcc.gnu.org/g:959cef942508b818c7dcb8df0f3c7bf4968d406a

commit r12-10554-g959cef942508b818c7dcb8df0f3c7bf4968d406a
Author: Vladimir N. Makarov 
Date:   Mon Sep 25 16:19:50 2023 -0400

[PR111497][LRA]: Copy substituted equivalence

When we substitute the equivalence and it becomes shared, we can fail
to correctly update reg info used by LRA.  This can result in wrong
code generation, e.g. because of incorrect live analysis.  It can also
result in compiler crash as the pseudo survives RA.  This is what
exactly happened for the PR.  This patch solves this problem by
unsharing substituted equivalences.

gcc/ChangeLog:

PR middle-end/111497
* lra-constraints.cc (lra_constraints): Copy substituted
equivalence.
* lra.cc (lra): Change comment for calling unshare_all_rtl_again.

gcc/testsuite/ChangeLog:

PR middle-end/111497
* g++.target/i386/pr111497.C: new test.

(cherry picked from commit 3c23defed384cf17518ad6c817d94463a445d21b)

[Bug tree-optimization/40635] [12 Regression] bogus name and location in 'may be used uninitialized' warning

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

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

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

https://gcc.gnu.org/g:844ff32c04a4e36bf69f3878634d9f50aec3a332

commit r12-10553-g844ff32c04a4e36bf69f3878634d9f50aec3a332
Author: Richard Biener 
Date:   Mon Dec 5 16:03:21 2022 +0100

middle-end/40635 - SSA update losing PHI arg loations

The following fixes an issue where SSA update loses PHI argument
locations when updating PHI nodes it didn't create as part of the
SSA update.  For the case where the reaching def is the same as
the current argument opt to do nothing and for the case where the
PHI argument already has a location keep that (that's an indication
the PHI node wasn't created as part of the update SSA process).

PR middle-end/40635
* tree-into-ssa.cc (rewrite_update_phi_arguments): Only
update the argument when the reaching definition is different
from the current argument.  Keep an existing argument
location.

* gcc.dg/uninit-pr40635.c: New testcase.

(cherry picked from commit 0d14720f93a8139a7f234b2762c361e8e5da99cc)

[Bug tree-optimization/40635] [12 Regression] bogus name and location in 'may be used uninitialized' warning

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to fail||12.3.0

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 40635 Summary: [12 Regression] bogus name and location in 'may be used 
uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635

   What|Removed |Added

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

[Bug tree-optimization/83336] [meta-bug] Issues with displaying inlining chain for middle-end warnings

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

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

Bug 40635 Summary: [12 Regression] bogus name and location in 'may be used 
uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635

   What|Removed |Added

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

[Bug middle-end/115459] New: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[macro at orcam dot me.uk via Gcc-bugs]

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

Bug ID: 115459
   Summary: [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG,
at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as
from r14-1187-gd6b756447cd5
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: macro at orcam dot me.uk
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
Target: alpha-linux-gnu

Created attachment 58413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58413&action=edit
reload: Do not emit a MEM SUBREG if it would break alignment rules

With alpha-linux-gnu target as from:

commit d6b756447cd58bcca20e6892790582308b869817
Author: Alexandre Oliva 
Date:   Wed May 24 03:07:56 2023 -0300

[PR100106] Reject unaligned subregs when strict alignment is required

I get:

during RTL pass: ira
+===GNAT BUG DETECTED==+
| 15.0.0 20240610 (experimental) (alpha-linux-gnu) GCC error:  |
| in gen_rtx_SUBREG, at emit-rtl.cc:1032   |
| Error detected around g-debpoo.adb:1896:8|
| Compiling g-debpoo.adb   |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

in libada; the invocation is:

.../obj/gcc/./gcc/xgcc -B.../obj/gcc/./gcc/ -B/usr/alpha-linux-gnu/bin/
-B/usr/alpha-linux-gnu/lib/ -isystem /usr/alpha-linux-gnu/include -isystem
/usr/alpha-linux-gnu/sys-include --sysroot=.../install/usr/sysroot  -c -g -O2
-fPIC -fno-lto -W -Wall -gnatpg -nostdinc -fno-toplevel-reorder  g-debpoo.adb
-o g-debpoo.o

And the triggering RTX is:

(mem:SI (plus:DI (reg/f:DI 15 $15)
(const_int 8400 [0x20d0])) [0  S4 A8])

derived from:

(subreg:HI (mem:SI (plus:DI (reg/f:DI 63 FP)
(const_int 8384 [0x20c0])) [0  S4 A8]) 0)

where the alignment of MEM is set to 8 for some reason (even though it's
SImode) and the alignment of HImode is of course 16.  Consequently the
newly added condition triggers and the assertion then fails.

AFAICT the MEM SUBREG RTX is made by combining:

(insn 1106 1110 1104 54 (set (reg:SI 769)
(mem:SI (plus:DI (reg/f:DI 63 FP)
(const_int 8384 [0x20c0])) [0  S4 A8])) "g-debpoo.adb":1861:21
discrim 2 213 {*movsi}
 (nil))

and:

(insn 1112 1105 1723 54 (set (subreg:DI (reg:SI 771) 0)
(zero_extend:DI (subreg:HI (reg:SI 769) 0))) "g-debpoo.adb":1861:21
discrim 2 52 {zero_extendhidi2}
 (expr_list:REG_DEAD (reg:SI 769)
(nil)))

into one, which is shown as (with the SET destination set to NIL, likely
due to the in-progress state at the time of the assertion):

(insn 1112  1723 54 (set (nil)
(zero_extend:DI (subreg:HI (mem:SI (plus:DI (reg/f:DI 63 FP)
(const_int 8384 [0x20c0])) [0  S4 A8]) 0)))
"g-debpoo.adb":1861:21 discrim 2 52 {zero_extendhidi2}
 (nil))

I have attached a patch that fixes the issue for me, by preventing the
combined MEM subreg from being created.  It's still in testing and I'm
not sure offhand if it's the best or even the correct one.

I note this is with a !TARGET_BWX target (using `-mcpu=ev4' default), so
it's not clear to me why the `reg_or_bwx_memory_operand' predicate has
allowed such a combined operand in the first place, but maybe SUBREGs are
special.  For the record it doesn't trigger with TARGET_BWX targets, e.g.
`-mcpu=ev56'.

I also note that Alpha is still !LRA; I've thought a RISC target would be
easy to convert.  For the time being this issue needs to be fixed though.

[Bug middle-end/115459] [15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

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

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

Richard Biener  changed:

   What|Removed |Added

Version|14.0|15.0
Summary|[14/15 regression]  |[15 regression] Alpha/Linux
   |Alpha/Linux ICE: in |ICE: in gen_rtx_SUBREG, at
   |gen_rtx_SUBREG, at  |emit-rtl.cc:1032 around
   |emit-rtl.cc:1032 around |g-debpoo.adb:1896:8, as
   |g-debpoo.adb:1896:8, as |from r14-1187-gd6b756447cd5
   |from r14-1187-gd6b756447cd5 |
   Target Milestone|--- |15.0

--- Comment #1 from Richard Biener  ---
The change doesn't seem to be on the GCC 14 branch.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|15.0|14.2

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> The change doesn't seem to be on the GCC 14 branch.

r14-1187-gd6b756447cd58b is the commit id where the change was done for
rejecting `unaligned subregs when strict alignment`.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

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

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

--- Comment #3 from Andrew Pinski  ---
Alpha really should move to LRA too.

[Bug testsuite/115460] New: gcc test results deviations

[sadineniharish8446 at gmail dot com via Gcc-bugs]

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

Bug ID: 115460
   Summary: gcc test results deviations
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sadineniharish8446 at gmail dot com
  Target Milestone: ---

I'am using gcc-13.2.0, I have given two consecutive builds with make check-gcc
and compared test results, i have observed following deviations: 

Result from first test build:
 WARNING: program timed out
 FAIL: gcc.target/i386/avx512bw-pr94509-2.c (test for excess errors)   
 UNRESOLVED: gcc.target/i386/avx512bw-pr94509-2.c compilation failed to

Result from second test build: 
 PASS: gcc.target/i386/avx512bw-pr94509-2.c (test for excess errors)
 PASS: gcc.target/i386/avx512bw-pr94509-2.c execution test

In yocto we are using gcc-13.2.0 and after running gcc testsuite and comparing
results we have observed a lot of test result deviations :
for example, test passed in first iteration is moving to unresolved in the next
iteration.

 ptestresult.gcc.gcc.dg/20061026.c (test for excess errors): PASS -> UNRESOLVED
ptestresult.gcc.gcc.dg/20081223-1.c  (test for errors, line 5): PASS ->
UNRESOLVED
ptestresult.gcc.gcc.dg/Warray-bounds-6.c (test for excess errors): PASS
-> UNRESOLVED
ptestresult.gcc.gcc.dg/asm-4.c (test for excess errors): PASS ->
UNRESOLVED
ptestresult.gcc.gcc.dg/attr-access-read-write-2.c  (test for warnings,
line 18): PASS -> UNRESOLVED
ptestresult.gcc.gcc.dg/bitfld-10.c  (test for errors, line 8): PASS ->
UNRESOLVED
ptestresult.gcc.gcc.dg/c2x-complit-4.c: UNRESOLVED -> UNSUPPORTED
ptestresult.gcc.gcc.dg/c2x-float-5.c: UNRESOLVED -> UNSUPPORTED
ptestresult.gcc.gcc.dg/c2x-stdarg-5.c (test for excess errors): PASS ->
UNRESOLVED
ptestresult.gcc.gcc.dg/c99-condexpr-1.c (test for excess errors): PASS
-> UNRESOLVED
ptestresult.gcc.gcc.dg/const-float80-ped.c  (test for warnings, line
5): PASS -> UNRESOLVED


 1)What can be the reason for this?
 2)How to resolve this kind of issues?

 thanks,
 Harish sadineni

[Bug testsuite/115460] gcc test results deviations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-12
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Without the full .log of the testsuite runs, it is hard to debug what is going
wrong. And I personally have not seen this. The only time I have (recently)
seen a timeout compiling has been when the compiler is miscompiled.

[Bug middle-end/115459] [14/15 regression] Alpha/Linux ICE: in gen_rtx_SUBREG, at emit-rtl.cc:1032 around g-debpoo.adb:1896:8, as from r14-1187-gd6b756447cd5

[macro at orcam dot me.uk via Gcc-bugs]

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

--- Comment #4 from Maciej W. Rozycki  ---
(In reply to Andrew Pinski from comment #3)
> Alpha really should move to LRA too.

I can certainly have a look once I'm done with the VAX target unless
someone beats me to it.  Or maybe even before, as I have an important
matter to sort out with the Alpha target now.  We shall see.

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Victor Do Nascimento
:

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

commit r15-1211-gadcc815a01ae009d2768b6afb546e357bd37bbd2
Author: Victor Do Nascimento 
Date:   Wed May 22 12:14:11 2024 +0100

middle-end: Drop __builtin_prefetch calls in autovectorization [PR114061]

At present the autovectorizer fails to vectorize simple loops
involving calls to `__builtin_prefetch'.  A simple example of such
loop is given below:

void foo(double * restrict a, double * restrict b, int n){
  int i;
  for(i=0; i

[Bug libstdc++/115399] std::tr2::dynamic_bitset shift behaves differently from std::bitset

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

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

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

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

commit r15-1213-gbd3a312728fbf8c35a09239b9180269f938f872e
Author: Jonathan Wakely 
Date:   Mon Jun 10 14:08:16 2024 +0100

libstdc++: Fix std::tr2::dynamic_bitset shift operations [PR115399]

The shift operations for dynamic_bitset fail to zero out words where the
non-zero bits were shifted to a completely different word.

For a right shift we don't need to sanitize the unused bits in the high
word, because we know they were already clear and a right shift doesn't
change that.

libstdc++-v3/ChangeLog:

PR libstdc++/115399
* include/tr2/dynamic_bitset (operator>>=): Remove redundant
call to _M_do_sanitize.
* include/tr2/dynamic_bitset.tcc (_M_do_left_shift): Zero out
low bits in words that should no longer be populated.
(_M_do_right_shift): Likewise for high bits.
* testsuite/tr2/dynamic_bitset/pr115399.cc: New test.

[Bug target/115360] cmse_nonsecure_call wrapper on arm missing STT_FUNCTION

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:7593dae69ba06ffe63bc22d26c16b19aa9ab24e8

commit r14-10308-g7593dae69ba06ffe63bc22d26c16b19aa9ab24e8
Author: Andre Vieira 
Date:   Thu Jun 6 16:02:50 2024 +0100

arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

This patch adds missing assembly directives to the CMSE library wrapper to
call
functions with attribute cmse_nonsecure_call.  Without the .type directive
the
linker will fail to produce the correct veneer if a call to this wrapper
function is to far from the wrapper itself.  The .size was added for
completeness, though we don't necessarily have a usecase for it.

libgcc/ChangeLog:

PR target/115360
* config/arm/cmse_nonsecure_call.S: Add .type and .size directives.

(cherry picked from commit c559353af49fe5743d226ac3112a285b27a50f6a)

[Bug target/115360] cmse_nonsecure_call wrapper on arm missing STT_FUNCTION

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:113a104edb5c31fbaa767ba8526f0da4dcf39ebe

commit r13-8846-g113a104edb5c31fbaa767ba8526f0da4dcf39ebe
Author: Andre Vieira 
Date:   Thu Jun 6 16:02:50 2024 +0100

arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

This patch adds missing assembly directives to the CMSE library wrapper to
call
functions with attribute cmse_nonsecure_call.  Without the .type directive
the
linker will fail to produce the correct veneer if a call to this wrapper
function is to far from the wrapper itself.  The .size was added for
completeness, though we don't necessarily have a usecase for it.

libgcc/ChangeLog:

PR target/115360
* config/arm/cmse_nonsecure_call.S: Add .type and .size directives.

(cherry picked from commit c559353af49fe5743d226ac3112a285b27a50f6a)

[Bug target/115360] cmse_nonsecure_call wrapper on arm missing STT_FUNCTION

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira
:

https://gcc.gnu.org/g:448dd002a07aa268c00318066bfe843adebe7292

commit r12-10556-g448dd002a07aa268c00318066bfe843adebe7292
Author: Andre Vieira 
Date:   Thu Jun 6 16:02:50 2024 +0100

arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

This patch adds missing assembly directives to the CMSE library wrapper to
call
functions with attribute cmse_nonsecure_call.  Without the .type directive
the
linker will fail to produce the correct veneer if a call to this wrapper
function is to far from the wrapper itself.  The .size was added for
completeness, though we don't necessarily have a usecase for it.

libgcc/ChangeLog:

PR target/115360
* config/arm/cmse_nonsecure_call.S: Add .type and .size directives.

(cherry picked from commit c559353af49fe5743d226ac3112a285b27a50f6a)

[Bug target/115360] cmse_nonsecure_call wrapper on arm missing STT_FUNCTION

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Andre Simoes Dias Vieira
:

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

commit r11-11479-ge8d2679c0163f190984c6e5c20f17fe0ceec77fd
Author: Andre Vieira 
Date:   Thu Jun 6 16:02:50 2024 +0100

arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

This patch adds missing assembly directives to the CMSE library wrapper to
call
functions with attribute cmse_nonsecure_call.  Without the .type directive
the
linker will fail to produce the correct veneer if a call to this wrapper
function is to far from the wrapper itself.  The .size was added for
completeness, though we don't necessarily have a usecase for it.

libgcc/ChangeLog:

PR target/115360
* config/arm/cmse_nonsecure_call.S: Add .type and .size directives.

(cherry picked from commit c559353af49fe5743d226ac3112a285b27a50f6a)

[Bug target/115360] cmse_nonsecure_call wrapper on arm missing STT_FUNCTION

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

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to work||11.0, 12.0, 13.0, 15.0

--- Comment #7 from avieira at gcc dot gnu.org ---
Fix first applied on gcc-15 and backported up to gcc-11.

[Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-12
 Status|UNCONFIRMED |NEW

[Bug sanitizer/115461] New: lsan doesn't work on s390x

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

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

Bug ID: 115461
   Summary: lsan doesn't work on s390x
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

It appears that -fsanitize=leak has no effect on s390x; it doesn't detect even
the simplest leaks:

```
#include 
#include 

int main() {
void* ptr = malloc(123);
printf("%x\n", ptr);
return 0;
}
```

On x86_64, I get:

=
==69068==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 123 byte(s) in 1 object(s) allocated from:
#0 0x7fd39ce13de5 in malloc (/lib64/liblsan.so.0+0x13de5) (BuildId:
bd0edcefa09c842881bff411016cb80201b5bdd9)
#1 0x401147 in main (/home/mpolacek/x/trunk/gcc/a.out+0x401147) (BuildId:
f29bbf6d55a2764be0623cb24526521a08243448)
#2 0x7fd39cc46149 in __libc_start_call_main (/lib64/libc.so.6+0x28149)
(BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#3 0x7fd39cc4620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a)
(BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#4 0x401074 in _start (/home/mpolacek/x/trunk/gcc/a.out+0x401074) (BuildId:
f29bbf6d55a2764be0623cb24526521a08243448)

SUMMARY: LeakSanitizer: 123 byte(s) leaked in 1 allocation(s).


Incidentally, we have *no* -fsanitize=leak tests whatsoever.

[Bug sanitizer/115461] lsan doesn't work on s390x

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

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

--- Comment #1 from Marek Polacek  ---
LSan and TSan are enabled on s390x since r12-2560:

commit ea22954e7c580d1e54da4ac58301f65d5cf5f76a
Author: Ilya Leoshkevich 
Date:   Thu Jul 22 15:51:56 2021 +0200

IBM Z: Enable LSan and TSan

libsanitizer/ChangeLog:

* configure.tgt (s390*-*-linux*): Enable LSan and TSan for
s390x.

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index 0ca5d9fd924..f635e412bdc 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -41,6 +41,11 @@ case "${target}" in
   sparc*-*-linux*)
;;
   s390*-*-linux*)
+   if test x$ac_cv_sizeof_void_p = x8; then
+   TSAN_SUPPORTED=yes
+   LSAN_SUPPORTED=yes
+   TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_s390x.lo
+   fi
;;
   sparc*-*-solaris2.11*)
;;

[Bug target/115456] RISC-V: ICE: unrecognizable insn with march=rv64gcv_zvfhmin

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #1 from Li Pan  ---
Ack, will take care of it.

[Bug target/115462] New: 416.gamess regressed 4-6% on x86_64 since r15-882-g1d6199e5f8c1c0

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

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

Bug ID: 115462
   Summary: 416.gamess regressed 4-6% on x86_64 since
r15-882-g1d6199e5f8c1c0
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: crazylht at gmail dot com
Blocks: 26163
  Target Milestone: ---

Benchmark 416.gamess from SPECINT 2006 recently regressed on all
x86_64 CPUs we track using many of the compiler options we track.  I
have bisected the one on Zen3 CPU using -O2 -flto (so -march=generic)
to r15-882-g1d6199e5f8c1c0 (liuhongt: Reduce cost of MEM (A + imm)).

Regressing hosts and options:

  - zen2 -O2 -flto: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=292.50.0
  - zen2 -O2 -march=native: 6%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=291.50.0
  - zen2 -O2 -flto -march=native: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=290.50.0
  - zen2 -Ofast: 4%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=300.50.0

  - skylake -O2: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=784.50.0
  - skylake -O2 flto: 4%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=799.50.0
  - skylake -O2 -march=native: 6%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=787.50.0
  - skylake -O2 -flto -march=native: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=788.50.0
  - skylake -Ofast: 4%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=789.50.0

  - zen3 -O2 -flto: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=469.50.0
  - zen3 -O2 -flto -fprofile-use: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=464.50.0
  - zen3 -O2 -flto -march=native: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=465.50.0
  - zen3 -Ofast: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=466.50.0

  - zen4 -O2 -flto: 4%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=956.50.0
  - zen4 -O2 -march=native: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=961.50.0
  - zen4 -O2 -flto -march=native: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=993.50.0
  - zen4 -Ofast: 4%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=967.50.0
  - zen4 -Ofast -march=native: 6%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=965.50.0
  - zen4 -Ofast -flto -march=native: 5%
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=992.50.0


Referenced Bugs:

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

[Bug target/115463] New: 526.blender_r regressed 5% on Zen2 with -Ofast -flto -march=native since r15-1058-gc989e59fc99d99

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

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

Bug ID: 115463
   Summary: 526.blender_r regressed 5% on Zen2 with -Ofast -flto
-march=native since r15-1058-gc989e59fc99d99
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hongyuw at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

The run-time of benchmark 526.blender_r from SPEC INTrate 2017 has
regressed 5.3% on Zen2-based CPUs when compiled with -Ofast -flto
-march-mnative since r15-1058-gc989e59fc99d99 (Hongyu Wang: [APX CCMP]
Support APX CCMP).  I was not expecting this patch to cause any
changes in code generated for non-APX CPUs but I have double checked.

The regression can be seen/tracked at
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.487.0


There are also smaller regressions that happened around the same time:

- zen2 -Ofast -flto -fprofile-use -march=native: 3%
  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=286.487.0

- skylake -Ofast -flto -march=native: 4%
  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=801.487.0

- skylake -Ofast -flto -fprofile-use -march=native: 3%
  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.487.0

- zen3 -Ofast -flto -march=native: 2%
  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=475.487.0


Referenced Bugs:

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

[Bug target/115463] 526.blender_r regressed 5% on Zen2 with -Ofast -flto -march=native since r15-1058-gc989e59fc99d99

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||115370

--- Comment #1 from Andrew Pinski  ---
Most likely similar to PR 115370. Yes enabling ccmp for x86_64's APX
unfortunately enables it for all of x86_64 due to the way ccmp was originally
designed (thinking it was enabled for the whole target or not).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115370
[Bug 115370] [15 regression] gcc.target/i386/pr77881.c FAIL

[Bug target/115370] [15 regression] gcc.target/i386/pr77881.c FAIL

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-12
 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/115449] `(truncate)a` and `(nop_convert)~(truncate)a` are bitwise inversion of each other

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

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

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

https://gcc.gnu.org/g:0256121e2f23ac3550e87410c9b1e690c8edfc7c

commit r15-1215-g0256121e2f23ac3550e87410c9b1e690c8edfc7c
Author: Andrew Pinski 
Date:   Tue Jun 11 17:16:42 2024 -0700

match: Improve gimple_bitwise_equal_p and gimple_bitwise_inverted_equal_p
for truncating casts [PR115449]

As mentioned by Jeff in r15-831-g05daf617ea22e1d818295ed2d037456937e23530,
we don't handle
`(X | Y) & ~Y` -> `X & ~Y` on the gimple level when there are some
different signed
(but same precision) types dealing with matching `~Y` with the `Y` part.
This
improves both gimple_bitwise_equal_p and gimple_bitwise_inverted_equal_p to
be able to say `(truncate)a` and `(truncate)a` are bitwise_equal and
that `~(truncate)a` and `(truncate)a` are bitwise_invert_equal.

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

PR tree-optimization/115449

gcc/ChangeLog:

* gimple-match-head.cc (gimple_maybe_truncate): New declaration.
(gimple_bitwise_equal_p): Match truncations that differ only
in types with the same precision.
(gimple_bitwise_inverted_equal_p): For matching after
bit_not_with_nop
call gimple_bitwise_equal_p.
* match.pd (maybe_truncate): New match pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/bitops-10.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/115449] `(truncate)a` and `(nop_convert)~(truncate)a` are bitwise inversion of each other

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/115464] New: ICE when building libaom on arm64

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

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

Bug ID: 115464
   Summary: ICE when building libaom on arm64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
# gcc -c highbd_convolve_sve2.c.i -fpermissive -march=armv9-a+sve2 -O
during RTL pass: expand
highbd_convolve_sve2.c.i: In function ‘convolve4_4_x’:
highbd_convolve_sve2.c.i:10:7: internal compiler error: in
paradoxical_subreg_p, at rtl.h:3213
   10 |   svget_neonq_s16(svtbl_s16(svset_neonq_s16(svundef_s16(),
aom_tbl_s16_s),
  |  
^~~~
   11 | svset_neonq_u16(svundef_u16(), tbl)));
  | ~
0xcefc611f paradoxical_subreg_p(machine_mode, machine_mode)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/rtl.h:3213
0xcefc611f simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/simplify-rtx.cc:7751
0xcefcefeb simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<2u, unsigned long>)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/simplify-rtx.cc:7998
0xcf667d1b simplify_gen_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<2u, unsigned long>)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/rtl.h:3552
0xcf667d1b expand
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/config/aarch64/aarch64-sve-builtins-base.cc:1177
0xcf64d2eb aarch64_sve::expand_builtin(unsigned int, tree_node*, rtx_def*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/config/aarch64/aarch64-sve-builtins.cc:4790
0xcea1e7af expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/expr.cc:12357
0xcea33c23 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/expr.cc:9447
0xcea33c23 store_expr(tree_node*, rtx_def*, int, bool, bool)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/expr.cc:6747
0xcea3b587 expand_assignment(tree_node*, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/expr.cc:6468
0xcea3b587 expand_assignment(tree_node*, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/expr.cc:5953
0xce86cf97 expand_call_stmt
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cfgexpand.cc:2893
0xce86cf97 expand_gimple_stmt_1
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cfgexpand.cc:3962
0xce86cf97 expand_gimple_stmt
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cfgexpand.cc:4104
0xce87586f expand_gimple_basic_block
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cfgexpand.cc:6160
0xce877da7 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cfgexpand.cc:6899
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

---

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/15/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include
--datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15
--mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15/man
--infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit c8bf41759fe849050fcb5c5105483c9db6b15da2'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --en

[Bug sanitizer/115461] lsan doesn't work on s390x

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

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

--- Comment #2 from Andrew Pinski  ---
Does it work with upstream (LLVM)?

[Bug target/115464] ICE when building libaom on arm64

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

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

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

[Bug target/115464] ICE when building libaom on arm64

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

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

--- Comment #2 from Sam James  ---
Reduced:
```
#pragma GCC aarch64 "arm_neon.h"
typedef __Int16x8_t int16x8_t;
typedef __Uint16x8_t uint16x8_t;
#pragma GCC aarch64 "arm_sve.h"
#pragma GCC aarch64 "arm_neon_sve_bridge.h"
int16x8_t aom_tbl_s16_s, convolve4_4_x___trans_tmp_2;
int convolve4_4_x(uint16x8x2_t permute_tbl) {
uint16x8_t tbl = permute_tbl.val[1];
convolve4_4_x___trans_tmp_2 =
svget_neonq_s16(svtbl_s16(svset_neonq_s16(svundef_s16(), aom_tbl_s16_s),
svset_neonq_u16(svundef_u16(), tbl)));
}
```

[Bug libstdc++/115399] std::tr2::dynamic_bitset shift behaves differently from std::bitset

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk. I'll probably backport it to the release branches at some
point.

[Bug target/115176] rbit pattern should use bitreverse rtl now

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

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

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

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

commit r15-1216-gc2f0aaf7539c42b024ed6b3fb6909bd2c86bb206
Author: Andrew Pinski 
Date:   Tue Jun 11 20:36:34 2024 +

aarch64: Use bitreverse rtl code instead of unspec [PR115176]

Bitreverse rtl code was added with r14-1586-g6160572f8d243c. So let's
use it instead of an unspec. This is just a small cleanup but it does
have one small fix with respect to rtx costs which didn't handle vector
modes
correctly for the UNSPEC and now it does.
This is part of the first step in adding __builtin_bitreverse's builtins
but it is independent of it though.

Bootstrapped and tested on aarch64-linux-gnu with no regressions.

gcc/ChangeLog:

PR target/115176
* config/aarch64/aarch64-simd.md
(aarch64_rbit): Use
bitreverse instead of unspec.
* config/aarch64/aarch64-sve-builtins-base.cc (svrbit): Convert
over to using
rtx_code_function instead of unspec_based_function.
* config/aarch64/aarch64-sve.md: Update comment where RBIT is
included.
* config/aarch64/aarch64.cc (aarch64_rtx_costs): Handle BITREVERSE
like BSWAP.
Remove UNSPEC_RBIT support.
* config/aarch64/aarch64.md (unspec): Remove UNSPEC_RBIT.
(aarch64_rbit): Use bitreverse instead of unspec.
* config/aarch64/iterators.md (SVE_INT_UNARY): Add bitreverse.
(optab): Likewise.
(sve_int_op): Likewise.
(SVE_INT_UNARY): Remove UNSPEC_RBIT.
(optab): Likewise.
(sve_int_op): Likewise.
(min_elem_bits): Likewise.

Signed-off-by: Andrew Pinski 

[Bug target/115176] rbit pattern should use bitreverse rtl now

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug libstdc++/115444] std::copy_n generates more code than needed

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #1 from Jiang An  ---
> I think it's within its rights to do that, and thus the behavior of this 
> program
> is undefined by the standard (specifically, 
> https://eel.is/c++draft/alg.copy#12
> doesn't claim that it *is* defined, so it's undefined).

Sounds interesting. At least UB won't be triggered if each `*(result + i) =
*(first + i)` is sequentially executed.

So are the so-called sequential (non-parallel) versions of algorithms not
really sequential?

[Bug libstdc++/115444] std::copy_n generates more code than needed

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #2 from Jiang An  ---
Oh, UB seems still introduced by [iterator.requirements.general]/12
(https://eel.is/c++draft/iterator.requirements.general#12).

> The result of the application of library functions to invalid ranges is
> undefined.

Although this rule seems defective as it seemingly makes
std::unreachable_sentinel almost unusable.

[Bug target/113858] `ldr s0/h0/b0` should be used to zero extend into the full register

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-12
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
I have someone working on this.

[Bug bootstrap/115465] New: [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

Bug ID: 115465
   Summary: [15 Regression] aarch64-early-ra.cc:3449:23: error:
‘class pretty_printer’ has no member named ‘buffer’
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

Looks like I broke the build on aarch64 with r15-1209-gc5e3be456888aa.

  https://builder.sourceware.org/buildbot/#/builders/266/builds/3613

../../gcc/gcc/config/aarch64/aarch64-early-ra.cc: In member function ‘void
{anonymous}::early_ra::process_block(basic_block, bool)’:
../../gcc/gcc/config/aarch64/aarch64-early-ra.cc:3449:23: error: ‘class
pretty_printer’ has no member named ‘buffer’; did you mean ‘output_buffer*
pretty_printer::m_buffer’? (not accessible from this context)
 3449 |   rtl_slim_pp.buffer->stream = dump_file;
  |   ^~
In file included from ../../gcc/gcc/rtl-ssa.h:39,
 from ../../gcc/gcc/config/aarch64/aarch64-early-ra.cc:49:
../../gcc/gcc/pretty-print.h:327:18: note: declared private here
  327 |   output_buffer *m_buffer;

Sorry; am working on a fix.

[Bug bootstrap/115465] [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-12

[Bug bootstrap/115465] [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Keywords||build
   Target Milestone|--- |15.0

[Bug bootstrap/115465] [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

--- Comment #1 from Andrew Pinski  ---
  pretty_printer rtl_slim_pp;
  rtl_slim_pp.buffer->stream = dump_file;
  print_insn (&rtl_slim_pp, insn, 1);
  pp_flush (&rtl_slim_pp);
  fprintf (dump_file, "\n");


There seems to be a better way of implement this than the above too.

Maybe change dump_insn_slim to take an bool argument that defaults to true and
then if it was false use print_insn instead of print_insn_with_notes.

[Bug tree-optimization/114061] GCC fails vectorization when using __builtin_prefetch

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 114061 Summary: GCC fails vectorization when using __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061

   What|Removed |Added

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

[Bug testsuite/115460] gcc test results deviations

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

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

--- Comment #2 from Andrew Pinski  ---
Note you want to look into the gcc.log file to understand why things are
turning into UNRESOLVED. the gcc.sum file is only a summary of what is going
on.

Also depending on the board you are using or how you are running the testsuite,
it could be that the ssh connection has been broken due to the machine
crashing. So you really should look into the gcc.log file to understand the
exact failure here.

[Bug target/115464] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)

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

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

Tamar Christina  changed:

   What|Removed |Added

   Last reconfirmed||2024-06-12
 CC||tnfchris at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Tamar Christina  ---
Confirmed, slightly more cleaned up example:

#include 
#include 
#include 

int16x8_t
convolve4_4_x (uint16x8x2_t permute_tbl, svint16_t res)
{
return svget_neonq_s16 (
svtbl_s16 (res,
   svset_neonq_u16 (svundef_u16 (), permute_tbl.val[0])));
}

[Bug sanitizer/115461] lsan doesn't work on s390x

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

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

--- Comment #3 from Marek Polacek  ---
(In reply to Andrew Pinski from comment #2)
> Does it work with upstream (LLVM)?

I don't think so; I've tried Fedora 40 clang:

$ clang k.c -fsanitize=leak; ./a.out

and it also didn't report anything.  So probably we need an LLVM bug as well?

[Bug c++/99678] [concepts] requires-clause allows undeclared identifier

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||eratchias at gmail dot com

--- Comment #3 from Patrick Palka  ---
*** Bug 115429 has been marked as a duplicate of this bug. ***

[Bug c++/115429] requires clause wrongly accepts unqualified access to inherited static members

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Patrick Palka  ---
This is essentially a dup of PR99678 -- we should have rejected the
requires-clause at parse time since unqualified lookup for 'con' failed, but
because we didn't we naturally ended up repeating unqualified lookup at
instantiation time which succeeded.

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

[Bug c++/99678] [concepts] requires-clause allows undeclared identifier

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-12

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 115429 Summary: requires clause wrongly accepts unqualified access to 
inherited static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115429

   What|Removed |Added

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

[Bug bootstrap/115465] [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

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

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

commit r15-1220-ge35f4eab68773b08324f9784ca69f8ace3c657cc
Author: David Malcolm 
Date:   Wed Jun 12 14:24:47 2024 -0400

pretty_printer: unbreak build on aarch64 [PR115465]

I missed this target-specific usage of pretty_printer::buffer when
making the fields private in r15-1209-gc5e3be456888aa; sorry.

gcc/ChangeLog:
PR bootstrap/115465
* config/aarch64/aarch64-early-ra.cc (early_ra::process_block):
Update for fields of pretty_printer becoming private in
r15-1209-gc5e3be456888aa.

Signed-off-by: David Malcolm 

[Bug bootstrap/115465] [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Build breakage should be fixed by the above patch.

[Bug bootstrap/115465] [15 Regression] aarch64-early-ra.cc:3449:23: error: ‘class pretty_printer’ has no member named ‘buffer’

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

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> Build breakage should be fixed by the above patch.

Indeed, https://builder.sourceware.org/buildbot/#/builders/266/builds/3620
succeeded.

[Bug target/115464] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Tamar Christina  ---
Looks like the Neon lowpart optimization doesn't take into account aggregate
vectors.

That means simplest reproduction is:

#include 
#include 
#include 

svuint16_t
convolve4_4_x (uint16x8x2_t permute_tbl)
{
return svset_neonq_u16 (svundef_u16 (), permute_tbl.val[1]);
}

This generates a subreg between from E_V2x8HImode to E_VNx8HImode.

This subreg is an invalid paradoxical subreg as there's no strict ordered
relationship between the modes.

This fails because ordered_p does not have a relationship defined between a
poly vector
and an aggregate non-poly vector.

I think one should probably be provided, essentially the NEON<->SVE bridge is
broken for aggregate types in general at the moment.  I don't know the exact
semantics for poly-ints.

I tried patching ordered_p but the ICE just moves. Any thoughts Richard?