[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[kkanas at fastmail dot com via Gcc-bugs]

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

Krzysztof Kanas  changed:

   What|Removed |Added

 CC||kkanas at fastmail dot com

--- Comment #4 from Krzysztof Kanas  ---
I bisected the issue and it seems that commit
0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

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

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

--- Comment #5 from Hongtao Liu  ---
(In reply to Krzysztof Kanas from comment #4)
> I bisected the issue and it seems that commit
> 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.

I guess the real guilty commit is 

commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7
Author: Uros Bizjak 
Date:   Thu May 25 19:40:26 2023 +0200

i386: Use 2x-wider modes when emulating QImode vector instructions

Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI ->
V16HImode)
instructions when available.  Currently, the compiler generates following
assembly for V16QImode multiplication (-mavx2):

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #6 from Haochen Jiang  ---
(In reply to Hongtao Liu from comment #5)
> (In reply to Krzysztof Kanas from comment #4)
> > I bisected the issue and it seems that commit
> > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.
> 
> I guess the real guilty commit is 
> 
> commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7
> Author: Uros Bizjak 
> Date:   Thu May 25 19:40:26 2023 +0200
>  
> i386: Use 2x-wider modes when emulating QImode vector instructions
>  
> Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI ->
> V16HImode)
> instructions when available.  Currently, the compiler generates following
> assembly for V16QImode multiplication (-mavx2):

Yes, since 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d only fixed a typo in that
patch.

Original thread: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619745.html

[Bug sanitizer/115127] New: [12/13/14 Regression] passing zero to __builtin_ctz() check missing

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 115127
   Summary: [12/13/14 Regression] passing zero to __builtin_ctz()
check missing
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
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: ---

Created attachment 58220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58220&action=edit
test case

OS: Ubuntu 22.04.3 LTS
We found that UBSAN missed checking if zero is passed to __builtin_ctz() when
compiling with gcc-12.3.0, gcc-13.2.0, gcc-14.1.0.

$ ../compiler-builds/gcc-12.3.0_build/bin/gcc -fsanitize=undefined -g -lgcc_s
-I/home/csmith/include/csmith-2.3.0 testcase.c -o exec

$ timeout 1s ./exec 2>exec.err

$ cat exec.err

$ ../compiler-builds/gcc-11.4.0_build/bin/gcc -fsanitize=undefined -g -lgcc_s
-I/home/csmith/include/csmith-2.3.0 testcase.c -o exec

$ timeout 1s ./exec 2>exec.err

$ cat exec.err
test1_176.c:202:83: runtime error: passing zero to ctz(), which is not a valid
argument test1_176.c:202: runtime error: passing zero to ctz(), which is not a
valid argument test1_176.c:202: runtime error: passing zero to ctz(), which is
not a valid argument test1_176.c:202: runtime error: passing zero to ctz(),
which is not a valid argument test1_176.c:202: runtime error: passing zero to
ctz(), which is not a valid argument test1_176.c:202: runtime error: passing
zero to ctz(), which is not a valid argument

[Bug sanitizer/115127] [12/13/14/15 Regression] passing zero to __builtin_ctz() check missing

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12/13/14/15 Regression]
   |passing zero to |passing zero to
   |__builtin_ctz() check   |__builtin_ctz() check
   |missing |missing
   Keywords||needs-reduction
   Target Milestone|--- |12.4

[Bug middle-end/115128] New: [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

Bug ID: 115128
   Summary: [15 regression] ICE when building aflplusplus
(internal compiler error: in type, at
value-range.h:983)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58221&action=edit
afl-compiler-rt.i.xz

```
$ gcc -c afl-compiler-rt.i -march=znver2 -O3
instrumentation/afl-compiler-rt.o.c:1442:1: warning: constructor priorities
from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor]
instrumentation/afl-compiler-rt.o.c:1450:1: warning: constructor priorities
from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor]
instrumentation/afl-compiler-rt.o.c:1465:1: warning: constructor priorities
from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor]
instrumentation/afl-compiler-rt.o.c:1509:1: warning: constructor priorities
from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor]
instrumentation/afl-compiler-rt.o.c: In function ‘__afl_start_forkserver’:
instrumentation/afl-compiler-rt.o.c:1161:9: warning: ignoring return value of
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
instrumentation/afl-compiler-rt.o.c:1174:11: warning: ignoring return value of
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
instrumentation/afl-compiler-rt.o.c: In function ‘__afl_start_snapshots’:
instrumentation/afl-compiler-rt.o.c:895:9: warning: ignoring return value of
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
instrumentation/afl-compiler-rt.o.c:907:11: warning: ignoring return value of
‘write’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
during IPA pass: cp
instrumentation/afl-compiler-rt.o.c: At top level:
instrumentation/afl-compiler-rt.o.c:2658:1: internal compiler error: in type,
at value-range.h:983
0x55dea9caac63 irange::type() const
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-range.h:983
0x55deab9da9fe Value_Range::type()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-range.h:777
0x55deab9da9fe propagate_vr_across_jump_function
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:2559
0x55deab9de6b8 propagate_constants_across_call
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:3035
0x55deab9ea2bc propagate_constants_topo
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:3921
0x55deab9ea2bc ipcp_propagate_stage
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:4103
0x55deab9ea2bc ipcp_driver
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:6440
0x55deab9ea2bc execute
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:6515
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/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit bc7d81fe2f725b4043ce8b9ffb11d80032ce3f75'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-h

[Bug tree-optimization/115120] Bad interaction between ivcanon and early break vectorization

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

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

--- Comment #3 from Tamar Christina  ---
That makes sense, though I also wonder how it works for scalar multi exit
loops, IVops has various checks on single exits.

I guess one problem is that the code in IVops that does this uses the exit to
determine niters.

But in the case of the multiple exits vector code the vectorizer could have
picked a different exit.

So I guess the question is how do we even tell which one is used or could the
transformation be driven from the PHI nodes themselves instead of an exit.

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-reduction
   Target Milestone|--- |15.0
Version|unknown |15.0

[Bug lto/115129] New: [12/13/14/15 regression] ICE on recursive realloc call with LTO

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

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

Bug ID: 115129
   Summary: [12/13/14/15 regression] ICE on recursive realloc call
with LTO
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Working on reducing something else but noticed this in the process.

url.i:
```
struct growable main_dest;
void* realloc();

struct growable {
  char base;
} append_string(struct growable *dest) {
  struct growable G_ = *dest;
  long DR_needed_size;
  while (DR_needed_size)
realloc(G_);
}
int main() { append_string(&main_dest); }
```

xmalloc.i:
```
void *realloc(void *p, unsigned long s) { realloc(p, s); }
```

```
$ gcc url.i xmalloc.i -flto -O2
[...]
during GIMPLE pass: fre
url.i: In function ‘main’:
url.i:12:5: internal compiler error: in execute_todo, at passes.cc:2138
   12 | int main() { append_string(&main_dest); }
  | ^
0x55b08ec670be execute_todo
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:2138
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.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/15/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

[Bug lto/115129] [12/13/14/15 regression] ICE on recursive realloc call with LTO

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |14.1.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |12.4
   Last reconfirmed||2024-05-17

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

Setting value number of p_4 to 0B (changed)
Value numbering stmt = realloc (p_4, s_5(D));

...

   [local count: 8687547538]:
  __builtin_malloc (s_5(D));

but virtual operands are not updated.  Somewhere we fold this and break things
this way.  gimple_fold_builtin_realloc likely.

[Bug lto/115129] [12/13/14/15 regression] ICE on recursive realloc call with LTO

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Ah, because that realloc definition makes realloc CONST, but the replacement
builtin is not.

Honza, I know we still have that loop pattern detection bug detecting
memcpy as memcpy.  What's our (IPA?) strategy in these kind of situations?
Should we avoid messing with builtin implementation attributes?

We can of course sanity-check at folding time and leave realloc w/o virtual
operands alone, but ...

[Bug tree-optimization/115130] New: (early-break) [meta-bug] early break vectorization

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

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

Bug ID: 115130
   Summary: (early-break) [meta-bug] early break vectorization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: meta-bug, missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

Meta tickets about early break vectorization to better keep track of early
break specific issues


Referenced Bugs:

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

[Bug tree-optimization/115130] (early-break) [meta-bug] early break vectorization

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

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

Tamar Christina  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-17
 Status|UNCONFIRMED |NEW

[Bug target/115115] [12/13/14/15 Regression] highway-1.0.7 wrong _mm_cvttps_epi32() constant fold

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

Jan Wassenberg  changed:

   What|Removed |Added

 CC||jan.wassenberg at gmail dot com

--- Comment #8 from Jan Wassenberg  ---
Thanks Andrew and Sergei :) I agree we should not require a certain outcome for
converting source values which are outside the domain of the target type. We'll
update the test.

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-17
 Status|UNCONFIRMED |NEW

--- Comment #1 from Aldy Hernandez  ---
Mine.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Hongtao Liu from comment #5)
> (In reply to Krzysztof Kanas from comment #4)
> > I bisected the issue and it seems that commit
> > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.
> 
> I guess the real guilty commit is 
> 
> commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7
> Author: Uros Bizjak 
> Date:   Thu May 25 19:40:26 2023 +0200
>  
> i386: Use 2x-wider modes when emulating QImode vector instructions
>  
> Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI ->
> V16HImode)
> instructions when available.  Currently, the compiler generates following
> assembly for V16QImode multiplication (-mavx2):

The patch is at:

https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619715.html

As mentioned in Comment #3, it looks that VPERMQ is a problematic insn. This
should be reflected in some cost function. Alternatively, we can simply change
the first line in:

+  if ((qimode == V16QImode && !TARGET_AVX2)
+  || (qimode == V32QImode && !TARGET_AVX512BW)
+  /* There are no V64HImode instructions.  */
+  || qimode == V64QImode)
+ return false;

to check "qimode == V16QImode && !TARGET_AVX512VL" to avoid VPERMQ:

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 4e16aedc5c1..450035ea9e6 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -24493,7 +24493,7 @@ ix86_expand_vecop_qihi2 (enum rtx_code code, rtx dest,
rtx op1, rtx op2)
   bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT;
   bool uns_p = code != ASHIFTRT;

-  if ((qimode == V16QImode && !TARGET_AVX2)
+  if ((qimode == V16QImode && !TARGET_AVX512VL)
   || (qimode == V32QImode && (!TARGET_AVX512BW || !TARGET_EVEX512))
   /* There are no V64HImode instructions.  */
   || qimode == V64QImode)

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

--- Comment #2 from Sam James  ---
Reduction is nearly done.

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

--- Comment #3 from Aldy Hernandez  ---
Created attachment 58222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58222&action=edit
patch in testing

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

--- Comment #4 from Sam James  ---
Reduced:
```

long XXH3_len_4to8_64b_len, XXH3_len_0to16_64b___trans_tmp_3,
XXH3_mix2Accs_acc,
XXH3_64bits_internal___trans_tmp_8;
typedef unsigned long XXH3_hashLong64_f();
void *XXH3_64bits_internal_input;
int XXH3_64bits_internal___trans_tmp_1;
void XXH3_mul128_fold64();
static void XXH3_mergeAccs(unsigned long) {
  for (;;)
XXH3_mul128_fold64(XXH3_mix2Accs_acc);
}
static __attribute__((noinline)) unsigned long
XXH3_hashLong_64b_default(void *, unsigned long len) {
  XXH3_mergeAccs(len * 7);
}
__attribute__((always_inline)) long
XXH3_64bits_internal(unsigned long len, XXH3_hashLong64_f f_hashLong) {
  if (len <= 16) {
long keyed =
XXH3_64bits_internal___trans_tmp_1 ^ XXH3_len_0to16_64b___trans_tmp_3;
XXH3_mul128_fold64(keyed, XXH3_len_4to8_64b_len);
return XXH3_64bits_internal___trans_tmp_8;
  }
  f_hashLong(XXH3_64bits_internal_input, len);
}
static void XXH_INLINE_XXH3_64bits(unsigned long len) {
  XXH3_64bits_internal(len, XXH3_hashLong_64b_default);
}
void __cmplog_rtn_hook() { XXH_INLINE_XXH3_64bits(sizeof(long)); }
```

(and thank you aldy!)

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-17

--- Comment #8 from Uroš Bizjak  ---
A better patch:

--cut here--
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 4e16aedc5c1..88bfc43201b 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -24493,6 +24493,10 @@ ix86_expand_vecop_qihi2 (enum rtx_code code, rtx dest,
rtx op1, rtx op2)
   bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT;
   bool uns_p = code != ASHIFTRT;

+  /* ??? VPERMQ is slow and VPMOWVB is only available under AVX512BW.  */
+  if (!TARGET_AVX512BW)
+return false;
+
   if ((qimode == V16QImode && !TARGET_AVX2)
   || (qimode == V32QImode && (!TARGET_AVX512BW || !TARGET_EVEX512))
   /* There are no V64HImode instructions.  */
--cut here--

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #8)
> A better patch:

The real issue is that the following permutation (truncation):

+  for (i = 0; i < d.nelt; ++i)
+   d.perm[i] = i * 2;
+
+  ok = ix86_expand_vec_perm_const_1 (&d);

results in a slow code involving VPERMQ. Ideally, ix86_expand_vec_perm_const_1
should emit faster code for truncation, because this will benefit other code as
well.

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #5 from Sam James  ---
Bit more (and no more now):
```
long a, b, c;
typedef unsigned long d();
int e;
void f();
static void g(unsigned long) {
  for (;;)
f(c);
}
static __attribute__((noinline)) unsigned long h(void *, unsigned long i) {
  g(i * 7);
}
__attribute__((always_inline)) int j(unsigned long k, d i) {
  if (k <= 1) {
int d = e ^ b;
f(d, a);
return 1;
  }
  i(1, k);
}
static void l(unsigned long k) { j(k, h); }
void m() { l(1); }

```

[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
I have a patch.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #10 from Haochen Jiang  ---
A patch like Comment 8 could definitely solve the problem. But I need to test
more benchmarks to see if there is surprise.

But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
better.

[Bug target/115115] [12/13/14/15 Regression] highway-1.0.7 wrong _mm_cvttps_epi32() constant fold

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Jan Wassenberg  ---
On second thought, we are actually trying to convert out-of-bounds values to
the closest representable. We use the documented behavior of the instruction,
as mentioned in #5, and then correct the result afterwards.

Per the comment in the code below, it seems GCC since v11 or even 10 has been
assuming this is UB, and optimizing out our fix.

I do believe this is compiler misbehavior, rooted in treating the operation as
if it were scalar code. But vector instructions are more modern and have
tighter specs; for example, integers are 2's complement and wraparound for
addition is well-defined in the actual instructions.

Given that at least GCC's constant folding has unexpected results, we will have
to find a workaround. I had previously worried that a floating-point min(input,
(2^63)-1) is not exact. But comparing the float >= 2^63 and if so returning
(2^63)-1 would work, right? The CPU will anyway truncate the float to int.

Our current fixup code:

// For ConvertTo float->int of same size, clamping before conversion would
// change the result because the max integer value is not exactly
representable.
// Instead detect the overflow result after conversion and fix it.
// Generic for all vector lengths.
template 
HWY_INLINE VFromD FixConversionOverflow(DI di,
VFromD> original,
VFromD converted) {
  // Combinations of original and output sign:
  //   --: normal <0 or -huge_val to 80..00: OK
  //   -+: -0 to 0 : OK
  //   +-: +huge_val to 80..00 : xor with FF..FF to get 7F..FF
  //   ++: normal >0   : OK
  const VFromD sign_wrong = AndNot(BitCast(di, original), converted);
#if HWY_COMPILER_GCC_ACTUAL
  // Critical GCC 11 compiler bug (possibly also GCC 10): omits the Xor; also
  // Add() if using that instead. Work around with one more instruction.
  const RebindToUnsigned du;
  const VFromD mask = BroadcastSignBit(sign_wrong);
  const VFromD max = BitCast(di, ShiftRight<1>(BitCast(du, mask)));
  return IfVecThenElse(mask, max, converted);
#else
  return Xor(converted, BroadcastSignBit(sign_wrong));
#endif
}

[Bug middle-end/115131] New: [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

Bug ID: 115131
   Summary: [15 regression] ICE when building (external) rtl88x2bu
kernel module (in verify_range, at value-range.cc:677)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---

```
$ gcc -c rtw_recv.i -O1 -fno-strict-overflow
during GIMPLE pass: dom
rtw_recv.i: In function ‘_rtw_init_recv_priv’:
rtw_recv.i:5094:9: internal compiler error: in verify_range, at
value-range.cc:677
 5094 |sint _rtw_init_recv_priv(struct recv_priv *precvpriv, _adapter
*padapter) {  sint i;  union recv_frame *precvframe;  sint res = 1; 
_rtw_spinlock_init(&precvpriv->lock); 
_rtw_init_queue(&precvpriv->free_recv_queue); 
_rtw_init_queue(&precvpriv->recv_pending_queue); 
_rtw_init_queue(&precvpriv->uc_swdec_pending_queue);  precvpriv->adapter =
padapter;  precvpriv->free_recvframe_cnt = 256;  precvpriv->sink_udpport = 0; 
precvpriv->pre_rtp_rxseq = 0;  precvpriv->cur_rtp_rxseq = 0; 
precvpriv->store_law_data_flag = 0;  rtw_os_recv_resource_init(precvpriv,
padapter);  precvpriv->pallocated_frame_buf = _rtw_zvmalloc((256 * sizeof(union
recv_frame) + (1<<8)));  if (precvpriv->pallocated_frame_buf == ((void *)0)) { 
 res = 0;   goto exit;  }  precvpriv->precv_frame_buf = (u8 *)(((1<<8) == 1) ?
((SIZE_T)(precvpriv->pallocated_frame_buf)) :
SIZE_T)(precvpriv->pallocated_frame_buf) + (1<<8) - 1) / (1<<8)) *
(1<<8)));  precvframe = (union recv_frame *) precvpriv->precv_frame_buf;  for
(i = 0; i < 256 ; i++) {   _rtw_init_listhead(&(precvframe->u.list));  
rtw_list_insert_tail(&(precvframe->u.list),
&(precvpriv->free_recv_queue.queue));   rtw_os_recv_resource_alloc(padapter,
precvframe);   precvframe->u.hdr.len = 0;   precvframe->u.hdr.adapter =
padapter;   precvframe++;  }  ATOMIC_SET(&(precvpriv->rx_pending_cnt), 1); 
_rtw_init_sema(&precvpriv->allrxreturnevt, 0);  res =
rtw_hal_init_recv_priv(padapter); 
rtw_init_timer(&precvpriv->signal_stat_timer, padapter,
rtw_signal_stat_timer_hdl, padapter);  precvpriv->signal_stat_sampling_interval
= 2000;  _set_timer(&(precvpriv)->signal_stat_timer,
(precvpriv)->signal_stat_sampling_interval); exit:  return res; }
  | ^~~
0x55ede114ec9e prange::verify_range() const
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-range.cc:677
0x55ede114ec9e prange::verify_range() const
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-range.cc:663
0x55ede24c47e7 prange::intersect(vrange const&)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/value-range.cc:594
0x55ede1fb1bb5 operator_not_equal::fold_range(irange&, tree_node*, prange
const&, prange const&, relation_trio) const
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/range-op-ptr.cc:1244
0x55ede351d9eb fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-fold.cc:704
0x55ede351fcc0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-fold.cc:604
0x55ede22ee957 path_range_query::range_of_stmt(vrange&, gimple*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-path.cc:684
0x55ede239fc96 hybrid_jt_simplifier::simplify(gimple*, gimple*,
basic_block_def*, jt_state*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-threadedge.cc:1423
0x55ede239e8d7 jump_threader::simplify_control_stmt_condition(edge_def*,
gimple*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-threadedge.cc:385
0x55ede239f1aa
jump_threader::thread_through_normal_block(vec*, edge_def*, bitmap_head*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-threadedge.cc:951
0x55ede23a1450 jump_threader::thread_across_edge(edge_def*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-threadedge.cc:1080
0x55ede2241ba4 dom_opt_dom_walker::after_dom_children(basic_block_def*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-dom.cc:1791
0x55ede348eec4 dom_walker::walk(basic_block_def*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/domwalk.cc:354
0x55ede2247881 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-dom.cc:939
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/x86_64-pc-linux-gnu/1

[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c

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

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

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

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

commit r15-626-ga5b3721c06646bf5b9b50a22964e8e2bd4d03f5f
Author: Richard Biener 
Date:   Fri May 17 11:02:29 2024 +0200

middle-end/115110 - Fix view_converted_memref_p

view_converted_memref_p was checking the reference type against the
pointer type of the offset operand rather than its pointed-to type
which leads to all refs being subject to view-convert treatment
in get_alias_set causing numerous testsuite fails but with its
new uses from r15-512-g9b7cad5884f21c is also a wrong-code issue.

PR middle-end/115110
* tree-ssa-alias.cc (view_converted_memref_p): Fix.

[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

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

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

--- Comment #2 from Sam James  ---
I'm reducing it now, but attached a partial reduction.

[Bug fortran/104621] [OpenMP] Issues with 'declare variant'

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

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

--- Comment #1 from Tobias Burnus  ---
This got fixed for OpenMP 6 via OpenMP spec pull request #3383, adding:

* A declarative directive must be specified in the specification part after all
'USE', 'IMPORT' and 'IMPLICIT' statements.

* If a declarative directive applies to a function declaration or definition
  and it is specified with one or more C++ attribute specifiers, the
  specified attributes must be applied to the function as permitted by the
  base language.

Plus revising the wording for 'declare variant' for Fortran (semantic +
restrictions). See TR12/OpenMP 6.

[Bug tree-optimization/114998] [14 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/114998] [14 Regression] ICE on valid code at -O3 with "-fno-tree-dce" on x86_64-linux-gnu: Segmentation fault since r14-9767

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

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

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

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

commit r14-10214-g1e9ae50d4d160f6d557fc4cbbe95c4a36897c09f
Author: Richard Biener 
Date:   Fri May 10 14:19:49 2024 +0200

tree-optimization/114998 - use-after-free with loop distribution

When loop distribution releases a PHI node of the original IL it
can end up clobbering memory that's re-used when it upon releasing
its RDG resets all stmt UIDs back to -1, even those that got released.

The fix is to avoid resetting UIDs based on stmts in the RDG but
instead reset only those still present in the loop.

PR tree-optimization/114998
* tree-loop-distribution.cc (free_rdg): Take loop argument.
Reset UIDs of stmts still in the IL rather than all stmts
referenced from the RDG.
(loop_distribution::build_rdg): Pass loop to free_rdg.
(loop_distribution::distribute_loop): Likewise.
(loop_distribution::transform_reduction_loop): Likewise.

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

(cherry picked from commit 34d15a4d630a0d54eddb99bdab086c506e10dac5)

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

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

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

--- Comment #1 from Tobias Burnus  ---
Ups, testcase was lost. Re-written from scratch:
---
int var1() { return 1; }
int var2() { return 2; }

#pragma omp declare variant (var1) match(construct={target})
#pragma omp declare variant (var2) match(construct={parallel})
int foo() { return 42; }

#pragma omp declare variant (var2) match(construct={parallel})
#pragma omp declare variant (var2) match(construct={target})
int bar() { return 99; }

int main() {
  __builtin_printf("foo: %d (expected: 42)\n", foo());
  __builtin_printf("bar: %d (expected: 99)\n", bar());
  #pragma omp parallel if(0)
  {
__builtin_printf("foo: %d (expected: 2)\n", foo());
__builtin_printf("bar: %d (expected: 1)\n", bar());
  }
  #pragma omp target //device(-1 /*omp_initial_device*/)
  {
__builtin_printf("foo: %d (expected: 1)\n", foo());
__builtin_printf("bar: %d (expected: 2)\n", bar());
  }
}

[Bug tree-optimization/112793] [11/12 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)

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

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

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

https://gcc.gnu.org/g:9bad5cf9ae446b367f666176537eb76e94cc4448

commit r12-10452-g9bad5cf9ae446b367f666176537eb76e94cc4448
Author: Richard Biener 
Date:   Wed Dec 13 14:23:31 2023 +0100

tree-optimization/112793 - SLP of constant/external code-generated twice

The following makes the attempt at code-generating a constant/external
SLP node twice well-formed as that can happen when partitioning BB
vectorization attempts where we keep constants/externals unpartitioned.

PR tree-optimization/112793
* tree-vect-slp.cc (vect_schedule_slp_node): Already
code-generated constant/external nodes are OK.

* g++.dg/vect/pr112793.cc: New testcase.

(cherry picked from commit d782ec8362eadc3169286eb1e39c631effd02323)

[Bug tree-optimization/112281] [12 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

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

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

commit r12-10456-g5db4b5449df8f59a61438f8db1836dbc9b53f02e
Author: Richard Biener 
Date:   Mon Nov 20 13:39:52 2023 +0100

tree-optimization/112281 - loop distribution and zero dependence distances

The following fixes an omission in dependence testing for loop
distribution.  When the overall dependence distance is not zero but
the dependence direction in the innermost common loop is = there is
a conflict between the partitions and we have to merge them.

PR tree-optimization/112281
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For = in the
innermost common loop record a partition conflict.

* gcc.dg/torture/pr112281-1.c: New testcase.
* gcc.dg/torture/pr112281-2.c: Likewise.

(cherry picked from commit 3b34902417259031823bff7f853f615a60464bbd)

[Bug tree-optimization/111039] [11/12 Regression] Unable to coalesce ssa_names

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

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

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

https://gcc.gnu.org/g:47e6bff94d980e2fcb6bcb42df04d3b73bd67da7

commit r12-10457-g47e6bff94d980e2fcb6bcb42df04d3b73bd67da7
Author: Richard Biener 
Date:   Thu Aug 17 13:10:14 2023 +0200

tree-optimization/111039 - abnormals and bit test merging

The following guards the bit test merging code in if-combine against
the appearance of SSA names used in abnormal PHIs.

PR tree-optimization/111039
* tree-ssa-ifcombine.cc (ifcombine_ifandif): Check for
SSA_NAME_OCCURS_IN_ABNORMAL_PHI.

* gcc.dg/pr111039.c: New testcase.

(cherry picked from commit 482551a79a3d3f107f6239679ee74655cfe8707e)

[Bug debug/112718] [11/12 Regression] ICE: in add_dwarf_attr, at dwarf2out.cc:4501 with -g -fdebug-types-section -flto -ffat-lto-objects

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

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

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

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

commit r12-10453-g1f41e8eef3da1d76c18fe1a93846054c53dc5a47
Author: Richard Biener 
Date:   Mon Jan 22 15:42:59 2024 +0100

debug/112718 - reset all type units with -ffat-lto-objects

When mixing -flto, -ffat-lto-objects and -fdebug-type-section we
fail to reset all type units after early output resulting in an
ICE when attempting to add then duplicate sibling attributes.

PR debug/112718
* dwarf2out.cc (dwarf2out_finish): Reset all type units
for the fat part of an LTO compile.

* gcc.dg/debug/pr112718.c: New testcase.

(cherry picked from commit 7218f5050cb7163edae331f54ca163248ab48bfa)

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r15-627-gbc6e336cb7c85094ddc77757be97c3d8588f35ca
Author: Aldy Hernandez 
Date:   Fri May 17 10:30:03 2024 +0200

[prange] Avoid looking at type() for undefined ranges

Undefined ranges have no type.  This patch fixes the thinko.

gcc/ChangeLog:

PR middle-end/115128
* ipa-cp.cc (ipa_value_range_from_jfunc): Check for undefined_p
before looking at type.
(propagate_vr_across_jump_function): Same.

gcc/testsuite/ChangeLog:

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

[Bug tree-optimization/110176] [11/12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r11-2446

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

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

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

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

commit r12-10458-g65e5547e5468ce404d0f9ebd646a1d63abf3a772
Author: Richard Biener 
Date:   Wed Jan 31 14:40:24 2024 +0100

middle-end/110176 - wrong zext (bool) <= (int) 4294967295u folding

The following fixes a wrong pattern that didn't match the behavior
of the original fold_widened_comparison in that get_unwidened
returned a constant always in the wider type.  But here we're
using (int) 4294967295u without the conversion applied.  Fixed
by doing as earlier in the pattern - matching constants only
if the conversion was actually applied.

PR middle-end/110176
* match.pd (zext (bool) <= (int) 4294967295u): Make sure
to match INTEGER_CST only without outstanding conversion.

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

(cherry picked from commit 22dbfbe8767ff4c1d93e39f68ec7c2d5b1358beb)

[Bug tree-optimization/112281] [12 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/112505] [11/12 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104 since r10-4076

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

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

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

https://gcc.gnu.org/g:4a71557fbebe3fb4031d1c2adc4f89c89a8c6c62

commit r12-10454-g4a71557fbebe3fb4031d1c2adc4f89c89a8c6c62
Author: Richard Biener 
Date:   Thu Jan 11 14:00:33 2024 +0100

tree-optimization/112505 - bit-precision induction vectorization

Vectorization of bit-precision inductions isn't implemented but we
don't check this, instead we ICE during transform.

PR tree-optimization/112505
* tree-vect-loop.cc (vectorizable_induction): Reject
bit-precision induction.

* gcc.dg/vect/pr112505.c: New testcase.

(cherry picked from commit ec345df53556ec581590347f71c3d9ff3cdbca76)

[Bug tree-optimization/112495] [11/12 Regression] ICE: verify_gimple failed (after vectorizer) with named address space (__seg_gs )

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

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

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

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

commit r12-10455-gdbb5273996259b04350a1e3d35e633c51fc9310f
Author: Richard Biener 
Date:   Mon Nov 13 10:20:37 2023 +0100

tree-optimization/112495 - alias versioning and address spaces

We are not correctly handling differing address spaces in dependence
analysis runtime alias check generation so refuse to do that.

PR tree-optimization/112495
* tree-data-ref.cc (runtime_alias_check_p): Reject checks
between different address spaces.

* gcc.target/i386/pr112495.c: New testcase.

(cherry picked from commit 0f593c0521caab8cfac53514b1a5e7d0d0dd1932)

[Bug middle-end/115128] [15 regression] ICE when building aflplusplus (internal compiler error: in type, at value-range.h:983)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
Fixed

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
   Last reconfirmed||2024-05-17
 Ever confirmed|0   |1

--- Comment #3 from Aldy Hernandez  ---
Mine.

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

--- Comment #4 from Sam James  ---
Reduced:
```
struct recv_frame_hdr {
  int *adapter
};
union recv_frame {
  struct recv_frame_hdr u
};
char *_rtw_init_recv_priv_precvpriv_0;
int _rtw_init_recv_priv_padapter, _rtw_init_recv_priv_i;
void _rtw_init_recv_priv() {
  union recv_frame *precvframe;
  _rtw_init_recv_priv_precvpriv_0 = (char *)(0 / 0 << 8);
  precvframe = (union recv_frame *)_rtw_init_recv_priv_precvpriv_0;
  _rtw_init_recv_priv_i = 0;
  for (; _rtw_init_recv_priv_i < 6; _rtw_init_recv_priv_i++) {
precvframe->u.adapter = &_rtw_init_recv_priv_padapter;
precvframe++;
  }
}
```

But it has UB with the division by zero.

[Bug middle-end/115132] New: Sibling calls optim should not be performed when builtin_unwind_init is used

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

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

Bug ID: 115132
   Summary: Sibling calls optim should not be performed when
builtin_unwind_init is used
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrl at gcc dot gnu.org
  Target Milestone: ---

Hi all,

In GNU Emacs we use (in order to have all callee saved registers pushed on the
stack before entering in the garbage collector)  '__builtin_unwind_init'.

If sibling calls optimization is performed the call to gc is moved after the
register are popped again making '__builtin_unwind_init' ineffective.

test.c==

void gc ();

void foo (void)
{
  __builtin_unwind_init ();
  gc ();
}
===

Expected result:

gcc -fno-optimize-sibling-calls -O2 test.c

===
foo:
pushrbp
xor eax, eax
mov rbp, rsp
pushr15
pushr14
pushr13
pushr12
pushrbx
sub rsp, 8
callgc
add rsp, 8
pop rbx
pop r12
pop r13
pop r14
pop r15
pop rbp
ret


gcc -02 test.c


foo:
pushrbp
xor eax, eax
mov rbp, rsp
pushr15
pushr14
pushr13
pushr12
pushrbx
pop rbx
pop r12
pop r13
pop r14
pop r15
pop rbp
jmp gc


I understand '__builtin_unwind_init' it's undocumented and this can be
categorized as a non-bug but AFAIU this optimization makes
'__builtin_unwind_init' unusable for its scope.

Another very possible scenario is that I don't understand correctly how
'__builtin_unwind_init' is supposed to be used.

I see this on trunk but this behavior is present since at least GCC13.

Note: Original Emacs bug 

Thanks!

  Andrea

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

--- Comment #5 from Aldy Hernandez  ---
Created attachment 58224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58224&action=edit
patch in testing

[Bug ada/115133] New: [15 regression] s-oslock__solaris.ads doesn't compile

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

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

Bug ID: 115133
   Summary: [15 regression] s-oslock__solaris.ads doesn't compile
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

The new gcc/ada/libgnat/s-oslock__solaris.ads from

commit c8e5d90c4a0b736c2c4c5be3e8a3e9744e602d9d
Author: Eric Botcazou 
Date:   Tue Mar 5 23:30:51 2024 +0100

ada: Replace spinlocks with fully-fledged locks in finalization collections

breaks Solaris Ada bootstrap:

s-oslock.ads:50:10: error: "Ada" is not visible
s-oslock.ads:50:10: error: non-visible declaration at ada.ads:16

This snippet got me further along:

diff --git a/gcc/ada/libgnat/s-oslock__solaris.ads
b/gcc/ada/libgnat/s-oslock__solaris.ads
--- a/gcc/ada/libgnat/s-oslock__solaris.ads
+++ b/gcc/ada/libgnat/s-oslock__solaris.ads
@@ -32,6 +32,7 @@
 --  This is a Solaris (native) version of this package

 with Interfaces.C;
+with Ada.Unchecked_Conversion;

 package System.OS_Locks is
pragma Preelaborate;
@@ -65,10 +66,10 @@ package System.OS_Locks is

 private

-   type array_type_9 is array (0 .. 3) of unsigned_char;
+   type array_type_9 is array (0 .. 3) of Interfaces.C.unsigned_char;
type record_type_3 is record
   flag  : array_type_9;
-  Xtype : unsigned_long;
+  Xtype : Interfaces.C.unsigned_long;
end record;
pragma Convention (C, record_type_3);


but it may not be enough:

a-stbufi.ads:71:04: error: run-time library configuration error
a-stbufi.ads:71:04: error: file s-taskin.ads had semantic errors
a-stbufi.ads:71:04: error: entity "System.Tasking.Activation_Chain_Access" not
available
s-osinte.ads:301:29: error: "OS_Lock" not declared in "System"
s-osinte.ads:301:30: error: possible misspelling of "OS_Locks"
compilation abandoned
make[6]: *** [../gcc-interface/Makefile:306: a-stbufi.o] Error 1

This patch fixes the typo:

diff --git a/gcc/ada/libgnarl/s-osinte__solaris.ads
b/gcc/ada/libgnarl/s-osinte__solaris.ads
--- a/gcc/ada/libgnarl/s-osinte__solaris.ads
+++ b/gcc/ada/libgnarl/s-osinte__solaris.ads
@@ -298,7 +298,7 @@ package System.OS_Interface is

function To_thread_t is new Ada.Unchecked_Conversion (Integer, thread_t);

-   subtype mutex_t is System.OS_Lock.mutex_t;
+   subtype mutex_t is System.OS_Locks.mutex_t;

type cond_t is limited private;

until one runs into

s-oslock.ads:83:03: (style) bad indentation [-gnaty0]
make[6]: *** [../gcc-interface/Makefile:306: a-undesu.o] Error 1

No idea what's wrong here, though.

[Bug libstdc++/115099] compilation error: format thread::id

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-17
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |14.2
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug middle-end/115132] Sibling calls optim should not be performed when builtin_unwind_init is used

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

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

--- Comment #1 from Richard Biener  ---
You can do the following as workaround:

void __attribute__((optimize("no-optimize-sibling-calls"))) foo (void)
{
  __builtin_unwind_init ();
  gc ();
}

[Bug c/105863] RFE: C23 #embed

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

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

--- Comment #10 from Jakub Jelinek  ---
I think we should add a new tree next to STRING_CST for use inside of
CONSTRUCTORs.
STRING_CST in theory could be used e.g. inside of a constructor_elt, with say
RANGE_EXPR for the index and STRING_CST for the element.  But the problem is
that the
STRING_CST owns the whole string.  If somebody does:
const char arr[] = { 1, 2, 3, 42,
#embed "large_data.bin"
0, [10] = 15, [20] = 32 };
it would be nice if we could start with say that STRING_CST covering all of
50MB or how much of data, but then the designated initializer overrides mean
either that we need to expand it all to the huge number of INTEGER_CSTs, or if
we had some tree that can extract some substring from larger STRING_CST use
that (3 operands, the STRING_CST and offset from start and length), we could
just create two such small trees and build one INTEGER_CST in between.
Because if we just have STRING_CST, we'd need to create 2 new huge STRING_CSTs
when splitting something into halves.
SUBSTRING_CST?

For what to do with -E, if the amount of data is really small (dunno, 64 or 128
bytes or user parameter?), we should expand it in the preprocessed source as
integer tokens with commas in between, so
 124,231,0,15,24,86
but for larger I'd go with what I've proposed in the LLVM pull request, i.e.
emit in
the preprocessed source
#embed "."
__gnu__::__base64__("TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVlciBhZGlwaXNjaW5nIGVsaXQuIE5hbSBzZWQgdGVsbHVzIGlkIG1hZ25hIGVsZW1lbnR1bSB0aW5jaWR1bnQuIEFsaXF1YW0gaWQgZG9sb3IuIFV0IHRlbXB1cyBwdXJ1cyBhdCBsb3JlbS4uLgo=")
or so, where the embed data would be base64 decoded from the string instead of
read from some other file.
Because
#embed_base64
or what has been proposed there would be something to diagnose with
-pedantic-errors as invalid,
while I think recognized #embed implementation-defined parameters aren't
strictly invalid (while unrecognized are).

[Bug middle-end/115132] Sibling calls optim should not be performed when builtin_unwind_init is used

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

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

--- Comment #2 from akrl at gcc dot gnu.org ---
Hi Richard,

thanks, yes I tried that already, the trouble is that our code looks more like
this:

=
extern void flush_stack_call_func1 (void (*func) (void *arg), void *arg);
extern void mark_threads (void);
extern void
mark_threads_callback (void *ignore);

static inline void
flush_stack_call_func (void (*func) (void *arg), void *arg)
{
  __builtin_unwind_init ();
  flush_stack_call_func1 (func, arg);
}

void
mark_threads (void)
{
  flush_stack_call_func (mark_threads_callback, ((void *)0));
}

[...]
=

Because we have several places where 'flush_stack_call_func' is used.

Unfortunately as 'flush_stack_call_func' gets inlined the trick does not work.

I'm not ecstatic at making 'flush_stack_call_func' not inlinable nor at marking
all the functions where it is called with the attribute, but we'll have to find
a way anyway I guess.

Thanks

  Andrea

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

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

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> until one runs into
>
> s-oslock.ads:83:03: (style) bad indentation [-gnaty0]
> make[6]: *** [../gcc-interface/Makefile:306: a-undesu.o] Error 1
>
> No idea what's wrong here, though.

There's a 2-space indentation instead of the expected 3 spaces.  I had
to look several times to see it, though.  Maybe the error could be
clearer?

After that, I run into

s-taprop.adb:1402:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr"
s-taprop.adb:1402:20: error: found type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1443:57: error: expected type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1443:57: error: found type "System.Os_Locks.RTS_Lock_Ptr"
s-taprop.adb:1471:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr"
s-taprop.adb:1471:20: error: found type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1552:57: error: expected type "System.Task_Primitives.Lock_Ptr"
s-taprop.adb:1552:57: error: found type "System.Os_Locks.RTS_Lock_Ptr"
make[6]: *** [../gcc-interface/Makefile:306: s-taprop.o] Error 1

but am stuck.

[Bug c++/114480] [12/13/14/15 Regression] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

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

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

--- Comment #32 from GCC Commits  ---
The master branch has been updated by Alexander Monakov :

https://gcc.gnu.org/g:4b9e68a6f3b22800a7f12b58ef6b25e3b339bb3c

commit r15-628-g4b9e68a6f3b22800a7f12b58ef6b25e3b339bb3c
Author: Alexander Monakov 
Date:   Wed May 15 16:23:17 2024 +0300

tree-into-ssa: speed up sorting in prune_unused_phi_nodes [PR114480]

In PR 114480 we are hitting a case where tree-into-ssa scales
quadratically due to prune_unused_phi_nodes doing O(N log N)
work for N basic blocks, for each variable individually.
Sorting the 'defs' array is especially costly.

It is possible to assist gcc_qsort by laying out dfs_out entries
in the reverse order in the 'defs' array, starting from its tail.
This is not always a win (in fact it flips most of 7-element qsorts
in this testcase from 9 comparisons (best case) to 15 (worst case)),
but overall it helps on the testcase and on libstdc++ build.
On the testcase we go from 1.28e9 comparator invocations to 1.05e9,
on libstdc++ from 2.91e6 to 2.84e6.

gcc/ChangeLog:

PR c++/114480
* tree-into-ssa.cc (prune_unused_phi_nodes): Add dfs_out entries
to the 'defs' array in the reverse order.

[Bug libstdc++/115134] New: Possible typo in _Grapheme_cluster_iterator iterator

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

Bug ID: 115134
   Summary: Possible typo in  _Grapheme_cluster_iterator iterator
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

I believe there's a missing dereference here:
https://github.com/gcc-mirror/gcc/blob/bc6e336cb7c85094ddc77757be97c3d8588f35ca/libstdc%2B%2B-v3/include/bits/unicode.h#L805

i.e.:

constexpr _Iterator
operator++(int)
{
  auto __tmp = *this;
  ++*this; // here
  return __tmp;
}

[Bug libstdc++/115134] Possible typo in _Grapheme_cluster_iterator iterator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Already reported twice in the past 24 hours

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

[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #6 from Jonathan Wakely  ---
*** Bug 115134 has been marked as a duplicate of this bug. ***

[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)

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

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

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

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

commit r15-629-gc9e05b03c18e898be604ab90401476e9c473cc52
Author: Jonathan Wakely 
Date:   Thu May 16 17:15:55 2024 +0100

libstdc++: Fix typo in _Grapheme_cluster_view::_Iterator [PR115119]

libstdc++-v3/ChangeLog:

PR libstdc++/115119
* include/bits/unicode.h (_Iterator::operator++(int)): Fix typo
in increment expression.
* testsuite/ext/unicode/grapheme_view.cc: Check post-increment
on view's iterator.

[Bug target/115135] New: [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com via Gcc-bugs]

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

Bug ID: 115135
   Summary: [C++] GCC produces wrong code at certain inlining
levels on Aarch64 with -fno-exceptions, related to
lambdas and variants
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clopez at igalia dot com
  Target Milestone: ---

Created attachment 58225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58225&action=edit
Simplified test case to reproduce the issue on Aarch64. The program should
print OK at the end. Check the comments at the top on how to build it.

This issue has been detected on the WebKit project. The builds of some CI bots
of WPEWebKit for Aarch64 started to crash heavily recently.
We are currently using GCC-12, but the issue happens also with newer GCC
versions. I tested and I can reproduce the issue with GCC-13 and GCC-14.

The original bug report is here: https://bugs.webkit.org/show_bug.cgi?id=273703
and further discussion is at: https://github.com/WebKit/WebKit/pull/28117

After quite a bit of effort I managed to create a simplified test case of only
a hundred lines. I'm attaching the test-case here.

If you build the test case and everything goes as expected you should see this:

intel-64:~# g++ -O3 -fno-exceptions test.cpp && ./a.out
[DEBUG] aPtr at 0x7ffd042c5080 points to 0x55e26078eec0 which has value 10 [At
initTest()]
[DEBUG] bObj at 0x7ffd042c5078 has value 11 [At initTest()]
[DEBUG] aPtr at 0x7ffd042c5090 points to 0x55e26078eec0 which has value 10 [At
doTest():aTest]
[DEBUG] bObj at 0x7ffd042c507c has value 11 [At doTest():aTest]
[DEBUG] mObj at 0x7ffd042c50cc [At doTest():aTest]
[DEBUG] mObj at 0x7ffd042c50cc has value 33 [At main()]

[OK] Everything went as expected. Program compiled correctly :)

So the program checks itself that everything was calculated as expected. It
reports OK if everything works as it should. Which is for example, what you see
if you build the program on x86_64

However, if you try this on Aarch64 you see something like this:

raspberrypi4-64:~# g++ -O3 -fno-exceptions test.cpp && ./a.out
[DEBUG] aPtr at 0x7fec013cb0 points to 0x55cf43cec0 which has value 10 [At
initTest()]
[DEBUG] bObj at 0x7fec013ca0 has value 11 [At initTest()]
[DEBUG] aPtr at 0x7fec013cc0 points to 0x5590b2fd20 which has value -1867445184
[At doTest():aTest]
[DEBUG] bObj at 0x7fec013ca8 has value -2006561636 [At doTest():aTest]
[DEBUG] mObj at 0x7fec013cf8 [At doTest():aTest]
[DEBUG] mObj at 0x7fec013cf8 has value 420960488 [At main()]

[ERROR] Something went wrong compiling the program!:  mObj.m_data should be 33
but is 420960488

The program ends with error, because the last two function parameters that the
doTest() function receives (aPtr and bObj) are messed up when passed into the
lambda.
It seems to me that is like the compiler somehow misses the initialization of
those function parameters (pass-by-value in this case) when the doTest()
function is called if those parameters are not used on the main body of the
function, but only inside the lambda.

What is even more amazing, is that if you comment out the third printfs() that
print the address of mObj inside the lambda then the program works correctly.

In other words, basically apply this patch to the program:

--- a/test.cpp  2024-05-17 12:12:50.561903072 +
+++ b/test.cpp  2024-05-17 12:32:45.957454704 +
@@ -81,13 +81,11 @@
 [&](std::unique_ptr& ptr_a) -> int {
 printf("[DEBUG] aPtr at %p points to %p which has value %d [At
doTest():aTest]\n", &aPtr, aPtr.get(), aPtr->m_data);
 printf("[DEBUG] bObj at %p has value %d [At doTest():aTest]\n",
&bObj, bObj.m_data);
-printf("[DEBUG] mObj at %p [At doTest():aTest]\n", &mObj);
 return aPtr->m_data + ptr_a->m_data + bObj.m_data;
 },
 [&](std::unique_ptr& ptr_b) -> int {
 printf("[DEBUG] aPtr at %p points to %p which has value %d [At
doTest():bTest]\n", &aPtr, aPtr.get(), aPtr->m_data);
 printf("[DEBUG] bObj at %p has value %d [At doTest():bTest]\n",
&bObj, bObj.m_data);
-printf("[DEBUG] mObj at %p [At doTest():bTest]\n", &mObj);
 return aPtr->m_data + ptr_b->m_data + bObj.m_data;
 });
 }


And then it works.. why? It makes zero sense to me.
Note that mObj is not used on the calculation returned, so it shouldn't even
need to be captured into the lambda for the program to work.

Inside the test code example there are some comments at the top about different
switches on how to compile it to reproduce the error.

The issue is only reproducible on Aarch64.
And I reproduced with gcc-12, gcc-13 and gcc-14 both on a Debian system as well
on a Yocto/OpenEmbedded based system. Both on Aarch64.

Note: To the best of my understanding there is no u

[Bug c++/115114] aggregate initialization with parens fails when there is a base class

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-630-g5aaf47cb1987bbc5508c4b9b7dad5ea7d69af2c2
Author: Patrick Palka 
Date:   Fri May 17 09:02:52 2024 -0400

c++: aggregate CTAD w/ paren init and bases [PR115114]

During aggregate CTAD with paren init, we're accidentally overlooking
base classes since TYPE_FIELDS of a template type doesn't contain
corresponding base fields.  So we need to consider them separately.

PR c++/115114

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Consider bases in the paren init case.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr15.C: New test.

Reviewed-by: Jason Merrill 

[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)

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

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

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

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

commit r14-10215-ge909d360dfaeafa9f45eda2461a1bedffac99ac2
Author: Jonathan Wakely 
Date:   Thu May 16 17:15:55 2024 +0100

libstdc++: Fix typo in _Grapheme_cluster_view::_Iterator [PR115119]

libstdc++-v3/ChangeLog:

PR libstdc++/115119
* include/bits/unicode.h (_Iterator::operator++(int)): Fix typo
in increment expression.
* testsuite/ext/unicode/grapheme_view.cc: Check post-increment
on view's iterator.

(cherry picked from commit c9e05b03c18e898be604ab90401476e9c473cc52)

[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 14.2, thanks for the report (and to the dup reporters).

[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

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

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

--- Comment #1 from Andrew Pinski  ---
Does either -fno-ivopts or -fno-ipa-modref help?

[Bug other/115136] New: [15 regression] experimental/functional/searchers.cc fails after

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

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

Bug ID: 115136
   Summary: [15 regression] experimental/functional/searchers.cc
fails after
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f3e5f4c58591f5dacdd14a65ec47bbe310df02a0, r15-580-gf3e5f4c58591f5
make  -k check
RUNTESTFLAGS="conformance.exp=experimental/functional/searchers.cc"
FAIL: experimental/functional/searchers.cc  -std=gnu++17 execution test


/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/experimental/functional/searchers.cc:123:
void test03(): Assertion 'bm_res == res' failed.
FAIL: experimental/functional/searchers.cc  -std=gnu++17 execution test


commit f3e5f4c58591f5dacdd14a65ec47bbe310df02a0 (HEAD)
Author: Richard Biener 
Date:   Mon Mar 11 11:17:32 2024 +0100

tree-optimization/13962 - handle ptr-ptr compares in ptrs_compare_unequal

[Bug middle-end/115137] New: [15 regression] Miscompilation of wget (test suite hangs)

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

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

Bug ID: 115137
   Summary: [15 regression] Miscompilation of wget (test suite
hangs)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58226&action=edit
url.c

I noticed that wget's testsuite was hanging today in `unit-tests`.

```
(gdb) bt
#0  0x9319 in append_uri_pathel (e=e@entry=0xa09d "",
escaped=escaped@entry=false, dest=dest@entry=0x7fffd780, b=0xa090
"somepage.html")
at ../src/url.c:1509
#1  0x63e0 in test_append_uri_pathel () at ../src/url.c:2492
#2  all_tests () at /home/sam/git/wget/tests/unit-tests.c:47
#3  main (argc=, argv=) at
/home/sam/git/wget/tests/unit-tests.c:70
```

I'm still reducing it but it hangs with gcc-15 -O2.

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

[Bug middle-end/115137] [15 regression] Miscompilation of wget (test suite hangs)

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

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

--- Comment #1 from Sam James  ---
Notable bits:
* -fno-strict-aliasing makes no difference
* -fno-strict-overflow stops the hang
* -fsanitize=address,undefined shows nothing with < GCC 15
* With GCC 15 only, I get

```
$ ./z
url.c:1575:41: runtime error: load of address 0x557b31e7c12e with insufficient
space for an object of type 'const char'
0x557b31e7c12e: note: pointer points here
 74 6d 6c 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00
00 00 00 00 00  00 00
 ^ 
#0 0x557b31e7b681 in append_uri_pathel /home/sam/git/wget/backup/url.c:1575
#1 0x557b31e7b94b in test_append_uri_pathel
/home/sam/git/wget/backup/url.c:1667
#2 0x557b31e7a3a8 in main /home/sam/git/wget/backup/url.c:1679
#3 0x7f251342df49  (/usr/lib64/libc.so.6+0x25f49)
#4 0x7f251342e004 in __libc_start_main (/usr/lib64/libc.so.6+0x26004)
#5 0x557b31e7a400 in _start (/home/sam/git/wget/backup/z+0x4400)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior url.c:1575:41 in 
Aborted (core dumped)
```

But only when building with `-O2 -fsanitize=address,undefined`. -O3 with
ASAN+UBSAN is fine.

[Bug middle-end/115137] [15 regression] Miscompilation of wget (test suite hangs)

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

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

--- Comment #2 from Sam James  ---
I have a reduction still running but I didn't do much manual analysis other
than doing enough to remove its dependency on other files + remove the need for
LTO (which was originally required).

I haven't yet bisected either.

[Bug other/115136] [15 regression] experimental/functional/searchers.cc fails after

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

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

--- Comment #1 from Andrew Pinski  ---
This should have been fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b420e0b920613c42f63252aa2478a8315dc37a13

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r15-632-g1accf4454a2ab57c4d681d1f6db332c46c61c058
Author: Aldy Hernandez 
Date:   Fri May 17 13:44:08 2024 +0200

[prange] Drop range to VARYING if the bitmask intersection made it so
[PR115131]

If the intersection of the bitmasks made the range span the entire
domain, normalize the range to VARYING.

gcc/ChangeLog:

PR middle-end/115131
* value-range.cc (prange::intersect): Set VARYING if intersection
of bitmasks made the range span the entire domain.
(range_tests_misc): New test.

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
Fixed

[Bug middle-end/115131] [15 regression] ICE when building (external) rtl88x2bu kernel module (in verify_range, at value-range.cc:677)

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

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

--- Comment #8 from Sam James  ---
thank you aldy

[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring

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

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

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

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

commit r15-633-g5f5074fe7aaf9524defb265299a985eecba7f914
Author: Paul Thomas 
Date:   Fri May 17 15:19:26 2024 +0100

Fortran: Fix select type regression due to r14-9489 [PR114874]

2024-05-17  Paul Thomas  

gcc/fortran
PR fortran/114874
* gfortran.h: Add 'assoc_name_inferred' to gfc_namespace.
* match.cc (gfc_match_select_type): Set 'assoc_name_inferred'
in select type namespace if the selector has inferred type.
* primary.cc (gfc_match_varspec): If a select type temporary
is apparently scalar and a left parenthesis has been detected,
check the current namespace has 'assoc_name_inferred' set. If
so, set inferred_type.
* resolve.cc (resolve_variable): If the namespace of a select
type temporary is marked with 'assoc_name_inferred' call
gfc_fixup_inferred_type_refs to ensure references are OK.
(gfc_fixup_inferred_type_refs): Catch invalid array refs..

gcc/testsuite/
PR fortran/114874
* gfortran.dg/pr114874_1.f90: New test for valid code.
* gfortran.dg/pr114874_2.f90: New test for invalid code.

[Bug tree-optimization/115138] New: [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

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

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

Bug ID: 115138
   Summary: [15 Regression] Bootstrap compare-debug fail after
r15-580-gf3e5f4c58591f5
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-darwin

The compare fail is a symbol name mismatch (AFAICT) the code is otherwise
identical.

a single fail fails gcc/d/opover.o

There's:

.const
_CSWTCH.155:
.byte   38
.byte   37
.byte   40
.byte   39

where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154

At present, still trying to figure out how to debug this further .. it's D so
no preprocessed output - I guess will have to try tree dumps.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |15.0
Version|14.0|15.0
   Last reconfirmed||2024-05-17

--- Comment #1 from Iain Sandoe  ---
seen on several OS versions.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #2 from rguenther at suse dot de  ---
> Am 17.05.2024 um 16:20 schrieb iains at gcc dot gnu.org 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138
> 
>Bug ID: 115138
>   Summary: [15 Regression] Bootstrap compare-debug fail after
>r15-580-gf3e5f4c58591f5
>   Product: gcc
>   Version: 14.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: tree-optimization
>  Assignee: unassigned at gcc dot gnu.org
>  Reporter: iains at gcc dot gnu.org
>CC: rguenth at gcc dot gnu.org
>  Target Milestone: ---
>Target: x86_64-darwin
> 
> The compare fail is a symbol name mismatch (AFAICT) the code is otherwise
> identical.
> 
> a single fail fails gcc/d/opover.o
> 
> There's:
> 
>.const
> _CSWTCH.155:
>.byte   38
>.byte   37
>.byte   40
>.byte   39
> 
> where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154
> 
> At present, still trying to figure out how to debug this further .. it's D so
> no preprocessed output - I guess will have to try tree dumps.

Did the followup fix maybe resolve this?

> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Paul Thomas :

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

commit r14-10216-gc887341432bb71cf5540d54955ad7265b0aaca77
Author: Paul Thomas 
Date:   Fri May 17 15:19:26 2024 +0100

Fortran: Fix select type regression due to r14-9489 [PR114874]

2024-05-17  Paul Thomas  

gcc/fortran
PR fortran/114874
* gfortran.h: Add 'assoc_name_inferred' to gfc_namespace.
* match.cc (gfc_match_select_type): Set 'assoc_name_inferred'
in select type namespace if the selector has inferred type.
* primary.cc (gfc_match_varspec): If a select type temporary
is apparently scalar and a left parenthesis has been detected,
check the current namespace has 'assoc_name_inferred' set. If
so, set inferred_type.
* resolve.cc (resolve_variable): If the namespace of a select
type temporary is marked with 'assoc_name_inferred' call
gfc_fixup_inferred_type_refs to ensure references are OK.
(gfc_fixup_inferred_type_refs): Catch invalid array refs..

gcc/testsuite/
PR fortran/114874
* gfortran.dg/pr114874_1.f90: New test for valid code.
* gfortran.dg/pr114874_2.f90: New test for invalid code.

(cherry picked from commit 5f5074fe7aaf9524defb265299a985eecba7f914)

[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #11 from Paul Thomas  ---
Hi Harald,

Your comments have been implemented and the patch committed to both affected
branches.

Thanks for the report and your help in honing up the fix.

Paul

[Bug c++/115139] New: Enum inside variadic template class can't define one of self with usage another value from this enum

[pavel at karpychev dot name via Gcc-bugs]

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

Bug ID: 115139
   Summary: Enum inside variadic template class can't define one
of self with usage another value from this enum
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at karpychev dot name
  Target Milestone: ---

Created attachment 58227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58227&action=edit
source, compile command, error, result of -freport-bug

[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64 and x86_64

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

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

Marc Poulhiès  changed:

   What|Removed |Added

 CC||dkm at gcc dot gnu.org

--- Comment #31 from Marc Poulhiès  ---
Hello Martin,

Any chance the fix that fixes the new test for 32bits can be also backported?

4923ed49b93352bcf9e43cafac38345e4a54c3f8
https://gcc.gnu.org/g:4923ed49b93352bcf9e43cafac38345e4a54c3f8

Not sure why it's not tagged so that it would appear here.

[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)

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

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

--- Comment #7 from Paul Thomas  ---
(In reply to Francois-Xavier Coudert from comment #6)
> So the var_decl in question is fpstate.0:
> 
>   type  type  size 
> unit-size 
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1035003f0 precision:8 min  max  0x1034bceb8 255>
> pointer_to_this >
> BLK
> size 
> unit-size 
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x1036c4b28
> domain 
> DI
> size 
> unit-size 
> align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x1036c4a80 precision:64 min  max
> >
> pointer_to_this >
> addressable used ignored BLK s.f90:10:17 size  264> unit-size 
> align:8 warn_if_not_align:0 context >
> 
> And if I look at the tree dump, it seems the variable is indeed not created
> correctly:
> 
> __attribute__((fn spec (". w ")))
> void my_sub (struct __class_my_mod_My_type_t & restrict obs)
> {
>   try
> {
>   _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
> 
> see the missing declaration for fpstate.0. But it is created by
> gfc_create_var(), like so many other local variables in the front-end, so I
> have no idea why it's disappearing.

Thanks for both the comments, Francois-Xavier. I will look to see if, somehow,
the way in which the finalization is stacked on the function tree is somehow
overwriting the ieee entry call and or the decl of fpstate.0.

Paul

[Bug middle-end/115132] Sibling calls optim should not be performed when builtin_unwind_init is used

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
Placing an empty asm is sufficient to prevent undesired tailcalls:

void gc ();

void foo (void)
{
  __builtin_unwind_init ();
  gc ();
  asm ("");
}

[Bug other/115136] [15 regression] experimental/functional/searchers.cc fails after

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Yup, looks like it is fixed with latest trunk I just tried.

[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-17
 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
Summary|Enum inside variadic|[14 Regression] Enum inside
   |template class can't define |variadic template class
   |one of self with usage  |can't define one of self
   |another value from this |with usage another value
   |enum|from this enum
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Confirmed, started with r14-4796-g3e3d73ed5e85e7.  Interestingly
r15-123-gf04dc89a991ddc made us accept this testcase on trunk, so this is a 14
regression only.

[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r15-634-gb59de4113262f2bee14147eb17eb3592f03d9556
Author: Uros Bizjak 
Date:   Fri May 17 09:55:49 2024 +0200

i386: Rename sat_plusminus expanders to standard names [PR112600]

Rename _3 expander to a standard ssadd,
usadd, sssub and ussub name to enable corresponding optab expansion.

Also add named expander for MMX modes.

PR middle-end/112600

gcc/ChangeLog:

* config/i386/mmx.md (3): New expander.
* config/i386/sse.md
(_3):
Rename expander to 3.
(3): Update for rename.
* config/i386/i386-builtin.def: Update for rename.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112600-1a.c: New test.
* gcc.target/i386/pr112600-1b.c: New test.

[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to rguent...@suse.de from comment #2)
> > Am 17.05.2024 um 16:20 schrieb iains at gcc dot gnu.org 
> > :
> > 

> > where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154
> > 
> > At present, still trying to figure out how to debug this further .. it's D 
> > so
> > no preprocessed output - I guess will have to try tree dumps.
> 
> Did the followup fix maybe resolve this?

unfortunately, not - the same behaviour is seen at r15-633 (so will have to see
what can be done to debug).

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Eric Botcazou  ---
> There's a 2-space indentation instead of the expected 3 spaces.  I had
> to look several times to see it, though.  Maybe the error could be
> clearer?

Style error messages are the hardest to get right, so I won't even try. ;-)

> After that, I run into
> 
> s-taprop.adb:1402:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr"
> s-taprop.adb:1402:20: error: found type "System.Task_Primitives.Lock_Ptr"
> s-taprop.adb:1443:57: error: expected type "System.Task_Primitives.Lock_Ptr"
> s-taprop.adb:1443:57: error: found type "System.Os_Locks.RTS_Lock_Ptr"
> s-taprop.adb:1471:20: error: expected type "System.Os_Locks.RTS_Lock_Ptr"
> s-taprop.adb:1471:20: error: found type "System.Task_Primitives.Lock_Ptr"
> s-taprop.adb:1552:57: error: expected type "System.Task_Primitives.Lock_Ptr"
> s-taprop.adb:1552:57: error: found type "System.Os_Locks.RTS_Lock_Ptr"
> make[6]: *** [../gcc-interface/Makefile:306: s-taprop.o] Error 1

Sorry about the mess, tentative fix to be attached.

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

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

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

--- Comment #3 from Eric Botcazou  ---
Created attachment 58228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58228&action=edit
Tentative fix

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

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

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #58228|0   |1
is obsolete||

--- Comment #4 from Eric Botcazou  ---
Created attachment 58229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58229&action=edit
Tentative fix

The complete version of it.

[Bug other/115140] New: [15 regression] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c excess errors after r15-579-ga9251ab3c91c8c

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

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

Bug ID: 115140
   Summary: [15 regression]
libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof
-kernels-1.c excess errors after
r15-579-ga9251ab3c91c8c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:a9251ab3c91c8c559d0306838575a666ae62dff4, r15-579-ga9251ab3c91c8c: 1130
failures

FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2   at line
190 (test for warnings, line 185)
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2   at line
221 (test for warnings, line 214)
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2   at line
252 (test for warnings, line 245)
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for
excess errors)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2   at line
190 (test for warnings, line 185)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2   at line
221 (test for warnings, line 214)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2   at line
252 (test for warnings, line 245)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for
excess errors)

commit a9251ab3c91c8c559d0306838575a666ae62dff4 (HEAD)
Author: Richard Biener 
Date:   Thu May 16 12:35:28 2024 +0200

wrong code with points-to and volatile



Excess errors:
/home/seurer/gcc/git/gcc-test2/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c:185:9:
optimized: assigned OpenACC seq loop parallelism
/home/seurer/gcc/git/gcc-test2/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c:214:9:
optimized: assigned OpenACC seq loop parallelism
/home/seurer/gcc/git/gcc-test2/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c:245:9:
optimized: assigned OpenACC seq loop parallelism

[Bug rtl-optimization/78664] LRA must honor REG_ALLOC_ORDER to pick reload registers

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

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

--- Comment #2 from Vladimir Makarov  ---
During register assignment subpass LRA processes hard regs from
ira_class_hard_regs.  Under the same conditions (e.g. costs), LRA chooses regs
processed first.

ira_class_hard_regs contains regs according REG_ALLOC_ORDER.

LRA has code for balanced use of hard regs (controlled by hook
register_usage_leveling_p).  But now by default it is switched off.  Probably
the issue occurred when the code was switched on. 

To be sure I tried the test case and I was not able to reproduce the problem.

So I think the problem has been solved.

[Bug middle-end/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants

[clopez at igalia dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Alberto Lopez Perez  ---
(In reply to Andrew Pinski from comment #1)
> Does either -fno-ivopts or -fno-ipa-modref help?

-fno-ivopts does not help

-fno-ipa-modref helps! passing this flag makes the compiled program is correct
:)

[Bug ada/115133] [15 regression] s-oslock__solaris.ads doesn't compile

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

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Eric Botcazou  ---
> Created attachment 58229
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58229&action=edit
> Tentative fix
>
> The complete version of it.

Thanks.  There's one issue left:

s-tasini.adb:248:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:248:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]
s-tasini.adb:260:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:260:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]
s-tasini.adb:272:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:272:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]
s-tasini.adb:284:11: warning: default initialization of "Lock" may modify
overlaid storage [-gnatwo]
s-tasini.adb:284:11: warning: use pragma Import for "Lock" to suppress
initialization (RM B.1(24)) [-gnatwo]

[Bug middle-end/115137] [15 regression] Miscompilation of wget (test suite hangs) since r15-580-gf3e5f4c58591f5

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Summary|[15 regression] |[15 regression]
   |Miscompilation of wget  |Miscompilation of wget
   |(test suite hangs)  |(test suite hangs) since
   ||r15-580-gf3e5f4c58591f5

--- Comment #3 from Sam James  ---
Bisect says r15-580-gf3e5f4c58591f5.

[Bug middle-end/115137] [15 regression] Miscompilation of wget (test suite hangs) since r15-580-gf3e5f4c58591f5

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

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

--- Comment #4 from Sam James  ---
(In reply to Sam James from comment #3)
> Bisect says r15-580-gf3e5f4c58591f5.

(Still fails on trunk as of r15-634-gb59de4113262f2.)

[Bug tree-optimization/115141] New: [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c

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

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

Bug ID: 115141
   Summary: [15 Regression] g++.dg/tree-ssa/pr83215.C and
gcc.dg/tree-ssa/ssa-lim-15.c since
r15-512-g9b7cad5884f21c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Since commit r15-512-g9b7cad5884f21c, g++.dg/tree-ssa/pr83215.C and
gcc.dg/tree-ssa/ssa-lim-15.c regresses for what appears to be all targets,
including cris-elf.

See e.g.
powerpc64-unknown-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815379.html
arm-unknown-eabi:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815354.html
x86_64-pc-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815358.html

Compare to recent results posted before this commit:
powerpc64-unknown-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815200.html
arm-unknown-eabi:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815264.html
x86_64-pc-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815205.html

[Bug tree-optimization/115141] [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c

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

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

--- Comment #1 from Sam James  ---
Dupe of PR115110?

[Bug rtl-optimization/78664] LRA must honor REG_ALLOC_ORDER to pick reload registers

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

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

--- Comment #3 from Eric Botcazou  ---
OK, thanks for the explanation.

[Bug tree-optimization/115141] [15 Regression] g++.dg/tree-ssa/pr83215.C and gcc.dg/tree-ssa/ssa-lim-15.c since r15-512-g9b7cad5884f21c

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #2 from Hans-Peter Nilsson  ---
(In reply to Sam James from comment #1)> Dupe of PR115110?

Yep, thanks. It was fixed already, and by default searches don't include fixed
issues, that's why my pre-pr-search didn't find it.