[Bug bootstrap/111642] [14 Regression] profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Rolf Eike Beer changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #2 from Rolf Eike Beer ---
Just hit the one in simplify-rtx.cc on Linux/sparc64:
In file included from
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./gcc/coretypes.h:480,
from
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./gcc/simplify-rtx.cc:23:
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./gcc/poly-int.h:
In instantiation of ‘constexpr poly_int::poly_int(poly_int_full, const
Cs& ...) [with Cs = {int, int}; unsigned int N = 1; C = long int]’:
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./gcc/poly-int.h:439:13:
required from here
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./gcc/simplify-rtx.cc:8692:25:
in ‘constexpr’ expansion of ‘poly_int<1, long int>(1, 1)’
/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./gcc/poly-int.h:453:5:
error: too many initializers for ‘long int [1]’
453 | : coeffs { (typename poly_coeff_traits::
| ^
454 | template init_cast::type (cs))... } {}
| ~~~
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 --- Comment #3 from Lukas Grätz --- (In reply to Marc Glisse from comment #2) > (In reply to Andrew Pinski from comment #1) > > I am 99% sure this is falls under don't do this as flatten inlines > > everything it can that the function calls ... > > Maybe people end up abusing flatten because we are missing a convenient way > for a caller to ask that a call be inlined? From the callee, we can use > always_inline (couldn't this be used on name_original in this testcase?), > but from the caller... Here even a non-recursive version of flatten would > have helped. Yes, this was what I was searching for, but I found only flatten. Also, that flatten is applied recursively is not mentioned in the documentation and it is also not what I would expect. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html I don't want to always_inline name_original. What I want is to only inline name_original when called by the wrapper function name, hence the flatten. Because I replace every call to name with name_original where I don't want to apply the instrumentation by the wrapper function name. Thanks!
[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566 --- Comment #5 from Jorn Wolfgang Rennecke --- I had a look at riscv_legitimize_move. It doesn't seem to suffer from quite the same problem as legitimize_move does, but it could if another problem was fixed: riscv_legitimize_move changes the rtl it's passed. That can lead to trouble if this is shared rtl.
[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566 --- Comment #4 from Jorn Wolfgang Rennecke --- Also, the GET_MODE_BITSIZE (mode).to_constant () <= MAX_BITS_PER_WORD in the *mov_mem_to_mem splitter can generate unaligned accesses, yet it is not guarded by a check that the target supports them.
[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566 --- Comment #3 from Jorn Wolfgang Rennecke --- riscv-v.cc:legitimize_move has: if (MEM_P (dest) && !REG_P (src)) src = force_reg (mode, src); return false; since src is passed by value, this is pointless. The caller still had src as a MEM.
[Bug target/111645] New: Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645 Bug ID: 111645 Summary: Intrinsics vec_sldb /vec_srdb fail with __vector unsigned __int128 Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: munroesj at gcc dot gnu.org Target Milestone: --- Created attachment 56018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56018&action=edit example of the problem. Compile with gcc -m64 -O3 -mcpu=power10 -c sldbi.c GCC 12 and 13 fail to compile vector intrisic vec_sldb / vec_srdb as required by the Power Vector Intrinsic Programming Reference. error: invalid parameter combination for AltiVec intrinsic ‘__builtin_vec_sldb’ Both the Programming Reference and the GCC documentation state that vector (unsigned/signed) __int128 are valid operands. But they fail with a error: invalid parameter combination for AltiVec intrinsic ‘__builtin_vec_sldb’ or error: invalid parameter combination for AltiVec intrinsic ‘__builtin_vec_srdb’
[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
--- Comment #2 from Jorn Wolfgang Rennecke ---
This also causes trouble with my cpymem patch.
With the *movv8si_mem_to_mem pattern, ira.cc:combine_and_move_insns
will eagerly transform
(insn 1606 1603 1608 77 (set (reg/f:SI 1187)
(plus:SI (reg/f:SI 65 frame)
(const_int -1248 [0xfb20])))
"/home/amylaar/embecosm/fsf-cme3/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-add.c":44:0
discrim 126 4 {*addsi3}
(nil))
(insn 1608 1606 1609 77 (set (reg:V8SI 1189)
(mem/u/c:V8SI (reg/f:SI 5064) [0 S32 A128]))
"/home/amylaar/embecosm/fsf-cme3/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-add.c":44:0
discrim 126 1151 {*movv8si}
(expr_list:REG_DEAD (reg/f:SI 5064)
(expr_list:REG_EQUAL (mem/u/c:V8SI (const:SI (plus:SI (symbol_ref:SI
("*.LANCHOR0") [flags 0x182])
(const_int 64 [0x40]))) [0 S32 A128])
(nil
(insn 1609 1608 12961 77 (set (mem/v/c:V8SI (reg/f:SI 1187) [1 S32 A128])
(reg:V8SI 1189))
"/home/amylaar/embecosm/fsf-cme3/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-add.c":44:0
discrim 126 1151 {*movv8si}
(expr_list:REG_DEAD (reg:V8SI 1189)
(expr_list:REG_DEAD (reg/f:SI 1187)
(nil
into
(insn 1608 1603 16000 77 (set (reg:V8SI 1189)
(mem/u/c:V8SI (reg/f:SI 5064) [0 S32 A128]))
"/home/amylaar/embecosm/fsf-cme3/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-add.c":44:0
discrim 126 1151 {*movv8si}
(expr_list:REG_EQUIV (mem/u/c:V8SI (const:SI (plus:SI (symbol_ref:SI
("*.LANCHOR0") [flags 0x182])
(const_int 64 [0x40]))) [0 S32 A128])
(expr_list:REG_DEAD (reg/f:SI 5064)
(nil
(insn 16000 1608 1609 77 (set (reg/f:SI 1187)
(plus:SI (reg/f:SI 65 frame)
(const_int -1248 [0xfb20])))
"/home/amylaar/embecosm/fsf-cme3/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-add.c":44:0
discrim 126 4 {*addsi3}
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 65 frame)
(const_int -1248 [0xfb20]))
(nil)))
(insn 1609 16000 12961 77 (set (mem/v/c:V8SI (reg/f:SI 1187) [1 S32 A128])
(mem/u/c:V8SI (reg/f:SI 5064) [0 S32 A128]))
"/home/amylaar/embecosm/fsf-cme3/gcc/gcc/testsuite/c-c++-common/torture/complex-sign-add.c":44:0
discrim 126 -1
(expr_list:REG_DEAD (reg:V8SI 1189)
(expr_list:REG_DEAD (reg/f:SI 1187)
(nil
during compilation of check_add_long_double.
When a pattern with a mandatory split is recognized, you must make sure it can
be split. If the pattern ceases to be valid at some point during the
compilation, you must make sure it can be split or otherwise transformed
before another attempt to recognize it is made.
[Bug fortran/111644] New: [13 regression] many failures after r13-7923-gd9b3269bdccac2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644 Bug ID: 111644 Summary: [13 regression] many failures after r13-7923-gd9b3269bdccac2 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d9b3269bdccac2db9200303494c4e82f2aeb7bbc, r13-7923-gd9b3269bdccac2 FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O0 scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O1 scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O2 scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O3 -g scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_basics_1.f90 -Os scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/allocatable_scalar_9.f90 -O0 scan-tree-dump-times original "__builtin_free" 54 FAIL: gfortran.dg/allocatable_scalar_9.f90 -O1 scan-tree-dump-times original "__builtin_free" 54 FAIL: gfortran.dg/allocatable_scalar_9.f90 -O2 scan-tree-dump-times original "__builtin_free" 54 FAIL: gfortran.dg/allocatable_scalar_9.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions scan-tree-dump-times original "__builtin_free" 54 FAIL: gfortran.dg/allocatable_scalar_9.f90 -O3 -g scan-tree-dump-times original "__builtin_free" 54 FAIL: gfortran.dg/allocatable_scalar_9.f90 -Os scan-tree-dump-times original "__builtin_free" 54 FAIL: gfortran.dg/coarray/alloc_comp_6.f90 -fcoarray=lib -O2 -lcaf_single -latomic (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray/alloc_comp_6.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/alloc_comp_7.f90 -fcoarray=lib -O2 -lcaf_single -latomic (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray/alloc_comp_7.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/get_array.f90 -fcoarray=lib -O2 -lcaf_single -latomic (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray/get_array.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/scalar_alloc_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray/scalar_alloc_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/send_array.f90 -fcoarray=lib -O2 -lcaf_single -latomic (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray/send_array.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray/sendget_array.f90 -fcoarray=lib -O2 -lcaf_single -latomic (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray/sendget_array.f90 -fcoarray=lib -O2 -lcaf_single -latomic (test for excess errors) FAIL: gfortran.dg/coarray_lib_alloc_1.f90 -O (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray_lib_alloc_1.f90 -O (test for excess errors) FAIL: gfortran.dg/coarray_lib_token_2.f90 -O scan-tree-dump-times original "sub \\([^,]*caf.data, &[^,]*caf_dt.data.->b, caf.token, 0, caf_dt.token, 4\\)" 1 FAIL: gfortran.dg/coarray_lib_token_2.f90 -O scan-tree-dump-times original "sub \\(integer.kind=4. . restrict x1, integer.kind=4. . restrict x2, void . restrict caf_token.[0-9]+, integer.kind=.. caf_offset.[0-9]+, void . restrict caf_token.[0-9]+, integer.kind=.. caf_offset.[0-9]+\\)" 1 FAIL: gfortran.dg/coarray_lib_token_2.f90 -O scan-tree-dump-times original "sub2 \\([^,]*x1, [^,]*x2, caf_token.[0-9]+, [^,]*caf_offset[^,]*, caf_token.[0-9]+, [^,]*caf_offset[^,]*\\)" 1 FAIL: gfortran.dg/coarray_lib_token_2.f90 -O scan-tree-dump-times original "sub2 \\(integer.kind=4. . restrict y1, integer.kind=4. . restrict y2, void . restrict caf_token.[0-9]+, integer.kind=.. caf_offset.[0-9]+, void . restrict caf_token.[0-9]+, integer.kind=.. caf_offset.[0-9]+\\)" 1 FAIL: gfortran.dg/coarray_lib_token_2.f90 -O scan-tree-dump-times original "sub_opt \\(.integer.kind=4. .. caf.data, caf.token, 0\\)" 1 FAIL: gfortran.dg/coarray_lib_token_2.f90 -O scan-tree-dump-times original "sub_opt \\(0B, 0B, 0\\)" 1 FAIL: gfortran.dg/coarray_lib_token_2.f90 -O (internal compiler error: in wide_int_to_tree_1, at tree.cc:1755) FAIL: gfortran.dg/coarray_lib_token_2.f90 -O (test for excess er
[Bug bootstrap/111642] [14 Regression] profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642 --- Comment #1 from Sergei Trofimovich --- Looks like this code is all under `#if CHECKING_P` of sorts. A few more possibly affected entries: ``` $ git grep -P 'poly_int64 \(\d+, \d+\)' gcc/config/riscv/riscv-selftests.cc: -BYTES_PER_RISCV_VECTOR * 33, poly_int64 (207, 0), gcc/config/riscv/riscv-selftests.cc: poly_int64 (-207, 0), poly_int64 (0, 207), gcc/config/riscv/riscv-selftests.cc: poly_int64 (0, -207), poly_int64 (, 0), gcc/config/riscv/riscv-selftests.cc: poly_int64 (0, ), poly_int64 (4096, 4096), gcc/config/riscv/riscv-selftests.cc: poly_int64 (17, 4088), poly_int64 (3889, 4104), gcc/config/riscv/riscv-selftests.cc: poly_int64 (9317, -88), poly_int64 (4, 4), gcc/config/riscv/riscv-selftests.cc: poly_int64 (17, 4), poly_int64 (-7337, 4), gcc/config/riscv/riscv-selftests.cc: poly_int64 (219, -1508), poly_int64 (2, 2), gcc/config/riscv/riscv-selftests.cc: poly_int64 (33, 2), poly_int64 (-7337, 2), gcc/config/riscv/riscv-selftests.cc: poly_int64 (945, -954), poly_int64 (1, 1), gcc/config/riscv/riscv-selftests.cc: poly_int64 (977, 1), poly_int64 (-339, 1), gcc/config/riscv/riscv-selftests.cc: poly_int64 (44, -1), poly_int64 (9567, 77), gcc/config/riscv/riscv.cc: return poly_int64 (1, 1); gcc/rtl-tests.cc: rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); gcc/rtl-tests.cc: rtx x255 = gen_int_mode (poly_int64 (1, 255), QImode); gcc/rtl-tests.cc: ASSERT_EQ (x1, gen_int_mode (poly_int64 (1, 1), QImode)); gcc/rtl-tests.cc: ASSERT_NE (x1, gen_int_mode (poly_int64 (1, 1), HImode)); gcc/rtl-tests.cc: ASSERT_KNOWN_EQ (const_poly_int_value (x1), poly_int64 (1, 1)); gcc/rtl-tests.cc: ASSERT_KNOWN_EQ (rtx_to_poly_int64 (x1), poly_int64 (1, 1)); gcc/rtl-tests.cc: ASSERT_MAYBE_NE (rtx_to_poly_int64 (x255), poly_int64 (1, 255)); gcc/rtl-tests.cc: rtx offset1 = gen_int_mode (poly_int64 (9, 11), Pmode); gcc/rtl-tests.cc: ASSERT_RTX_EQ (plus_constant (Pmode, symbol, poly_int64 (9, 11)), sum1); gcc/rtl-tests.cc: rtx offset2 = gen_int_mode (poly_int64 (12, 20), Pmode); gcc/rtl-tests.cc: ASSERT_RTX_EQ (plus_constant (Pmode, sum1, poly_int64 (3, 9)), sum2); gcc/simplify-rtx.cc: rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); gcc/simplify-rtx.cc: rtx x4 = gen_int_mode (poly_int64 (5, 4), QImode); gcc/simplify-rtx.cc: rtx x5 = gen_int_mode (poly_int64 (30, 24), QImode); gcc/simplify-rtx.cc: rtx x6 = gen_int_mode (poly_int64 (20, 16), QImode); gcc/simplify-rtx.cc: rtx x7 = gen_int_mode (poly_int64 (7, 4), QImode); gcc/simplify-rtx.cc: rtx x8 = gen_int_mode (poly_int64 (30, 24), HImode); ```
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Marc Glisse --- (In reply to Andrew Pinski from comment #1) > I am 99% sure this is falls under don't do this as flatten inlines > everything it can that the function calls ... Maybe people end up abusing flatten because we are missing a convenient way for a caller to ask that a call be inlined? From the callee, we can use always_inline (couldn't this be used on name_original in this testcase?), but from the caller... Here even a non-recursive version of flatten would have helped.
[Bug testsuite/111427] [14 regression] gfortran.dg/vect/pr60510.f fails after r14-3999-g3c834d85f2ec42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427 --- Comment #3 from Vladimir Makarov --- Sorry for the inconvenience caused by the patch. I reverted this patch yesterday.
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 Andrew Pinski changed: What|Removed |Added Component|c |ipa CC||marxin at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- I am 99% sure this is falls under don't do this as flatten inlines everything it can that the function calls ...
[Bug c/111643] New: __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 Bug ID: 111643 Summary: __attribute__((flatten)) with -O1 runs out of memory (killed cc1) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lukas.gra...@tu-darmstadt.de Target Milestone: --- Created attachment 56017 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56017&action=edit C file When I run gcc -c -O0 runs_out_of_memory.i -o runs_out_of_memory.o (see the attached .i file) everything is fine. But when I run gcc -c -O1 runs_out_of_memory.i -o runs_out_of_memory.o then I get: gcc: fatal error: Killed signal terminated program cc1 Apparently, quickly runs out of memory. I have 16 GB ram and the program is rather simple. I tested it with gcc versions 9.4.0, 5.1 and 13.2 (target x86_64-linux-gnu) on ubuntu 20.04. I believe the problem is the __attribute__((flatten)) on several methods. How I created the source file: The code comes from busybox (file coreutils/expr.c) and musl header files. Additionally, I replaced every function 'name' with 'name_original' and added a wrapper with __attribute__((flatten)), for later instrumentation (I did this with a script). I used that attribute, because to reduce the overhead of the wrapper functions and I believe this should be fine. My reason why I introduced the wrappers in the first place was to allow a fine-grained instrumentation of these functions.
[Bug bootstrap/111642] New: [14 Regression] profiledbootstrap failure: poly-int.h:453:5: error: too many initializers for ‘long int [1]’ (possibly since r14-4339-geaa41a6dc127d8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Bug ID: 111642
Summary: [14 Regression] profiledbootstrap failure:
poly-int.h:453:5: error: too many initializers for
‘long int [1]’ (possibly since
r14-4339-geaa41a6dc127d8)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
I suspect r14-4339-geaa41a6dc127d8 "Remove poly_int_pod" caused checking build
failure as:
In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480,
from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
/home/slyfox/dev/git/gcc/gcc/poly-int.h: In instantiation of ‘constexpr
poly_int::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int};
unsigned int N = 1; C = long int]’:
/home/slyfox/dev/git/gcc/gcc/poly-int.h:439:13: required from here
/home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of
‘poly_int<1, long int>(1, 1)’
/home/slyfox/dev/git/gcc/gcc/poly-int.h:453:5: error: too many initializers for
‘long int [1]’
453 | : coeffs { (typename poly_coeff_traits::
| ^
454 | template init_cast::type (cs))... } {}
| ~~~
make[3]: *** [Makefile:1188: rtl-tests.o] Error 1
To reproduce:
$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc
-O1 -g0' CXX='g++ -O1 -g0'
$ make -j16 profiledbootstrap
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v
Reading specs from /tmp/gb/./prev-gcc/specs
COLLECT_GCC=/tmp/gb/./prev-gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-languages=c,c++ CC='gcc -O1 -g0' CXX='g++ -O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230929 (experimental) (GCC)
[Bug c++/111636] Wreturn-type not triggered with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111636 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Andrew Pinski --- .
[Bug libstdc++/111589] Use relaxed atomic increment (but not decrement!) in shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111589
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> The interesting question is whether all of these can be relaxed or if we
> need to stop using __atomic_add_dispatch for shared_ptr copies:
>
> include/bits/cow_string.h:
> __gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
This is basic_string::_M_add_ref_copy() which increases the refcount on a COW
string. I think this can be relaxed. We only need to synchronize with
decrements of that refcount, and any change to the existing string that causes
a decrement needs to be synchronized explicitly with the copy anyway. The
refcount increment isn't such a synchronization operation, so can be relaxed.
> include/bits/cow_string.h:
> __gnu_cxx::__atomic_add_dispatch(&_M_rep()->_M_refcount, 1);
This is the COW string move constructor when --enable-fully-dynamic-string is
used to configure libstdc++. This can be relaxed for the same reasons.
> include/bits/ios_base.h: _M_add_reference() {
> __gnu_cxx::__atomic_add_dispatch(&_M_refcount, 1); }
This is increases the refcount of callbacks in ios::copyfmt. This can be
relaxed. We only need to synchrnonize with decrements, which only happen in the
~ios destructor, which cannot be potentially concurrent with copying the ios
object.
> include/bits/locale_classes.h:{
> __gnu_cxx::__atomic_add_dispatch(&_M_refcount, 1); }
locale::facet::_M_add_reference(). Can be relaxed, because any remove_reference
call cannot happen concurrently on the same object, so doesn't need to
synchronize with the increment.
> include/bits/locale_classes.h:{
> __gnu_cxx::__atomic_add_dispatch(&_M_refcount, 1); }
locale::id::_M_add_reference(). Same again.
> include/bits/shared_ptr_base.h: {
> __gnu_cxx::__atomic_add_dispatch(&_M_use_count, 1); }
That's the subject of this PR.
> include/bits/shared_ptr_base.h: {
> __gnu_cxx::__atomic_add_dispatch(&_M_weak_count, 1); }
I think the same logic applies to this as well.
> include/ext/atomicity.h: // __atomic_add_dispatch
> include/ext/atomicity.h: __atomic_add_dispatch(_Atomic_word* __mem, int
> __val)
That's the actual function we're talking about changing.
> include/ext/pool_allocator.h: __atomic_add_dispatch(&_S_force_new,
> 1);
> include/ext/pool_allocator.h: __atomic_add_dispatch(&_S_force_new,
> -1);
This just looks like a data race, without changing anything. The getenv call
can probably be considered a synchronization point, and I don't think we need
to synchronize with other threads here anyway. We should consider an relaxed
atomic load for _S_force_new as well, to avoid the race. In any case, it can be
a relaxed inc/dec.
> include/ext/rc_string_base.h:
> __atomic_add_dispatch(&_M_info._M_refcount, 1);
Equivalent to the COW string _M_refcopy().
> include/tr1/shared_ptr.h: {
> __gnu_cxx::__atomic_add_dispatch(&_M_use_count, 1); }
> include/tr1/shared_ptr.h: {
> __gnu_cxx::__atomic_add_dispatch(&_M_weak_count, 1); }
Equivalent to std::shared_ptr and std::weak_ptr.
> libsupc++/eh_atomics.h:__gnu_cxx::__atomic_add_dispatch (__count, 1);
This looks like it needs acq_rel. We could use __exchange_and_add to get
acq_rel ordering.
> src/c++98/ios_init.cc: __gnu_cxx::__atomic_add_dispatch(&_S_refcount, 1);
I think there's a race here, independent of the ordering used for this
increment.
[Bug tree-optimization/111640] Missed optimization of Loop Unswitch (Simple loops)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111640 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- If we change the for loop to be: for (int i_0 = 0; i_0 < 4 + -1; i_0 += 1) Then it unswitches. Or just use -fwrapv which makes the undefined code to become defined.
[Bug tree-optimization/111640] Missed optimization of Loop Unswitch (Simple loops)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111640 --- Comment #1 from Andrew Pinski --- Induction variable (int) var_45_lsm.67_240 + -2147483643 + -2147483643 * iteration does not wrap in statement _153 = var_45_lsm.67_226 + -2147483643; in loop 1. Statement _153 = var_45_lsm.67_226 + -2147483643; is executed at most 1 (bounded by 1) + 1 times in loop 1. Reducing loop iteration estimate by 1; undefined statement must be executed at the last iteration. /app/example.cpp:20:27: note: Not unswitching, loop is not expected to iterate So
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #1 from Jonathan Wakely --- This fails the same way on 32-bit arm. Presumably some difference in libbacktrace support.
[Bug libstdc++/110900] std::string initializes SSO object subfield without making the SSO object active in the union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.4 --- Comment #8 from Jonathan Wakely --- This should be fixed on trunk now by r14-4334-g28adad7a32ed92 That needs to be backported too.
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a8b9c32da787ea0bfbfc9118ac816fa7be4b1bc8 commit r14-4335-ga8b9c32da787ea0bfbfc9118ac816fa7be4b1bc8 Author: Dimitrij Mijoski Date: Thu Sep 28 21:38:11 2023 +0200 libstdc++: Fix handling of surrogate CP in codecvt [PR108976] This patch fixes the handling of surrogate code points in all standard facets for transcoding Unicode that are based on std::codecvt. Surrogate code points should always be treated as error. On the other hand surrogate code units can only appear in UTF-16 and only when they come in a proper pair. Additionally, it fixes a bug in std::codecvt_utf16::in() when odd number of bytes were given in the range [from, from_end), error was returned always. The last byte in such range does not form a full UTF-16 code unit and we can not make any decisions for error, instead partial should be returned. The testsuite for testing these facets was updated in the following order: 1. All functions that test codecvts that work with UTF-8 were refactored and made more generic so they accept codecvt that works with the char type char8_t. 2. The same functions were updated with new test cases for transcoding errors and now additionally test for surrogates, overlong UTF-8 sequences, code points out of the Unicode range, and more tests for missing leading and trailing code units. 3. New tests were added to test codecvt_utf16 in both of its variants, UTF-16 <-> UTF-32/UCS-4 and UTF-16 <-> UCS-2. libstdc++-v3/ChangeLog: PR libstdc++/108976 * src/c++11/codecvt.cc (read_utf8_code_point): Fix handing of surrogates in UTF-8. (ucs4_out): Fix handling of surrogates in UCS-4 -> UTF-8. (ucs4_in): Fix handling of range with odd number of bytes. (ucs4_out): Fix handling of surrogates in UCS-4 -> UTF-16. (ucs2_out): Fix handling of surrogates in UCS-2 -> UTF-16. (ucs2_in): Fix handling of range with odd number of bytes. (__codecvt_utf16_base::do_in): Likewise. (__codecvt_utf16_base::do_in): Likewise. (__codecvt_utf16_base::do_in): Likewise. * testsuite/22_locale/codecvt/codecvt_unicode.cc: Renames, add tests for codecvt_utf16 and codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_unicode.h: Refactor UTF-8 testing functions for char8_t, add more test cases for errors, add testing functions for codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_unicode_wchar_t.cc: Renames, add tests for codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_utf16/79980.cc (test06): Fix test. * testsuite/22_locale/codecvt/codecvt_unicode_char8_t.cc: New test.
[Bug libstdc++/111641] New: FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 Bug ID: 111641 Summary: FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-linux* Target: hppa*-*-linux* Build: hppa*-*-linux* Executing on host: /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home/d ave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/ libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.li bs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/ho me/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-14/h ppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/sys-include -fchecking=1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fmessage-le ngth=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc+ +-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++ -v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc -std=gnu++23 -lstdc++exp -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/filesystem/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/experimental/.libs -lm -o ./current.exe(timeout = 360) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-14/hppa-linux-gnu/sys-include -fchecking=1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc -std=gnu++23 -lstdc++exp -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/filesystem/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/experimental/.libs -lm -o ./current.exe PASS: 19_diagnostics/stacktrace/current.cc -std=gnu++23 (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc Execution timeout is: 300 spawn [open ...] /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc:52: test_max_depth(): Assertion '! t.empty()' failed. FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test extra_tool_flags are: -std=gnu++26 -lstdc++exp Similar fails: FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test FAIL: 19_diagnostic
[Bug middle-end/111637] ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637 --- Comment #1 from Jakub Jelinek --- Untested fix in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625#c2
[Bug middle-end/111625] valgrind error with ./gcc.dg/bitint-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625 --- Comment #2 from Jakub Jelinek --- Created attachment 56016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56016&action=edit gcc14-pr111625.patch Untested fix.
[Bug tree-optimization/111640] New: Missed optimization of Loop Unswitch (Simple loops)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111640
Bug ID: 111640
Summary: Missed optimization of Loop Unswitch (Simple loops)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
Target Milestone: ---
Hello, we found some optimizations (regarding Loop Unswitch) that GCC may have
missed.
The control flow graph for this code is simple. At the same time, even with
--param max-unswitch-insns, this code will not optimize as expected.
We would greatly appreicate if you can take a look and let us know you think.
https://godbolt.org/z/M3b61qqno
Given the following code:
extern int var_8;
extern int var_9;
extern int var_10;
extern int var_11;
extern int var_12;
extern int var_15;
extern int var_17;
extern int var_18;
extern int var_22;
extern int var_25;
extern int var_26;
extern int var_27;
extern int var_30;
extern int var_34;
extern int var_37;
extern int var_39;
extern int var_45;
void test(int var_0, int var_1, int var_2, int var_3, int var_4) {
for (int i_0 = 0; i_0 < 4 + -1986643035 + 1 - 1 + 1986643054; i_0 += var_3
- var_1 - var_3 - var_10 + var_10 + -636989219 + var_2 - 691490232 -
1995983094)
{
var_11 += 691490244 + 1118573265 - 1740428269 - -15 + var_1 - var_1 +
var_3 - var_1;
var_12 += var_2 - var_9 + var_4 - var_2 + 1349088205;
var_2 += 691490244 - var_2 + var_9 - var_4 + 524287 + var_0 - 130944 +
var_8;
var_2 += var_1 - var_2 + -1278891492 + var_0 + var_10 / var_2 -
1060987095 / var_10;
if (var_4)
{
var_15 += var_3 + var_2 + var_12 - var_10 + var_4 - var_10 + var_2
+ var_0;
var_0 += -1 - -2147483648 + -1106137664 + 653639923 + 299331679;
var_17 += 691490241 + var_2 + var_4 - 1 + -691490244;
var_18 += 7;
}
var_0 += var_2 + var_2 + var_17 - var_11 + 908521917 + 691490232 +
var_18 + var_2;
var_3 += -2147483627 - var_15 + var_4 - -4 - 1026228299;
var_3 += 524287 + var_2 - var_1 - var_12 - var_15;
var_22 += var_0 << -1630330270 + 1630330281 - 11 + -691490226 + var_2 -
917504 - var_2 + var_1 + var_0;
var_0 += var_22 - var_11 + var_2 + var_0 + var_17 + var_2 - var_3 -
var_10;
var_3 += -2147483644 + 1859189279 + var_10 + var_3 + var_10 - var_4 +
var_12 - -2147483648;
var_25 += var_3 / var_0 / var_10 / var_9 * 28 / var_0 / var_8 / var_3;
var_26 += var_4 - 416142146 - -754359525 + 2147483647 - 691490244 +
var_8 + 359765153 + var_1;
var_27 += var_4 ^ 66977792 | -1275910637 & 543545229 - -524287 + var_0
+ var_2 + var_4;
var_0 += var_4 | var_15 & var_0 | 12 | 13 ^ var_2 ^ var_2 & var_10;
var_1 += 524287 + var_2 + 2147483632 + var_2 + 75252783 + 1 -
587589943;
var_30 += 383955870 - var_4 - -1693411264 + var_0 + var_3 + var_0 -
var_3 + var_0;
var_1 += -524267 + 65535 + var_9 + var_0 - var_2 - var_4;
var_0 += 142220097 + var_3 - var_1 - var_4 + 2147483632 - var_18 -
var_4;
var_3 += -691490232;
var_2 += -307713567 & var_1 ^ var_4 - var_2 + -691490245 + 24 + var_25;
var_3 += var_4 + 983040 - var_0 - var_17 + var_1 - 68189835 + var_25 +
var_0;
var_45 += -2147483643;
}
}
Because `var_4` is a loop invariant so we can hoist the if condition out of the
loop, but gcc-trunk -O3 dose not (main parts):
.L5:
mov DWORD PTR [rsp-56], eax
.L3:
...
cmp r8d, -1099697352
je .L2
...
.L2:
...
jle .L5
...
Thank you very much for your time and effort! We look forward to hearing from
you.
[Bug middle-end/111637] ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-09-29
[Bug middle-end/111625] valgrind error with ./gcc.dg/bitint-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625 Jakub Jelinek changed: What|Removed |Added Version|unknown |14.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-09-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |14.0
[Bug target/111522] Different code path for static initialization with flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111522
--- Comment #11 from Mathieu Malaterre ---
Here is a dead simple reduced version:
```
% cat pr111522.cc
#include
#include
#pragma GCC push_options
#pragma GCC target "cpu=power10"
float BitCast(int in) {
float out;
memcpy(&out, &in, sizeof(out));
return out;
}
float kNearOneF = BitCast(1065353215);
#pragma GCC pop_options
int main() { std::cout << kNearOneF << std::endl; }
```
You can compare:
g++ -o works -O2 pr111522.cc -Wall -Wextra -Werror -Wfatal-errors
vs
g++ -o fails -flto -O2 pr111522.cc -Wall -Wextra -Werror -Wfatal-errors
For some reason, `-flto` rightfully generates a `xxspltidp` instruction:
(gdb) display/i $pc
1: x/i $pc
=> 0x10940 <_Z7BitCasti.constprop.0>: xxspltidp vs1,1065353215
I am not sure I understand the behavior of the non LTO case now...
[Bug libstdc++/111639] HAVE_ACOSF etc. are wrong on avr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Blocks||79700
Last reconfirmed||2023-09-29
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
This blocks the fix for PR 79700 because of these lying macros.
The crossconfig.m4 changes were made in 2016 by
g:6649ad7efdd583d84099beb5ee2b03a0ed28b9ee purportedly to fix duplicate
definitions in math_stubs_float.cc, e.g.
In file included from
/home/jwakely/src/gcc/build-avr/gcc-obj/avr/libstdc++-v3/include/cmath:47,
from
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++98/math_stubs_float.cc:25:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++98/math_stubs_float.cc:35:3:
error: conflicting declaration of C function 'float fabs(float)'
35 | fabsf(float x)
| ^
/usr/avr/include/math.h:146:15: note: previous declaration 'double
fabs(double)'
146 | extern double fabs(double __x) __ATTR_CONST__;
| ^~~~
But these are caused by the macros in avr , which mean that we end up
defining another fabs instead of the intended fabsf.
I think the correct fix is to remove the crossconfig.m4 changes and do this
instead:
--- a/libstdc++-v3/src/c++98/math_stubs_float.cc
+++ b/libstdc++-v3/src/c++98/math_stubs_float.cc
@@ -31,6 +31,7 @@
extern "C"
{
#ifndef _GLIBCXX_HAVE_FABSF
+#undef fabsf
float
fabsf(float x)
{
And similarly for the other functions in that file.
If defining those functions bloats libstdc++ too much for avr, then we can
consider defining the float and long double stubs as aliases of each other
(since float, double and long double all seem to be the same size on avr).
We could even define them inline in headers, instead of in the lib:
extern "C" inline float fabs(float __x) { return fabs((double)__x); }
But the first priority should be to remove the bogus HAVE_FABSF definitions in
crossconfig.m4
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
[Bug 79700] std::fabsf and std::fabsl missing from
[Bug libstdc++/111639] New: HAVE_ACOSF etc. are wrong on avr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639 Bug ID: 111639 Summary: HAVE_ACOSF etc. are wrong on avr Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Target: avr The in avr-libc does things like this: extern double acos(double __x) __ATTR_CONST__; #define acosf acos/**< The alias for acos(). */ and then crossconfig.m4 does: avr*-*-*) AC_DEFINE(HAVE_ACOSF) AC_DEFINE(HAVE_ASINF) AC_DEFINE(HAVE_ATAN2F) AC_DEFINE(HAVE_ATANF) AC_DEFINE(HAVE_CEILF) AC_DEFINE(HAVE_COSF) AC_DEFINE(HAVE_COSHF) AC_DEFINE(HAVE_EXPF) AC_DEFINE(HAVE_FABSF) AC_DEFINE(HAVE_FLOORF) AC_DEFINE(HAVE_FMODF) AC_DEFINE(HAVE_FREXPF) AC_DEFINE(HAVE_SQRTF) AC_DEFINE(HAVE_HYPOTF) AC_DEFINE(HAVE_LDEXPF) AC_DEFINE(HAVE_LOG10F) AC_DEFINE(HAVE_LOGF) AC_DEFINE(HAVE_MODFF) AC_DEFINE(HAVE_POWF) AC_DEFINE(HAVE_SINF) AC_DEFINE(HAVE_SINHF) AC_DEFINE(HAVE_TANF) AC_DEFINE(HAVE_TANHF) ;; But this doesn't work, because has to #undef all math function names, so we #undef the acosf macro and then the HAVE_ACOSF macro is left defined but is now lying.
[Bug libstdc++/111638] New: GLIBCXX_MAYBE_UNDERSCORED_FUNCS autoconf macro doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111638
Bug ID: 111638
Summary: GLIBCXX_MAYBE_UNDERSCORED_FUNCS autoconf macro doesn't
work
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In linkage.m4 we have:
dnl
dnl Define autoheader template for using the underscore functions
dnl For each parameter, create a macro where if func doesn't exist,
dnl but _func does, then it will "#define func _func".
dnl
dnl GLIBCXX_MAYBE_UNDERSCORED_FUNCS
AC_DEFUN([GLIBCXX_MAYBE_UNDERSCORED_FUNCS],
[AC_FOREACH([glibcxx_ufunc], [$1],
[AH_VERBATIM(_[]glibcxx_ufunc,
[#if defined (]AS_TR_CPP(HAVE__[]glibcxx_ufunc)[) && ! defined
(]AS_TR_CPP(HAVE_[]glibcxx_ufunc)[)
# define ]AS_TR_CPP(HAVE_[]glibcxx_ufunc)[ 1
# define ]glibcxx_ufunc[ _]glibcxx_ufunc[
#endif])])
])
dnl
dnl Check to see if the (math function) argument passed is
dnl 1) declared when using the c++ compiler
dnl 2) has "C" linkage
dnl 3) if not, see if 1) and 2) for argument prepended with '_'
dnl
dnl Define HAVE_CARGF etc if "cargf" is declared and links
dnl
dnl argument 1 is name of function to check
dnl
dnl ASSUMES argument is a math function with ONE parameter
dnl
dnl GLIBCXX_CHECK_MATH_DECL_AND_LINKAGE_1
AC_DEFUN([GLIBCXX_CHECK_MATH_DECL_AND_LINKAGE_1], [
GLIBCXX_CHECK_MATH_DECL_1($1)
if test x$glibcxx_cv_func_$1_use = x"yes"; then
AC_CHECK_FUNCS($1)
else
GLIBCXX_CHECK_MATH_DECL_1(_$1)
if test x$glibcxx_cv_func__$1_use = x"yes"; then
AC_CHECK_FUNCS(_$1)
fi
fi
GLIBCXX_MAYBE_UNDERSCORED_FUNCS($1)
])
Which results in output like this in c++config.h
#if defined (_GLIBCXX_HAVE__ACOSF) && ! defined (_GLIBCXX_HAVE_ACOSF)
# define _GLIBCXX_HAVE_ACOSF 1
# define acosf _acosf
#endif
But this is completely incompatible with the logic in .
For a target where _acosf is present, c++config.h will do:
# define _GLIBCXX_HAVE_ACOSF 1
# define acosf _acosf
Then will do something like:
#undef acosf
#ifdef _GLIBCXX_HAVE_ACOSF
using ::acosf;
#endif
So HAVE_ACOSF is defined, but the using-declaration will fail, because acosf
was actually just a macro for _acosf which has been undefined.
If the macros in linkage.m4 still have any value, we would need to output
something like this to c++config.h:
#if defined (_GLIBCXX_HAVE__ACOSF) && ! defined (_GLIBCXX_HAVE_ACOSF)
# define _GLIBCXX_HAVE_ACOSF 1
inline __decltype(_acosf(0)) acosf(__decltype(_acosf(0)) __x) { return
::_acosf(__x); }
#endif
That would define a real function that can refer to.
But maybe we should just remove it all.
The #define acosf _acosf stuff was added in 2000 by
g:54fa741538eaf41ed84093cc5245f41119a8e969 so maybe it's no longer even needed.
[Bug fortran/37336] [F03] Finish derived-type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #35 from CVS Commits --- The releases/gcc-13 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:d9b3269bdccac2db9200303494c4e82f2aeb7bbc commit r13-7923-gd9b3269bdccac2db9200303494c4e82f2aeb7bbc Author: Andre Vehreschild Date: Thu Sep 28 09:30:12 2023 +0200 Fortran: Free alloc. comp. in allocated coarrays only. When freeing allocatable components of an allocatable coarray, add a check that the coarray is still allocated, before accessing the components. This patch adds to PR fortran/37336, but does not fix it completely. gcc/fortran/ChangeLog: PR fortran/37336 * trans-array.cc (structure_alloc_comps): Deref coarray. (gfc_trans_deferred_array): Add freeing of components after check for allocated coarray. gcc/testsuite/ChangeLog: PR fortran/37336 * gfortran.dg/coarray/alloc_comp_6.f90: New test. * gfortran.dg/coarray/alloc_comp_7.f90: New test. (cherry picked from commit 9a63a62dfd73e159f1956e9b04b555c445de4e78)
[Bug fortran/37336] [F03] Finish derived-type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #34 from CVS Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:a680274616ec6b26ccfdcee400ed7f54e341d40c commit r14-4331-ga680274616ec6b26ccfdcee400ed7f54e341d40c Author: Andre Vehreschild Date: Thu Sep 28 09:30:12 2023 +0200 Fortran: Free alloc. comp. in allocated coarrays only. When freeing allocatable components of an allocatable coarray, add a check that the coarray is still allocated, before accessing the components. This patch adds to PR fortran/37336, but does not fix it completely. gcc/fortran/ChangeLog: PR fortran/37336 * trans-array.cc (structure_alloc_comps): Deref coarray. (gfc_trans_deferred_array): Add freeing of components after check for allocated coarray. gcc/testsuite/ChangeLog: PR fortran/37336 * gfortran.dg/coarray/alloc_comp_6.f90: New test. * gfortran.dg/coarray/alloc_comp_7.f90: New test.
[Bug tree-optimization/111131] SLP of gathers incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31
--- Comment #1 from Richard Biener ---
There's also
if (memory_access_type == VMAT_GATHER_SCATTER && gs_info.decl)
{
vect_build_gather_load_calls (vinfo, stmt_info, gsi, vec_stmt, &gs_info,
mask, cost_vec);
return true;
which doesn't support SLP either (but ICEs).
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 Wilco changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Wilco --- Fixed on trunk, backported to GCC13 and GCC12.
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:bc1e385488001b0bd1a9b9c55b09ce987c31d353 commit r12-9898-gbc1e385488001b0bd1a9b9c55b09ce987c31d353 Author: Wilco Dijkstra Date: Tue Sep 26 16:42:45 2023 +0100 AArch64: Fix memmove operand corruption [PR21] A MOPS memmove may corrupt registers since there is no copy of the input operands to temporary registers. Fix this by calling aarch64_expand_cpymem_mops. Reviewed-by: Richard Sandiford gcc/ChangeLog/ PR target/21 * config/aarch64/aarch64.md (aarch64_movmemdi): Add new expander. (movmemdi): Call aarch64_expand_cpymem_mops for correct expansion. * config/aarch64/aarch64.cc (aarch64_expand_cpymem_mops): Add support for memmove. * config/aarch64/aarch64-protos.h (aarch64_expand_cpymem_mops): Add new function. gcc/testsuite/ChangeLog/ PR target/21 * gcc.target/aarch64/mops_4.c: Add memmove testcases. (cherry picked from commit d8b56c95782a79ec40932ca88d00fd9f2ee2)
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:c534a9b198caa3807bcc592a3c5bac3f971417f7 commit r13-7921-gc534a9b198caa3807bcc592a3c5bac3f971417f7 Author: Wilco Dijkstra Date: Tue Sep 26 16:42:45 2023 +0100 AArch64: Fix memmove operand corruption [PR21] A MOPS memmove may corrupt registers since there is no copy of the input operands to temporary registers. Fix this by calling aarch64_expand_cpymem_mops. Reviewed-by: Richard Sandiford gcc/ChangeLog/ PR target/21 * config/aarch64/aarch64.md (aarch64_movmemdi): Add new expander. (movmemdi): Call aarch64_expand_cpymem_mops for correct expansion. * config/aarch64/aarch64.cc (aarch64_expand_cpymem_mops): Add support for memmove. * config/aarch64/aarch64-protos.h (aarch64_expand_cpymem_mops): Add new function. gcc/testsuite/ChangeLog/ PR target/21 * gcc.target/aarch64/mops_4.c: Add memmove testcases. (cherry picked from commit d8b56c95782a79ec40932ca88d00fd9f2ee2)
[Bug c++/111636] Wreturn-type not triggered with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111636 KL changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from KL --- You are right, the warning appears and, my bad, it is not a gcc issue, more a clangd one. Sorry for the bandwidth, cheers
[Bug c++/110158] Cannot use union with std::string inside in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158 --- Comment #7 from Jonathan Wakely --- That bug in comment 6 has already been fixed in gcc-12.3, by the last patch for PR 103295. The one in comment 4 is different, and will be fixed by Nathaniel's latest patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631642.html
[Bug libstdc++/110900] std::string initializes SSO object subfield without making the SSO object active in the union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900 Jonathan Wakely changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW --- Comment #7 from Jonathan Wakely --- I don't think this is a duplicate. This is just a libstdc++ bug, which we have a patch for.
[Bug middle-end/111637] New: ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637 Bug ID: 111637 Summary: ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz CC: jakub at gcc dot gnu.org, jamborm at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Compiling the bitint-8.c testsuite file with optimizations enabled and -fsanitize=signed-integer-overflow results in an ICE gcc $GCC_SRC_DIR/gcc/testsuite/gcc.dg/bitint-8.c -O1 -fsanitize=signed-integer-overflow during GIMPLE pass: bitintlower bitint-8.c: In function ‘foo’: bitint-8.c:7:1: internal compiler error: in lower_bound, at value-range.h:1078 7 | foo (void) | ^~~ 0x8c59fe irange::lower_bound(unsigned int) const ../../src/gcc/value-range.h:1078 0x8c59fe range_to_prec ../../src/gcc/gimple-lower-bitint.cc:1945 0x1cd0645 lower_addsub_overflow ../../src/gcc/gimple-lower-bitint.cc:3768 0x1cd27f3 lower_call ../../src/gcc/gimple-lower-bitint.cc:4469 0x1cd9a4a lower_stmt ../../src/gcc/gimple-lower-bitint.cc:4673 0x1cda8cd gimple_lower_bitint ../../src/gcc/gimple-lower-bitint.cc:5765
[Bug tree-optimization/111583] [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3281-g6cc3394507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111583 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/111583] [13 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3281-g6cc3394507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111583 Richard Biener changed: What|Removed |Added Summary|[13/14 Regression] Wrong|[13 Regression] Wrong code |code at -Os on |at -Os on x86_64-linux-gnu |x86_64-linux-gnu since |since r13-3281-g6cc3394507 |r13-3281-g6cc3394507| Known to fail||13.2.0 Known to work||14.0 --- Comment #5 from Richard Biener --- Fixed on trunk. The issue is latent for longer but at least pre-ranger we probably were not good enough to extract range info from this.
[Bug tree-optimization/111583] [13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3281-g6cc3394507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111583 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:962ca7149d652e4077a2259886e5cd2ea3cea0ab commit r14-4329-g962ca7149d652e4077a2259886e5cd2ea3cea0ab Author: Richard Biener Date: Fri Sep 29 11:08:18 2023 +0200 tree-optimization/111583 - loop distribution issue The following conservatively fixes loop distribution to only recognize memset/memcpy and friends when at least one element is going to be processed. This avoids having an unconditional builtin call in the IL that might imply the source and destination pointers are non-NULL when originally pointers were not always dereferenced. With -Os loop header copying is less likely to ensure this. PR tree-optimization/111583 * tree-loop-distribution.cc (find_single_drs): Ensure the load/store are always executed. * gcc.dg/tree-ssa/pr111583-1.c: New testcase. * gcc.dg/tree-ssa/pr111583-2.c: Likewise.
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 111505, which changed state. Bug 111505 Summary: [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/111505] [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Sergei Trofimovich --- I can confirm --with-build-config=bootstrap-asan fails the same way before the fix and passes successfully after the fix. Let's declare it FIXED.
[Bug c++/111636] Wreturn-type not triggered with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111636 --- Comment #2 from Jonathan Wakely --- Which suggests you can't have undefined behaviour at runtime that didn't have a warning, because you can't run the code without instantiating it. Do you have a complete example that have undefined behaviour at runtime and doesn't warn?
[Bug middle-end/111505] [14 Regression] Asan (address-sanitizer) bootstrap fails since r14-4003-geaa8e8541349df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111505 --- Comment #6 from CVS Commits --- The master branch has been updated by Sergei Trofimovich : https://gcc.gnu.org/g:7525707c5f3edb46958c4fdfbe30de5ddfa8923a commit r14-4327-g7525707c5f3edb46958c4fdfbe30de5ddfa8923a Author: Sergei Trofimovich Date: Thu Sep 28 20:20:31 2023 +0100 ggc: do not wipe out unrelated data via gt_ggc_rtab [PR111505] There are 3 GC root tables: gt_ggc_rtab gt_ggc_deletable_rtab gt_pch_scalar_rtab `deletable` and `scalar` tables are both simple: each element always contains a pointer to the beginning of the object and it's size is the full object. `rtab` is different: it's `base` is a pointer in the middle of the struct and `stride` points to the next GC pointer in the array. Before the change there were 2 problems: 1. We memset()ed not just pointers but data around them. 2. We wen out of bounds of the last object described by gt_ggc_rtab and triggered bootstrap failures in profile and asan bootstraps. After the change we handle only pointers themselves like the rest of ggc-common.cc code. gcc/ PR middle-end/111505 * ggc-common.cc (ggc_zero_out_root_pointers, ggc_common_finalize): Add new helper. Use helper instead of memset() to wipe out pointers.
[Bug tree-optimization/111583] [13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r13-3281-g6cc3394507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111583 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- A conservative fix would be to make sure the memory accesses for the memset/memcpy recognition are before the loop exit. Note since -Os disables loop header copying in most cases this will remove quite a bit of memset/memcpy loop detection there. The alternative would be to guard the calls.
[Bug c++/111636] Wreturn-type not triggered with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111636 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Except it will warn at instantiation time. : In instantiation of 'std::vector > check_values(T&&) [with T = int&]': :32:21: required from here :28:1: warning: no return statement in function returning non-void [-Wreturn-type] 28 | } | ^
[Bug middle-end/111632] gcc's C++ components fail to compile against recent libc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #3 from Dimitry Andric --- (In reply to Richard Biener from comment #2) > the patch looks reasonable, please post it to gcc-patc...@gcc.gnu.org https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html
[Bug c++/111636] New: Wreturn-type not triggered with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111636
Bug ID: 111636
Summary: Wreturn-type not triggered with exceptions
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deco33000 at yandex dot com
Target Milestone: ---
Hi,
In some cases, gcc won't trigger a warning for non returning a value in a non
void function.
Godbolt:
https://godbolt.org/z/dzfsTnssr
I simplified the code, to expose the logic of the issue.
---
// Type your code here, or load an example.
#include
#include
#include
enum Example {
TRY_THIS,
OR_THAT
};
template
auto check_values(auto &&type) -> std::vector {
std::vector accepted;
if constexpr (std::is_same_v) {
if (type != TRY_THIS) {
throw std::runtime_error("error");
}
accepted.emplace_back("1");
} else if constexpr (std::is_same_v) {
accepted.emplace_back("2");
} else if constexpr (std::is_same_v) {
accepted.emplace_back("3");
}
// return accepted_mimes;
}
once you comment
if (type != TRY_THIS) {
throw std::runtime_error("error");
}
it properly warns.
It is confusing/dangerous because it means that one can put an exception in the
code and have undefined behavior at runtime (happened to me this morning),
whereas the compiler should have caught the issue at compile time.
Thanks
[Bug middle-end/111632] gcc's C++ components fail to compile against recent libc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #2 from Richard Biener --- the patch looks reasonable, please post it to gcc-patc...@gcc.gnu.org
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643
--- Comment #15 from Andrew Pinski ---
Well the cvise reduced testcase is undefined code:
template
__tuple_element_t<__i, tuple<_Elements...>> get(tuple<_Elements...>) {
double __trans_tmp_23{};
double *__trans_tmp_21 = &__trans_tmp_23;
return __trans_tmp_21;
}
That returns a address to a local variable ...
Which is why you get this warning:
```
: In function 'void hwy::AssertVecEqual(Vec >)':
:174:45: warning: '__trans_tmp_23' is used uninitialized
[-Wuninitialized]
174 | __trans_tmp_20 = *actual_lanes.get();
| ^
:42:10: note: '__trans_tmp_23' was declared here
42 | double __trans_tmp_23{};
| ^~
```
