[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58443|0   |1
is obsolete||

--- Comment #11 from Andrew Pinski  ---
Created attachment 58444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58444=edit
Fails now without -m32

[Bug rtl-optimization/114515] [15 Regression] Failure to use aarch64 lane forms after PR101523

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #12 from Jeffrey A. Law  ---
Reading the RTL dumps from Richard S. this looks like the exact same problem
we're still seeing on the RISC-V port, affecting 557.xz.

Specifically we get the same I2 back, but I3 has changed.  The change in I3 in
turn allows I2 to combine into a different instruction and net is a clear
improvement.  ISTM that allowing this combination when we get the same I2 back,
but a different I3 would be sufficient to fix both the aarch64 and riscv
problems.

Unfortunately Segher has gone radio silent on this issue.

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58442|0   |1
is obsolete||

--- Comment #10 from Andrew Pinski  ---
Created attachment 58443
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58443=edit
A little more reduced

Slightly more reduced. Still trying to figure out the SLP thing here.

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #9 from Andrew Pinski  ---
  _19 = BIT_FIELD_REF ;
  _12 = BIT_FIELD_REF ;
  _15 = _12 | _19;

vs
  _13 = BIT_FIELD_REF ;
  _14 = BIT_FIELD_REF ;
  _15 = _13 | _14;

So basically it is just by accident the order happens that way which is why the
reducing it further removing the stuff afterwards does not make any difference
...

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 58442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58442=edit
Semi-cleaned up testcase with some extra hooks

So note if you change any of the `#if 0` to `#if 1` or `#if 1` to `#if 0` the
crash in SLP no longer happens.

Note also with the last one change, the only difference deals with the PERM
that is being selected in SLP:
Due to the order of `BIT_FIELD_REF ;` vs `BIT_FIELD_REF
;`. somehow.

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #6 from Sam James  ---
Created attachment 58441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58441=edit
reduced_more.i

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #5 from Sam James  ---
On trunk with reduced.i, I get:
```
==3698089== Invalid read of size 8
==3698089==at 0x2430014: UnknownInlinedFun (tree-vect-slp.cc:9672)
==3698089==by 0x2430014: vect_schedule_slp_node(vec_info*, _slp_tree*,
_slp_instance*) (tree-vect-slp.cc:9514)
==3698089==by 0x242F05C: vect_schedule_scc(vec_info*, _slp_tree*,
_slp_instance*, hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_in
fo> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&) (tree-vect-slp.cc:9965)
==3698089==by 0x242EFAC: vect_schedule_scc(vec_info*, _slp_tree*,
_slp_instance*, hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_in
fo> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&) (tree-vect-slp.cc:9946)
==3698089==by 0x2139092: vect_schedule_slp(vec_info*, vec<_slp_instance*,
va_heap, vl_ptr> const&) (tree-vect-slp.cc:10110)
==3698089==by 0x1F013DB: vect_slp_region(vec, vec, vec*,
unsigned int, loop*) (tree-vect-sl
p.cc:8222)
==3698089==by 0x1EFD5B3: vect_slp_bbs(vec const&, loop*) [clone .lto_priv.0] (tree-vect-slp.cc:8322)
==3698089==by 0x1EFD2DA: vect_slp_function(function*)
(tree-vect-slp.cc:8444)
==3698089==by 0x1EFCC6C: (anonymous
namespace)::pass_slp_vectorize::execute(function*) [clone .lto_priv.0]
(tree-vectorizer.cc:1534)
==3698089==by 0x1B69A70: execute_one_pass(opt_pass*) (passes.cc:2647)
==3698089==by 0x1C2C09B: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==3698089==by 0x1C2C0B8: execute_pass_list_1(opt_pass*) (passes.cc:2757)
==3698089==by 0x1C2C0B8: execute_pass_list_1(opt_pass*) (passes.cc:2757)
==3698089==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==3698089==
during GIMPLE pass: slp
a.i: In function
‘FLAC__fixed_compute_best_predictor_limit_residual_intrin_avx2’:
a.i:5:6: internal compiler error: Segmentation fault
5 | void FLAC__fixed_compute_best_predictor_limit_residual_intrin_avx2(
  |  ^
0x12a1362 crash_signal
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:319
0x2430014 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:9672
0x2430014 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:9514
0x242f05c vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:9965
0x242efac vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:9946
0x2139092 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:10110
0x1f013db vect_slp_region
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:8222
0x1efd5b3 vect_slp_bbs
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:8322
0x1efd2da vect_slp_function(function*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vect-slp.cc:8444
0x1efcc6c execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-vectorizer.cc:1534
```

I think pinskia will be able to simplify my reduced version more..

[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |14.2
   Keywords||ice-on-valid-code

[Bug tree-optimization/115508] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #4 from Sam James  ---
Created attachment 58440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58440=edit
reduced.i

[Bug tree-optimization/115508] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #3 from Sam James  ---
> I can't reproduce it with -march=znver2, just -march=znver1. Not compared
> the diff yet.

-march=znver2 -mprefer-vector-width=128 fails too

[Bug tree-optimization/115508] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #2 from Sam James  ---
I'm reducing.

[Bug tree-optimization/115508] ICE when building flac with -O2 -march=znver1

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

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

--- Comment #1 from Sam James  ---

==3050649== Invalid read of size 8
==3050649==at 0x192EB36: vect_schedule_slp_node(vec_info*, _slp_tree*,
_slp_instance*) [clone .part.0] (tree-vect-slp.cc:9279)
==3050649==by 0x1948643: vect_schedule_slp_node (tree-vect-slp.cc:9248)
==3050649==by 0x1948643: vect_schedule_scc(vec_info*, _slp_tree*,
_slp_instance*, hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_in
fo> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&) (tree-vect-slp.cc:9682)
==3050649==by 0x19486A8: vect_schedule_scc(vec_info*, _slp_tree*,
_slp_instance*, hash_map<_slp_tree*, slp_scc_info,
simple_hashmap_traits, slp_scc_in
fo> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&) (tree-vect-slp.cc:9663)
==3050649==by 0x1948E7A: vect_schedule_slp(vec_info*, vec<_slp_instance*,
va_heap, vl_ptr> const&) (tree-vect-slp.cc:9827)
==3050649==by 0x194BCC9: vect_slp_region(vec, vec, vec*,
unsigned int, loop*) (tree-vect-sl
p.cc:7948)
==3050649==by 0x194D54A: vect_slp_bbs(vec const&, loop*) (tree-vect-slp.cc:8048)
==3050649==by 0x194DBEA: vect_slp_function(function*)
(tree-vect-slp.cc:8170)
==3050649==by 0x1959B75: (anonymous
namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.cc:1533)
==3050649==by 0x1405CC2: execute_one_pass(opt_pass*) (passes.cc:2647)
==3050649==by 0x1406B39: execute_pass_list_1 (passes.cc:2756)
==3050649==by 0x1406B39: execute_pass_list_1(opt_pass*) (passes.cc:2757)
==3050649==by 0x1406EF6: execute_pass_list_1 (passes.cc:2757)
==3050649==by 0x1406EF6: execute_pass_list(function*, opt_pass*)
(passes.cc:2767)
==3050649==by 0xF02976: cgraph_node::expand() (cgraphunit.cc:1845)
==3050649==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
==3050649==
during GIMPLE pass: slp
/var/tmp/portage/media-libs/flac-1.4.3/work/flac-1.4.3/src/libFLAC/fixed_intrin_avx2.c:
In function 'FLAC__fixed_compute_best_predictor_wide_intrin_avx2':
/var/tmp/portage/media-libs/flac-1.4.3/work/flac-1.4.3/src/libFLAC/fixed_intrin_avx2.c:57:10:
internal compiler error: Segmentation fault

[Bug tree-optimization/115508] New: ICE when building flac with -O2 -march=znver1

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

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

Bug ID: 115508
   Summary: ICE when building flac with -O2 -march=znver1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58439=edit
fixed_intrin_avx2.i.xz

Originally reported downstream in Gentoo at https://bugs.gentoo.org/934383.

I can't reproduce it with -march=znver2, just -march=znver1. Not compared the
diff yet.

```
$ gcc-14 -c a.i -march=znver1 -m32 -mfpmath=sse -O2
during GIMPLE pass: slp
/var/tmp/portage/media-libs/flac-1.4.3/work/flac-1.4.3/src/libFLAC/fixed_intrin_avx2.c:
In function 'FLAC__fixed_compute_best_predictor_wide_intrin_avx2':
/var/tmp/portage/media-libs/flac-1.4.3/work/flac-1.4.3/src/libFLAC/fixed_intrin_avx2.c:57:10:
internal compiler error: Segmentation fault
0x55ccfe748bc3 crash_signal
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/toplev.cc:319
0x55ccfeaceb36 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:9279
0x55ccfeae8643 vect_schedule_slp_node
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:9248
0x55ccfeae8643 vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:9682
0x55ccfeae86a8 vect_schedule_scc
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:9663
0x55ccfeae8e7a vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap,
vl_ptr> const&)
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:9827
0x55ccfeaebcc9 vect_slp_region
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:7948
0x55ccfeaed54a vect_slp_bbs
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:8048
0x55ccfeaedbea vect_slp_function(function*)
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vect-slp.cc:8170
0x55ccfeaf9b75 execute
   
/usr/src/debug/sys-devel/gcc-14.1.1_p20240608/gcc-14-20240608/gcc/tree-vectorizer.cc:1533
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-14
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.1.1_p20240608/work/gcc-14-20240608/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
14.1.1_p20240608 p2' --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 14.1.1 20240608 (Gentoo Hardened 14.1.1_p20240608 p2)
```

[Bug target/114528] (0xFFFFFFFF0001FFFFULL - 0x00123000) constant forming could be done in 2 instructions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-06-16

--- Comment #2 from Andrew Pinski  ---
.

[Bug ada/115507] New: 'Wide_Wide_Value failed for unicode strings

[dramwang at 163 dot com via Gcc-bugs]

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

Bug ID: 115507
   Summary: 'Wide_Wide_Value failed for unicode strings
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dramwang at 163 dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

For following code, CONSTRAINT_ERROR exception will be raised:

```
with Ada.Wide_Wide_Text_IO ;

procedure Sample is
   use Ada.Wide_Wide_Text_IO ;

   type T is (A, 乙) ;
begin
   Put_Line (A'Wide_Wide_Image) ;
   Put_Line (乙'Wide_Wide_Image) ;

   Put_Line (T (T'Wide_Wide_Value ("A"))'Wide_Wide_Image) ;
   Put_Line (T (T'Wide_Wide_Value ("乙"))'Wide_Wide_Image) ;
end Sample ;
```

Output:

```
A
乙  
   A

raised CONSTRAINT_ERROR : bad input for 'Value: "乙"
[./sample]
0x41cd20 System.Val_Util.Bad_Value at s-valuti.adb:61
0x41c6d9 System.Val_Enum_8.Impl.Value_Enumeration at s-valuen.adb:149
0x404a4d Sample at sample.adb:12
0x4046b7 Main at b~sample.adb:258
[/lib/x86_64-linux-gnu/libc.so.6]
0x7fc03814f248
0x7fc03814f303
[./sample]
0x4040ef _start at ???
0xfffe
```

'Wide_Value will also failed with the same error.

I've tested in Debian 12 x86_64 with GNAT 15.0.0 20240615 (git 079506).

[Bug target/115475] AArch64 should define __ARM_FEATURE_SVE_BF16 when appropriate

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115457
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-16

[Bug target/108316] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE since r13-2737-g4a773bf2f08656

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.4|---

[Bug target/115087] dead block not eliminated in SVE intrinsics code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||aarch64-sve
 CC||pinskia at gcc dot gnu.org

[Bug target/113859] popcount HI can be vectorized for non-SVE

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Patch was posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650311.html

Latest patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653405.html

[Bug target/100211] [11/12/13/14/15 Regression] aarch64: OOB accesses in aarch64_{save,restore}_callee_saves

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||aarch64-sve
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Andrew Pinski  ---
Let me take a look at this.

[Bug target/106329] No optimization for SVE pfalse predicate

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/97405] ICE in get_or_alloc_expr_for in code hoisting with SVE intrinsics

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||15.0

--- Comment #6 from Andrew Pinski  ---
Fixed on the trunk, I suspect r15-917-gc9842f99042454 fixed it.
That revision is explictly fixing `POLY_INT_CST [16, 16] /[ex] 16` case too.

I think we should just add the testcase and close it as fixed.

[Bug target/111733] Emit inline SVE FSCALE instruction for ldexp

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||aarch64-sve
   Last reconfirmed||2024-06-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement

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

[Bug target/114906] aarch64 locally_streaming ICE with -fstack-clash-protection in aarch64_expand_prologue

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-06-15
Summary|aarch64 locally_streaming   |aarch64 locally_streaming
   |ICE in  |ICE with
   |aarch64_expand_prologue |-fstack-clash-protection in
   ||aarch64_expand_prologue
 Status|UNCONFIRMED |NEW

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

[Bug web/115391] Suggest add current size of git repository to git page

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
Tips for doing this with the GitHub mirror of it:
https://stackoverflow.com/questions/8646517/how-can-i-see-the-size-of-a-github-repository-before-cloning-it

[Bug rtl-optimization/115505] missing optimization: thumb1 use ldmia/stmia for load store DI/DF data when possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug bootstrap/112422] Build process does a redundant number of checks ?

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

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

--- Comment #4 from Eric Gallager  ---
(In reply to Sam James from comment #3)
> There's some stuff we could cache for sure but it wouldn't be the majority
> of the checks - stuff like finding tools like awk, sed should work
> regardless of which stage we're in and so on.

gawk and sed were potential host modules at one point previously, too, but it
looks like they've been removed, so yeah I guess it'd be safe for them now...
anything that might fall in this category should get checked against
Makefile.def to make sure there aren't already potential modules for them for
people trying to combine trees or something...

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #6 from Brecht Sanders  
---
You're right. Sorry I missed that.

[Bug c++/115486] ICE: Segfault while compiling partial template specialization with expanded parameter pack of function pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to work|7.5.0   |
   Last reconfirmed||2024-06-15
 Status|UNCONFIRMED |NEW

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

[Bug c++/115503] Explicit deduction guide - Capture parameter pack in lambda - Compiler segfaults

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||10.1.0, 11.1.0, 9.1.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-06-15

--- Comment #1 from Andrew Pinski  ---
Confirmed. Seems to be ICEing since lambda in unevaluated context support was
added.

[Bug c++/115504] [14/15 Regression] Wrong decltype result for a captured reference inside lambda

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect the fix for PR 96917 broke references (or rather changed all to be
non references).

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #11)
> Although that class template has been there for years, so if any library
> like abseil was using the built-in, they're already have the problem that
> libstdc++ now has.

It looks like the abseil code is not using __is_pointer directly at all, but
rather the standard headers here. I suspect we should just rename the
__is_pointer template to workaround this clang oddness (and add a comment on
why the name is not __is_pointer).

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #11 from Jonathan Wakely  ---
Although that class template has been there for years, so if any library like
abseil was using the built-in, they're already have the problem that libstdc++
now has.

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #10 from Jonathan Wakely  ---
The only foolproof fix would be to rename the __is_pointer class template.

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

--- Comment #9 from Jonathan Wakely  ---
Changing libstdc++ order of includes won't help abseil. If their use of
__is_pointer still comes after any standard header has included
cpp_type_traits.h, the identifier will be "poisoned" by the class template. So
they need their own workaround.

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

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

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

--- Comment #5 from Lewis Hyatt  ---
(In reply to Brecht Sanders from comment #4)
> No, that patch wasn't added for my build, see my build recipe here:
> https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib

Thanks, this script is useful. FWIW I think the patch is there, line 778?
Unless I am missing something.

I see you also commented out the assert in your recipe. I am still not sure if
that is just masking some deeper issue, but I am getting close to being able to
reproduce it myself and will let you know.

[Bug rtl-optimization/115505] missing optimization: thumb1 use ldmia/stmia for load store DI/DF data when possible

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Note patches should be posted to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[Bug middle-end/115506] Possible but missed "cmp" instruction merging (x86 & ARM, optimization)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|rtl-optimization|middle-end

[Bug other/115506] New: Possible but missed "cmp" instruction merging (x86 & ARM, optimization)

[Explorer09 at gmail dot com via Gcc-bugs]

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

Bug ID: 115506
   Summary: Possible but missed "cmp" instruction merging (x86 &
ARM, optimization)
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Explorer09 at gmail dot com
  Target Milestone: ---

I'm not sure if the GCC developers are interested in this optimization or if
this issue has been reported before.



(Compiler Explorer link: https://godbolt.org/z/vqqf865cb)

```c
#include 

// Modified from 
uint32_t utf8_to_code_point(const uint8_t **sequence) {
if (**sequence <= 0x7F) {
return *(*sequence)++;
}

unsigned int max_length;
uint32_t min_code_point;
if ((**sequence & 0xF0) == 0xE0) { /* NOTE 0 */
max_length = 3;
min_code_point = 0x0800;
} else if ((**sequence & 0xF0) < 0xE0) { /* NOTE 1 */
max_length = 2;
min_code_point = 0x80;
} else {
max_length = 4;
min_code_point = 0x1;
}

uint32_t code_point = (uint32_t)**sequence - (0xFF & ~(0xFF >>
max_length));
while (1) {
(*sequence)++;
if (--max_length == 0) {
break;
}
unsigned int code_offset = (unsigned int)**sequence - 0x80;
if (code_offset > 0x3F) {
return (uint32_t)-1;
}
code_point = (code_point << 6) + code_offset;
}

if (code_point < min_code_point) {
return (uint32_t)-1;
}
if (code_point >= 0xD800 && code_point <= 0xDFFF) {
return (uint32_t)-1;
}
return code_point;
}
```

I wrote this code with the expectation that the compiler can optimize the "cmp"
 instructions so that the same compare status can be used twice.

But instead I get this:

```x86asm
#   ...
movl%eax, %ecx
andl$-16, %ecx
cmpb$-32, %cl
je  .L8
cmpb$-33, %cl
ja  .L9
#   ...
```

The immediate constant for the second "cmp" instruction gets modified
off-by-one (I can guess the reason for that) and missed this particular chance
of merging the comparisons.

A workaround is to modify the line marked with the `/* NOTE 1 */` comment to
use `<=` instead of `<`. But I wish GCC can detect this optimization
opportunity better.

[Bug c++/115231] [C++20] [Modules] deduction guides reachability

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||nshead at gcc dot gnu.org
   Last reconfirmed|2024-05-26 00:00:00 |2024-06-15
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org

[Bug rtl-optimization/115505] New: missing optimization: thumb1 use ldmia/stmia for load store DI/DF data when possible

[lis8215 at gmail dot com via Gcc-bugs]

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

Bug ID: 115505
   Summary: missing optimization: thumb1 use ldmia/stmia for load
store DI/DF data when possible
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lis8215 at gmail dot com
  Target Milestone: ---

Created attachment 58438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58438=edit
possible solution patch

At the moment GCC emits two ldr/str instructions for DI/DF modes load/store.
However there's a trick to use ldmia/stmia when address register in not
used anymore/dead or reused.

I don't know if it affects arm and/or thumb2 as well.
Patch for possible solution for thumb1 provided.

Comparing code size with the patch gives for v6-m/nofp:
   libgcc:  -52 bytes / -0.10%
Newlib's libc:  -68 bytes / -0.03%
 libm:  -96 bytes / -0.10%
libstdc++: -140 bytes / -0.02%

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to Andrew Pinski from comment #7)
> `-fno-lifetime-dse` is already used but I get the feeling there might be
> strict aliasing issues in the code though.  What happens if you add
> -fno-strict-aliasing ?
> 
> This code gives me strict aliasing violation vibes:
> ```
> T **getAddressOfPointer(ExternalASTSource *Source) const {
> // Ensure the integer is in pointer form.
> (void)get(Source);
> return reinterpret_cast();
>   }
> ```

I tried with the following diff but that did not fix the issue:

diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake
b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 5ca580fbb59c..51c470dcc3ed 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -679,7 +679,7 @@ if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
   # crash if LLVM is built with GCC and LTO enabled (#57740).  Until
   # these bugs are fixed, we need to disable dead store eliminations
   # based on object lifetime.
-  append("-fno-lifetime-dse" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+  append("-fno-lifetime-dse -fno-strict-aliasing" CMAKE_C_FLAGS
CMAKE_CXX_FLAGS)
 endif ()

 # Modules enablement for GCC-compatible compilers:

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #12 from Xi Ruoyao  ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> > (In reply to Kewen Lin from comment #9)
> > > Since it's a breakage during stage2, it's concluded that some built stage1
> > > stuffs behave unexpectedly.  You probably can try to run regression 
> > > testing
> > > just with stage1 compiler to see if there is any regression exposed.
> > > 
> > > If without any luck, then you probably have to isolate into one or several
> > > object files, since you have "objects" for "good" and "bad" stage1 
> > > compiler,
> > > you can be able to isolate some in between further. Once you get some
> > > isolated, you can probably get some hints it's a bug in LLVM source or 
> > > gcc.
> > 
> > Thanks. This sounds like a good idea. I will try to identify the object
> > files that differ.
> 
> First result of the comparison is that Clang and GCC are building with
> different flags:
> 
> Clang-only flags: -Werror=unguarded-availability-new
> -Wc++98-compat-extra-semi -Wcovered-switch-default -Wnon-virtual-dtor
> -Wstring-conversion -Wmisleading-indentation
> 
> GCC-only flags:  -fno-lifetime-dse-Wno-missing-field-initializers  
> -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess
> -Wno-redundant-move -Wno-pessimizing-move-Wno-comment
> -Wno-misleading-indentation
> 
> I'll upload the build results later to my cloud space if anyone wants to
> help debug as the diff between the two build folders is rather big.

-Wxxx shouldn't have an effect on code generation.  -fno-lifetime-dse is quite
intentional, see PR106943.

[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr

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

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

--- Comment #9 from Georg-Johann Lay  ---
(In reply to Jonathan Wakely from comment #1)
> since float, double and long double all seem to be the same size on avr

Not necessarily. Since GCC v10, the default for long double is 64 bit (IEEE
double), but [long] double is also switchable per -m[long-]double={32,64}.

https://gcc.gnu.org/gcc-10/changes.html#avr

https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/AVR-Options.html#index-mdouble

[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #4 from Brecht Sanders  
---
No, that patch wasn't added for my build, see my build recipe here:
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #8 from Arthur O'Dwyer  ---
FWIW, I also ran into this, this morning.
Reduced: https://godbolt.org/z/rxYKTqKd4
Organically in Abseil: https://godbolt.org/z/9eoqKzYjc
(This happens because Abseil #includes  before 
(alphabetically). If you switch the order of those two includes, it Just
Works.)

IMVHO libstdc++ should do jwakely's idea of #include  from the
offending header file; that's the most foolproof O(1) solution, rather than the
O(N) solution of being really careful to always write `bool(__is_foo(T))`
instead of `__is_foo(T)`. Also, there are definitely third-party libraries
(like Abseil) out there who legitimately want to use `__is_pointer(T)` in their
own code, and right now they have no idea that they ought to write all their
uses with an extra `bool` cast just to work around a problematic interaction
between Clang and libstdc++ (a mode they probably don't even build in their
CI). So fixing the problem once and for all on libstdc++'s side of the fence
would be really helpful.

[Bug c++/115504] New: Wrong decltype result for a captured reference inside limbda

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 115504
   Summary: Wrong decltype result for a captured reference inside
limbda
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program
```
template int foo() = delete;
template<> int foo() { return 0; }

int main() { 
int y = 0;
int  = y;
return []() {
decltype(auto) x = i;
return foo();
}();
}
```
is accepted in Clang, MSVC and GCC 13.3, but not in GCC 14, which thinks that
`decltype(x)=int`. Online demo: https://gcc.godbolt.org/z/fc1nrP4P9

Related discussion: https://stackoverflow.com/a/78626163/7325599

[Bug target/113341] Using GCC as the bootstrap compiler breaks LLVM on 32-bit PowerPC

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Kewen Lin from comment #9)
> > Since it's a breakage during stage2, it's concluded that some built stage1
> > stuffs behave unexpectedly.  You probably can try to run regression testing
> > just with stage1 compiler to see if there is any regression exposed.
> > 
> > If without any luck, then you probably have to isolate into one or several
> > object files, since you have "objects" for "good" and "bad" stage1 compiler,
> > you can be able to isolate some in between further. Once you get some
> > isolated, you can probably get some hints it's a bug in LLVM source or gcc.
> 
> Thanks. This sounds like a good idea. I will try to identify the object
> files that differ.

First result of the comparison is that Clang and GCC are building with
different flags:

Clang-only flags: -Werror=unguarded-availability-new -Wc++98-compat-extra-semi
-Wcovered-switch-default -Wnon-virtual-dtor -Wstring-conversion
-Wmisleading-indentation

GCC-only flags:  -fno-lifetime-dse-Wno-missing-field-initializers  
-Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move
-Wno-pessimizing-move-Wno-comment -Wno-misleading-indentation

I'll upload the build results later to my cloud space if anyone wants to help
debug as the diff between the two build folders is rather big.

[Bug libstdc++/115482] [14/15 Regression] print.cc fails with avrlibc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/115497] [15 Regression] __is_pointer doesn't compile with clang since 014879ea4c86b3b8ab6b61a1226ee5b31e816c8b

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/108467] false positive -Wmaybe-uninitialized warning at -O1 or higher

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

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Sam James from comment #3)
> For 14/15, it seems gone with -O2, but I see it with -Og.

The warning still occurs with -O1 too.

[Bug target/111376] missed optimization of one bit test on MIPS32r1

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Siarhei Volkau  ---
Might it be that LoongArch have register reuse dependency?

I observed similar behavior on XBurst with load/store/reuse pattern:

e.g. this code
LW $v0, 0($t1)# Xburst load latency is 4 but it has bypass 
SW $v0, 0($t2)# to subsequent store operation, thus no stall here
ADD $v0, $t1, $t2 # but it stalls here, because of register reuse
  # until LW op is not completed.

[Bug target/111376] missed optimization of one bit test on MIPS32r1

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Siarhei Volkau  ---
Created attachment 58437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58437=edit
application to test performance of shift

Here is the test application (MIPS32 specific) I wrote.

It allows to detect execution cycles and extra pipeline stalls for SLL if they
take place.

for XBurst 1 (jz4725b) result is the following:

`SLL to use latency test` execution median: 168417 ns, min: 168416 ns
`SLL to use latency test with nop` execution median: 196250 ns, min: 196166 ns

`SLL to branch latency test` execution median: 196250 ns, min: 196166 ns
`SLL to branch latency test with nop` execution median: 224000 ns, min: 224000
ns

`SLL by 7 to use latency test` execution median: 168417 ns, min: 168416 ns
`SLL by 15 to use latency test` execution median: 168417 ns, min: 168416 ns
`SLL by 23 to use latency test` execution median: 168417 ns, min: 168416 ns
`SLL by 31 to use latency test` execution median: 168417 ns, min: 168416 ns

`LUI>AND>BEQZ reference test` execution median: 196250 ns, min: 196166 ns
`SLL>BGEZ reference test` execution median: 168417 ns, min: 168416 ns



and what does it mean:
`SLL to use latency test` 168417 ns and `.. with nop` 196250 ns
means that there's no extra stall cycles between SLL and further use by ALU
operation.

`SLL to branch latency test` and `.. with nop` result
means that there's no extra stall cycles between SLL and further use by branch
operations.

`SLL by N` results means that SLL execution time doesn't depend on shift
amount.

and finally, the reference test results showcases that SLL>BGEZ approach is
faster than LUI>AND>BEQZ.

[Bug libstdc++/115481] HAVE_* for long double math functions wrong for avrlibc (target AVR)

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

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

--- Comment #4 from Georg-Johann Lay  ---
(In reply to dv from comment #0)
> New versions of avrlibc provide long double math functions,

In the case it matters:

1) avr-libc has long double prototypes in math.h since v2.2.

2a) When long double is a 32-bit type, then the long double functions are
implemented in avr-libc as aliases to float functions.

2b) When long double is a 64-bit type, then the long double functions are
implemented in avr-libgcc. This requires GCC v10+ and an appropriate
configuration (default is long long = 64 bit and switchable to 32 bit)
https://gcc.gnu.org/install/configure.html#avr

3) The implementations are not complete, for example log2f is missing, gamma
etc. but log2l is available when long long is 64.

4) Available multilib variants ([long] double is 32 and / or 64 bits) can be
selected at configure time, and depending on configuration, [long] double
layout can also be selected at compile time (-mdouble=64 etc.).

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

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

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

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

https://gcc.gnu.org/g:57af69d56e72af049444c42bc7216d2737683f08

commit r15-1349-g57af69d56e72af049444c42bc7216d2737683f08
Author: Gerald Pfeifer 
Date:   Sat Jun 15 09:42:20 2024 +0200

doc: Remove pointer to old versions of binutils

The oldest release in the advertised location dates back to August 2002,
which is way older than we remotely want to cover here.

gcc:
PR target/69374
* doc/install.texi (Specific): Remove pointer to old versions
of binutils.

[Bug target/111376] missed optimization of one bit test on MIPS32r1

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

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

--- Comment #14 from YunQiang Su  ---
And it seems that the performance of SLL is related with the operand.

Just iterate from 0 to 1e9:

```
0b00 :
 b00:   000223c0sll a0,v0,0xf  <-- the code is something
wrong
   in normal code, we should
access
   v0 here.  v0 will be 100 or
1000.
 b04:   04810003bgeza0,b14 
 b08:   nop
 b0c:   03e8jr  ra
 b10:   240203e8li  v0,1000
 b14:   03e8jr  ra
 b18:   24020064li  v0,100
 b1c:   nop
```

is slower than

```
0b00 :
 b00:   000223c0sll a0,a0,0xf
 b04:   04810003bgeza0,b14 
 b08:   nop
 b0c:   03e8jr  ra
 b10:   240203e8li  v0,1000
 b14:   03e8jr  ra
 b18:   24020064li  v0,100
 b1c:   nop
```


I have no idea how to make a trade off here.

[Bug c++/115503] New: Explicit deduction guide - Capture parameter pack in lambda - Compiler segfaults

[thomaspkhealy at yahoo dot com via Gcc-bugs]

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

Bug ID: 115503
   Summary: Explicit deduction guide - Capture parameter pack in
lambda - Compiler segfaults
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomaspkhealy at yahoo dot com
  Target Milestone: ---

With the trunk version of g++ (dated 15 June 2023), the following program
causes the compiler to segfault:

template
struct Frog {
template
Frog(Params&&...){}
};

template
Frog(Params&&... args) -> Frog< sizeof([](){}) >;

int main(void)
{
Frog var(1.1, 2.2, 3.3, 4.4);
}

Here's a godbolt: https://godbolt.org/z/495xrT1c3

Here's the compiler output:

: In substitution of 'template Frog(Params&& ...)->
Frog)> [with Params = {double, double, double, double}]':
:12:37:   required from here
   12 | Frog var(1.1, 2.2, 3.3, 4.4 );
  | ^
:8:55: internal compiler error: Segmentation fault
8 | Frog(Params&&... args) -> Frog< sizeof([](){}) >;
  |   ^
0x26c86bc internal_error(char const*, ...)
???:0
0xcc3f7d tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xcb4f11 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
???:0
0xcb7319 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xcb28ba tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xcb2798 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc98733 instantiate_template(tree_node*, tree_node*, int)
???:0
0xccbd15 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xa8eb19 perform_dguide_overload_resolution(tree_node*, vec const*, int)
???:0
0xc8ed76 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int, tree_node*)
???:0
0xb533f1 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xc6f13a c_parse_file()
???:0
0xdc5989 c_common_parse_file()
???:0
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.

[Bug target/111376] missed optimization of one bit test on MIPS32r1

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

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

--- Comment #13 from YunQiang Su  ---
I try to insert 
li  $3, 500
li  $5, 500
between SLL/BGEZ  and LUI+AND/BNE.

The later is still some faster on Loongson 3A4000.

I notice something like this in 74K's software manual:

The 74K core’s ALU is pipelined. Some ALU instructions complete the operation
and bypass the results in this cycle. These instructions are referred to as
single-cycle ops and they include all logical instructions (AND, ANDI, OR, ORI,
XOR, XORI, LUI), some shift instructions (SLL sa<=8, SRL 31<=sa<=25), and some
arithmetic instructions (ADD rt=0, ADDU rt=0, SLT, SLTI, SLTU, SLTIU, SEH, SEB,
ZEH, ZEB). In addition, add instructions (ADD, ADDU, ADDI, ADDIU) complete the
operation and bypass results to the ALU pipe in this cycle.


I guess it means that if sa>8, SLL may be some slow.
On Loongson 3A4000, the value seems to be 20/21. It may means that we should be
care about for 64bit.

Can you have a test on XBurst 1?

[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855

[gang.peng at aclsemi dot com via Gcc-bugs]

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

--- Comment #8 from Gang Peng  ---
(In reply to Andrew Pinski from comment #6)
>   if (!crtl->uses_pic_offset_table || compute_now)
> {
>   gcc_assert (can_create_pseudo_p ()
>   || (pic_reg != NULL_RTX
>   && REG_P (pic_reg)
>   && GET_MODE (pic_reg) == Pmode));
> 
> 
> It has to do with these 2 options:
> >  -msingle-pic-base -mpic-register=r9

Dear Mr. Pinski,

Thank you very much for you kindly reply.
Yes, I need these compile option:
CFLAGS += -fPIE
CFLAGS += -msingle-pic-base
CFLAGS += -mpic-register=r9
CFLAGS += -fomit-frame-pointer
CFLAGS += -mno-pic-data-is-text-relative
CFLAGS += -mthumb
CFLAGS += -mlong-calls 

When we remove the -mlong-calls option, it can compile OK, but we need the
-mlong-calls option to compile.

Thanks &
BRs

Gang Peng

[Bug libcc1/105695] GCC 10.3.1 (20220519) build failure with GCC 12

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Sam James  ---
GCC 10 is EOL.

Downstream, we did:
```
if ! tc_version_is_at_least 11 && [[ $(gcc-major-version) -ge 12 ]] ;
then
# https://gcc.gnu.org/PR105695
# bug #849359
export ac_cv_std_swap_in_utility=no
fi
```