[Bug testsuite/116080] [15 regression] New tests from r15-2233-g8d1af8f904a0c0 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #18 from Christophe Lyon ---
Sorry, no, this is not the cause of the problem (actually musttail7.c also
fails in gcc.log).
I looked into this, and it's a bit tricky
in arm_function_ok_for_sibcall() (from arm.cc), we have:
/* If we are interworking and the function is not declared static
then we can't tail-call it unless we know that it exists in this
compilation unit (since it might be a Thumb routine). */
if (TARGET_INTERWORK && decl && TREE_PUBLIC (decl)
&& !TREE_ASM_WRITTEN (decl))
return false;
In this specific case, we have TARGET_INTERWORK==true because we default to
armv4t. In the other configurations we test, TARGET_INTERWORK==false because we
use newer architecture versions.
So the testcase emits an error because TREE_ASM_WRITTEN (decl) == false for
f2() since it is recursive.
Is musttail7.c specifically about testing recursive calls?
As a workaround, I suggest to remove {} from foo's definition, such that it is
TREE_PUBLIC, but TREE_ASM_WRITTEN is false.
AFAICS, this is already what we have in
check_effective_target_external_musttail and
check_effective_target_struct_musttail.
[Bug testsuite/116080] [15 regression] New tests from r15-2233-g8d1af8f904a0c0 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #15 from Christophe Lyon ---
(In reply to andi from comment #14)
> The test relies on the
>
> gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
Are you sure?
musttail7.c has:
/* { dg-do compile { target { musttail && { c || c++11 } } } } */
(so "musttail" and not "tail_call")
>
> probe matching what the test does. Perhaps the way you are passing options
> doesn't pass them to the TCL based test code? The probe should be in the
> logs,
> perhaps you can find that or upload them somewhere.
My log has:
spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++
musttail19057.c -fdiagnostics-plain-output -nostdinc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util
-fmessage-length=0 -fdump-rtl-expand-all -Wno-complain-wrong-lang
-fdump-rtl-expand -S -o musttail19057.s
(with no error)
but for the actual testcase:
spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/c-c++-common/musttail7.c
-fdiagnostics-plain-output -nostdinc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward
-I/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++11 -S -o musttail7.s
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/c-c++-common/musttail7.c:
In function 'void f2()':
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/c-c++-common/musttail7.c:8:30:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
[Bug tree-optimization/116901] New: pr110625_4.c fails on aarch64 since r15-3794-g2c04f175de4f39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901 Bug ID: 116901 Summary: pr110625_4.c fails on aarch64 since r15-3794-g2c04f175de4f39 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: aarch64 Since r15-3794-g2c04f175de4f39, we noticed this regression on aarch64: FAIL: gcc.target/aarch64/pr110625_4.c scan-tree-dump-not vect "LOOP VECTORIZED"
[Bug testsuite/116080] [15 regression] New tests from r15-2233-g8d1af8f904a0c0 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080 Christophe Lyon changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||clyon at gcc dot gnu.org --- Comment #13 from Christophe Lyon --- As of r15-3812-g4700ad1c78ccd7, musttail7.c still fails on arm-eabi with default configuration / test flags: FAIL: c-c++-common/musttail7.c -std=c++11 (test for excess errors) Excess errors: /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/c-c++-common/musttail7.c:8:30: error: cannot tail-call: target is not able to optimize the call into a sibling call Note that it passes on arm-eabi when forcing some configuration flags / test flags, for instance: - OK with qemu/-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp - OK with qemu/-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto so maybe the problem is just related to the default (armv4t IIRC) not being handled correctly.
[Bug tree-optimization/116818] New: gcc.target/aarch64/sve/strided_load_5.c fails since gcc-15-3735-g664e0ce580a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116818 Bug ID: 116818 Summary: gcc.target/aarch64/sve/strided_load_5.c fails since gcc-15-3735-g664e0ce580a8 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: aarch64 Since commit gcc-15-3735-g664e0ce580a8, we have noticed failures in gcc.target/aarch64/sve/strided_load_5.c: PASS: gcc.target/aarch64/sve/strided_load_5.c (test for excess errors) gcc.target/aarch64/sve/strided_load_5.c: \\tld1w\\tz[0-9]+\\.s, p[0-7]/z, \\[x[0-9]+, z[0-9]+.s, uxtw\\]\\n found 6 times FAIL: gcc.target/aarch64/sve/strided_load_5.c scan-assembler-times \\tld1w\\tz[0-9]+\\.s, p[0-7]/z, \\[x[0-9]+, z[0-9]+.s, uxtw\\]\\n 12 PASS: gcc.target/aarch64/sve/strided_load_5.c scan-assembler-times \\tld1w\\tz[0-9]+\\.s, p[0-7]/z, \\[x[0-9]+, z[0-9]+.s, sxtw\\]\\n 3 gcc.target/aarch64/sve/strided_load_5.c: \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+.d\\]\\n found 3 times FAIL: gcc.target/aarch64/sve/strided_load_5.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+.d\\]\\n 15
[Bug other/116260] testsuite-management/validate_failures.py: split multilib ABIs in results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116260 --- Comment #3 from Christophe Lyon --- Thanks for the additional information, indeed in our CI we do not run validations for several "variations", so it's not surprising this case is not handled very well. So you suggest having one manifest per variation, and calling validate_failures.py --manifest manifest.var1 --build_dir xxx --variation var1 etc ?
[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test with the rust fe (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ()))) since r15-159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #15 from Christophe Lyon --- Fixed
[Bug target/115643] [15 regression] aarch64-w64-mingw32 support today breaks x86_64-w64-mingw32 build cannot represent relocation type BFD_RELOC_64 since r15-1602-ged20feebd9ea31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED CC||clyon at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #23 from Christophe Lyon --- Fixed
[Bug bootstrap/115635] [15 regression] Bootstrap fails with failed self-test with the rust fe (diagnostic-path.cc:1153: test_empty_path: FAIL: ASSERT_FALSE ((path.interprocedural_p ()))) since r15-159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Bug 115635 depends on bug 115661, which changed state.
Bug 115661 Summary: [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu
since r15-1599-g63512c72df09b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
[Bug target/115661] [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r15-1599-g63512c72df09b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Christophe Lyon --- Fixed.
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #16 from Christophe Lyon --- (In reply to Richard Biener from comment #15) > OK, looking the fix was only half complete. Can you try It works with this, thanks!
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #14 from Christophe Lyon --- Created attachment 58522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58522&action=edit Wrong code after r15-1392
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #13 from Christophe Lyon --- Yes it breaks at the same point, again we are returning an uninitialized value. Adding annotate asm
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #11 from Christophe Lyon --- Created attachment 58520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58520&action=edit vect dump broken after r15-1392
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 Christophe Lyon changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Christophe Lyon --- The test is still failing on our side. Attaching the new vect traces, hopefully that will be enough for you?
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- Linaro CI and Intel CI have reported failures of the new tests: https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080080.html https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080078.html (Linaro precommit CI also reported the problem before the patch was committed BTW)
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #5 from Christophe Lyon ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*). (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with-float=hard is not
sufficient).
You can't build an arm-linux-* toolchain for cortex-M.
So I suggest you build your toolchain with the flags I suggested in the
description:
with GCC configured with:
--disable-multilib --with-mode=thumb --with-arch=armv8.1-m.main+mve.fp+fp.dp
--with-float=hard --target=arm-eabi
It shouldn't be very long since multilibs are disabled.
Alternatively, you can try to use our ABE build script:
git clone https://git.linaro.org/toolchain/abe.git
cd abe
./configure
./abe.sh --build all --target arm-eabi --extraconfigdir config/master --disable
make_docs --set languages=c,c++,lto --set
gcc_override_configure=--disable-multilib --set
gcc_override_configure=--with-mode=thumb --set
gcc_override_configure=--with-arch=armv8.1-m.main+mve.fp+fp.dp --set
gcc_override_configure=--with-float=hard --check gcc --set
'target_board_options={-mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto}'
--qemu-cpu cortex-m55 --set runtestflags=execute.exp=pr94734.c
That will clone all repos (binutils-gdb, gcc, newlib, qemu), build the full
toolchain from scratch, and run the test.
[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #2 from Christophe Lyon --- Created attachment 58431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58431&action=edit vect dump OK
[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #3 from Christophe Lyon --- Created attachment 58432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58432&action=edit vect dump broken
[Bug target/115493] New: gcc.c-torture/execute/pr94734.c fails on MVE after gcc-15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 Bug ID: 115493 Summary: gcc.c-torture/execute/pr94734.c fails on MVE after gcc-15-1054-g202a9c8fe7d Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Created attachment 58428 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58428&action=edit Code generated before the offending GCC commit (works) As reported in https://linaro.atlassian.net/browse/GNU-1255, we are seeing FAIL: gcc.c-torture/execute/pr94734.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gcc.c-torture/execute/pr94734.c -O3 -g execution test after g:202a9c8fe7d with GCC configured with: --disable-multilib --with-mode=thumb --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard --target=arm-eabi and the testsuite executed with: qemu/-mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto I'm attaching the annotated generated asm, the offending code is when calling if (baz (25, 4, 7) != 22) Maybe it's a problem with how we model predicates for MVE.
[Bug target/115493] gcc.c-torture/execute/pr94734.c fails on MVE after gcc-15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #1 from Christophe Lyon --- Created attachment 58429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58429&action=edit Wrong code generation
[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- The testcase was also updated by: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c1356e8cc9a8c869ab936c927b1812b4691265b6
[Bug target/115248] New: aarch64/sve/pre_cond_share_1.c fails since gcc-15-276-gbed6ec161be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248 Bug ID: 115248 Summary: aarch64/sve/pre_cond_share_1.c fails since gcc-15-276-gbed6ec161be Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: aarch64 Since gcc-15-276-gbed6ec161be (g:bed6ec161be8c5ca2f24195900ce3c9b81c3e141) we have noticed a regression on aarch64: Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ... FAIL: gcc.target/aarch64/sve/pre_cond_share_1.c scan-tree-dump-times optimized "\\.COND_MUL" 1 XPASS: gcc.target/aarch64/sve/pre_cond_share_1.c scan-tree-dump-times optimized "\\.VCOND" 1
[Bug rtl-optimization/114522] [15 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522 Christophe Lyon changed: What|Removed |Added Target|arm |arm aarch64 --- Comment #2 from Christophe Lyon --- The patch has been un-reverted, so indeed this failure has re-appeared. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9dbff9c05520a74e6cd337578f27b56c941f64f3 on aarch64, this triggers more regressions: Running gcc:gcc.target/aarch64/aarch64.exp ... FAIL: gcc.target/aarch64/aes_xor_combine.c scan-assembler-not eor FAIL: gcc.target/aarch64/aes_xor_combine.c scan-assembler-not mov FAIL: gcc.target/aarch64/ashltidisi.c scan-assembler-times asr 3 FAIL: gcc.target/aarch64/asimd-mull-elem.c scan-assembler-times \\s+fmul\\tv[0-9]+\\.4s, v[0-9]+\\.4s, v[0-9]+\\.s\\[0\\] 4 FAIL: gcc.target/aarch64/asimd-mull-elem.c scan-assembler-times \\s+mul\\tv[0-9]+\\.4s, v[0-9]+\\.4s, v[0-9]+\\.s\\[0\\] 4 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies g1 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies g16 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies g16p FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies g1p FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies g8 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align16.c check-function-bodies g8p FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies g1 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies g16 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies g16p FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies g1p FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies g8 FAIL: gcc.target/aarch64/bitfield-bitint-abi-align8.c check-function-bodies g8p FAIL: gcc.target/aarch64/ccmp_3.c scan-assembler-not \tcbnz\t XPASS: gcc.target/aarch64/pr100056.c scan-assembler-not \\t[us]bfiz\\tw[0-9]+, w[0-9]+, 11 FAIL: gcc.target/aarch64/pr100056.c scan-assembler-times \\t[us]bfiz\\tw[0-9]+, w[0-9]+, 11 2 FAIL: gcc.target/aarch64/pr100056.c scan-assembler-times \\tadd\\tw[0-9]+, w[0-9]+, w[0-9]+, uxtb\\n 2 FAIL: gcc.target/aarch64/pr108840.c scan-assembler-not and\\tw[0-9]+, w[0-9]+, 31 FAIL: gcc.target/aarch64/pr112105.c scan-assembler-not \\tdup\\t FAIL: gcc.target/aarch64/pr112105.c scan-assembler-times (?n)\\tfmul\\t.*v[0-9]+\\.s\\[0\\]\\n 2 FAIL: gcc.target/aarch64/rev16_2.c scan-assembler-times rev16\\tx[0-9]+ 2 FAIL: gcc.target/aarch64/vaddX_high_cost.c scan-assembler-not dup\\t FAIL: gcc.target/aarch64/vmul_element_cost.c scan-assembler-not dup\\t FAIL: gcc.target/aarch64/vmul_high_cost.c scan-assembler-not dup\\t FAIL: gcc.target/aarch64/vsubX_high_cost.c scan-assembler-not dup\\t Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ... FAIL: gcc.target/aarch64/sve/pr98119.c scan-assembler \\tand\\tx[0-9]+, x[0-9]+, #?-31\\n FAIL: gcc.target/aarch64/sve/pred-not-gen-1.c scan-assembler-not \\tbic\\t FAIL: gcc.target/aarch64/sve/pred-not-gen-1.c scan-assembler-times \\tnot\\tp[0-9]+\\.b, p[0-9]+/z, p[0-9]+\\.b\\n 1 FAIL: gcc.target/aarch64/sve/pred-not-gen-4.c scan-assembler-not \\tbic\\t FAIL: gcc.target/aarch64/sve/pred-not-gen-4.c scan-assembler-times \\tnot\\tp[0-9]+\\.b, p[0-9]+/z, p[0-9]+\\.b\\n 1 FAIL: gcc.target/aarch64/sve/var_stride_2.c scan-assembler-times \\tubfiz\\tx[0-9]+, x2, 10, 16\\n 1 FAIL: gcc.target/aarch64/sve/var_stride_2.c scan-assembler-times \\tubfiz\\tx[0-9]+, x3, 10, 16\\n 1 FAIL: gcc.target/aarch64/sve/var_stride_4.c scan-assembler-times \\tsbfiz\\tx[0-9]+, x2, 10, 32\\n 1 FAIL: gcc.target/aarch64/sve/var_stride_4.c scan-assembler-times \\tsbfiz\\tx[0-9]+, x3, 10, 32\\n 1
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #32 from Christophe Lyon --- Created attachment 58110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110&action=edit patch v2 Here is another patch proposal along the lines of what you suggest in #c24
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #30 from Christophe Lyon --- > ./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard > pr114801.c -mthumb -O2 -da Thanks, for some reason -O2 had disappeared from my flags, it does ICE with it.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #27 from Christophe Lyon --- (In reply to Jakub Jelinek from comment #25) > > Indeed, it ICEs e.g. during CSE. > Though, that also means it is just about luck, if something isn't a > CONST_INT at expansion time but simplified into CONST_INT later, it can ICE > as well. How did you test it to make it crash? The (modifed) testcase compiles OK for me: return vdupq_m_n_u32(vdupq_n_u32(0x), 0, 0x0acf); return vdupq_m_n_u16(vdupq_n_u16(0x), 0, 0x1b0f);
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #26 from Christophe Lyon --- Thanks for testing, my build is still in progress.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #22 from Christophe Lyon --- Sure, that's what I'm worried about. So we can: - leave this as-is for gcc-14 (known bug) - commit what we discussed in #c15 #c16, (with an improved testcase as you mentioned on the list,) thus at least temporarily forcing canonicalization (preventing users from using 'weird' values) - possibly revisit this for gcc-15 by handling predicates differently
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #19 from Christophe Lyon ---
So basically values such as 0x are not UB and we want to accept them.
I tested:
diff --git a/gcc/rtx-vector-builder.cc b/gcc/rtx-vector-builder.cc
index 9509d9fc453..f89aa717903 100644
--- a/gcc/rtx-vector-builder.cc
+++ b/gcc/rtx-vector-builder.cc
@@ -96,8 +96,6 @@ rtx_vector_builder::find_cached_value ()
return CONSTM1_RTX (m_mode);
else if (elt == const0_rtx)
return CONST0_RTX (m_mode);
- else
- gcc_unreachable ();
}
/* We can be called before the global vector constants are set up,
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 6a5775c67e5..6dc0b603dad 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -2205,7 +2205,13 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
}
else if (VALID_MVE_PRED_MODE (mode))
- x = gen_lowpart (mode, x);
+ {
+ if (SUBREG_P (x))
+ /* gen_lowpart on a SUBREG can ICE. */
+ x = force_reg (GET_MODE (x), x);
+
+ x = gen_lowpart (mode, x);
+ }
m_ops.safe_grow (m_ops.length () + 1, true);
create_input_operand (&m_ops.last (), x, mode);
And it works: we generate
mov r2, #52428 for 0x
mov r3, #43690 for 0x
But I guess removing the call to gcc_unreachable breaks a strong assumption in
many places?
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #16 from Christophe Lyon --- Thanks for the suggestion, this works. I've posted the patch + testcase: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650086.html
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #14 from Christophe Lyon --- Created attachment 58050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050&action=edit patch proposal Here is the patch I propose.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #12 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #11)
> So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> same size, 2 bytes, so I'd go with
> else if (VALID_MVE_PRED_MODE (mode))
> {
> /* unsigned short arguments to functions get promoted to int, undo
> that. */
> if (GET_MODE_SIZE (x) != GET_MODE_SIZE (HImode))
> x = gen_lowpart (HImode, x);
> if (GET_MODE (x) != mode)
> {
> /* Nested SUBREGs are invalid. */
> if (SUBREG_P (x))
> x = force_reg (GET_MODE (x), x);
> x = lowpart_subreg (mode, x,
> GET_MODE (x) == VOIDmode ? HImode : GET_MODE
> (x));
This still crashes with mode == V*BI, because we reach
rtx_vector_builder::find_cached_value() where elt is not a supported constant.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #8 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #5)
> Guess the primary question is why there is the gen_lowpart call at all.
> Is it that normally the mode of x is already right due to the prototypes of
> the builtins, with the exception that gcc likes to promote QImode/HImode
> arguments of calls to SImode, so is the intent in that case to just narrow
> down SImode back to HImode (seems VALID_MVE_PRED_MODE is only true for
> HImode from scalar MODE_INT modes)?
>
We have mode == V4BImode (could be V16BI or V8BI, it depends on the intrinsic
being expanded)
and x is HImode.
The intent is to generate:
(set (reg:V4BI 122)
(subreg:V4BI (reg:SI 116 [ _3 ]) 0))
This works if x is not a constant (this is what we have in trunk)
> If so, best would be to limit the call to just that case.
> So (completely untested):
> --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194
> +0100
> +++ gcc/config/arm/arm-mve-builtins.cc2024-04-26 15:49:55.380344060
> +0200
> @@ -2100,7 +2100,12 @@ function_expander::add_input_operand (in
>mode = GET_MODE (x);
> }
>else if (VALID_MVE_PRED_MODE (mode))
> -x = gen_lowpart (mode, x);
> +{
> + if (mode == HImode && GET_MODE (x) != HImode)
> + /* GCC promotes QI/HImode arguments to int, undo that
> +here. */
> + x = lowpart_subreg (mode, x, SImode);
So we won't enter the 'if' since mode != HImode
> +}
>
>m_ops.safe_grow (m_ops.length () + 1, true);
>create_input_operand (&m_ops.last (), x, mode);
>
> I'd hope if the argument is a vector mode x already has that mode...
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #7 from Christophe Lyon --- (In reply to Jakub Jelinek from comment #4) > (In reply to Christophe Lyon from comment #3) > > lowpart_subreg does not work either. > > > > If we put the predicates in a variable in the testcase, then in > > function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI > > 116 [ _3 ]) 0) so taking gen_lowpart of that is OK (we just want HImode to > > get the 16 bits of predicates). > > If x could be e.g. (subreg:SI (reg:DI ...) ...), then one needs to use for > GET_CODE (x) == SUBREG && GET_MODE (x) != mode do a force_reg first. > No sure I got this right: if (GET_CODE (x) == SUBREG && GET_MODE (x) != mode) x = force_reg (mode, x); breaks the assert in emit_move_insn because mode is V4BImode and 'y' is HImode. > > But when predicates are passed as a constant as in the testcase, we have > > x = (const_int -13108 [0x]) > > and gen_lowpart (HImode, x) fails on that. > > Why doesn't lowpart_subreg (mode, x, GET_MODE (x) == VOIDmode ? DImode : > GET_MODE (x)); > work? > I.e. for CONST_INTs assume it is some constant in a mode equal or wider than > mode. > Unless mode can be TImode or x can be __int128 constants, that is. > This fails because down the call chain from lowpart_subreg, we reach gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode == V4BImode (so is MODE_VECTOR_BOOL), but is not a valid expected boolean constant vector.
[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 --- Comment #3 from Christophe Lyon --- lowpart_subreg does not work either. If we put the predicates in a variable in the testcase, then in function_expander::add_input_operand() x is already a (subreg/s/v:HI (reg:SI 116 [ _3 ]) 0) so taking gen_lowpart of that is OK (we just want HImode to get the 16 bits of predicates). But when predicates are passed as a constant as in the testcase, we have x = (const_int -13108 [0x]) and gen_lowpart (HImode, x) fails on that. I'm trying an approach to convert the constant into a vector of constants whose mode will V4BImode in this case.
[Bug target/114801] [14 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801 Christophe Lyon changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-22 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Christophe Lyon --- The problem in function_expander::add_input_operand (arm-mve-builtins.cc) is that x = gen_lowpart (mode, x); does not work when x is a constant. Replacing 0x with a variable in the testcase makes it compile OK.
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #12 from Christophe Lyon --- Indeed the plan is to commit the first series (https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649261.html) once stage-1 re-opens (as approved in https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649299.html
[Bug preprocessor/114748] [14 Regression] libcpp aclocal.m4 and configure incorrectly regenerated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Christophe Lyon --- Fixed on trunk
[Bug preprocessor/114748] [14 Regression] libcpp aclocal.m4 and configure incorrectly regenerated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748 --- Comment #7 from Christophe Lyon --- So yes indeed at r14-5423-gfbe4e64365ec7f, autoreconf will generate the same contents, but starting at r14-5424-gdb50aea6259545 we get this discrepancy. We can probably commit the "fixed" version, but should we investigate why override.m4 is needed again?
[Bug preprocessor/114748] [14 Regression] libcpp aclocal.m4 and configure incorrectly regenerated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748 --- Comment #6 from Christophe Lyon --- (In reply to Andrew Pinski from comment #1) > The last time aclocal.m4 had an include for override.m4 was > r9-3776-g22e052725189a4 . IIUC that commit actually removed the include for override.m4 ? > Are you sure you are using the correct autoconf/automake version? Yes, autoconf-2.69 and automake-1.15.1. I'm updating autoregen.py in the sourceware buildbot.
[Bug other/114748] New: libcpp aclocal.m4 and configure incorrectly regenerated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748 Bug ID: 114748 Summary: libcpp aclocal.m4 and configure incorrectly regenerated Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Running either 'autoreconf' or 'aclocal -I ../config' in libcpp/ generates aclocal.m4 and configure scripts with slightly different contents from what is currently in the repo: diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4 index 4fc81709622..4d898ea2c97 100644 --- a/libcpp/aclocal.m4 +++ b/libcpp/aclocal.m4 @@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4]) m4_include([../config/lib-link.m4]) m4_include([../config/lib-prefix.m4]) m4_include([../config/nls.m4]) +m4_include([../config/override.m4]) m4_include([../config/po.m4]) m4_include([../config/progtest.m4]) m4_include([../config/warnings.m4]) diff --git a/libcpp/configure b/libcpp/configure index 8a38c0546e3..930f2d59307 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu + + + ac_aux_dir= for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do if test -f "$ac_dir/install-sh"; then Are these files incorrect in the repo? I tried to remove ../config/override.m4 and run either 'autoreconf' or 'aclocal -I ../config', then the result is the same as what is in the repo: override.m4 is not needed by libcpp, but still analyzed by aclocal, and it does have a sligh effect when generating configure. Is the fix to commit the above differences, or is there another recipe to regenerate these files?
[Bug testsuite/114568] [14 regression] g++.dg/vect/pr84556.cc fails to produce executable since r14-9706-gb8e7aaaf350a45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568 --- Comment #4 from Christophe Lyon --- I'm wondering whether you missed check_effective_target_arm_arch_FUNC_link and friends? Maybe check_effective_target_arm_arch_v7a_neon_link would work here, but it does not use the exact same flags.
[Bug testsuite/114568] [14 regression] g++.dg/vect/pr84556.cc fails to produce executable since r14-9706-gb8e7aaaf350a45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568 --- Comment #2 from Christophe Lyon --- I think the last -march option overrides the previous one(s). I'd say the test should use an effective-target which checks that linking is actually OK rather than just a compile OK test. Not sure if an adequate one already exists, but there are already plenty :-)
[Bug rtl-optimization/114522] New: [14 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522 Bug ID: 114522 Summary: [14 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: segher at gcc dot gnu.org Target Milestone: --- After g:839bc42772ba7af66af3bd16efed4a69511312ae, r14-9692-g839bc42772ba7a we have noticed a regression on arm: FAIL: gcc.target/arm/aes_xor_combine.c scan-assembler-not veor commit 839bc42772ba7af66af3bd16efed4a69511312ae (HEAD) Author: Segher Boessenkool Date: Wed Mar 27 14:09:52 2024 + combine: Don't combine if I2 does not change This might be the same problem as other PRs reported after this commit.
[Bug target/114323] [14 Regression] MVE vector load intrinsic miscompiled since r14-5622-g4d7647edfd7d98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Christophe Lyon --- Fixed.
[Bug target/114323] [14 Regression] MVE vector load intrinsic miscompiled since r14-5622-g4d7647edfd7d98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323 --- Comment #5 from Christophe Lyon --- Exactly. I have a (one-line) patch.
[Bug target/114323] [14 Regression] MVE vector load intrinsic miscompiled since r14-5622-g4d7647edfd7d98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2024-03-14
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #2 from Christophe Lyon ---
Tried a similar testcase for aarch64 (the intrinsics framework for MVE is very
close to SVE's), and noticed that when running dse_classify_store() it sees a
use of the initialized memory:
svuint32_t foo ()
{
const uint32_t D.11583[4];
svuint32_t V0;
:
D.11583[0] = 1;
D.11583[1] = 2;
D.11583[2] = 3;
D.11583[3] = 4;
V0_7 = svld1_u32 ({ -1, 0, 0, 0, ... }, &D.11583);
D.11583 ={v} {CLOBBER(eol)};
return V0_7;
}
# .MEM_6 = VDEF <.MEM_
D.11583[3] = 4;
# VUSE <.MEM_6>
V0_7 = svld1_u32 ({ -1, 0, 0, 0, ... }, &D.11583);
dse_classify_store() on arm/MVE does not see such a use and decides the
initialization is a dead store.
[Bug target/114143] Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- What configure flags did you use? Only --target arm-eabi" ? What does gcc --print-multi-lib say?
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- (In reply to Maxim Kuvyrkov from comment #13) > We are seeing scan-assembler failures in a single 32-bit arm test. This > affects both linux and bare-metal targets: arm-linux-gnueabihf and > arm-none-eabi. > > === gcc tests === > > Running gcc:gcc.target/arm/arm.exp ... > FAIL: gcc.target/arm/bics_3.c scan-assembler-times bics\tr[0-9]+, r[0-9]+, > r[0-9]+ 2 > FAIL: gcc.target/arm/bics_3.c scan-assembler-times bics\tr[0-9]+, r[0-9]+, > r[0-9]+, .sl #2 1 I think this is reported as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
[Bug testsuite/113425] gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425 --- Comment #3 from Christophe Lyon --- What I meant by arm-* is that we see the same issue on several of the configurations we test, as can be seen on https://linaro.atlassian.net/browse/GNU-1100 We have recently improved the extraction of the configure line, so now some of the xxx/details.txt on that page include it. The two "simplest" configurations we test are tcwg_gcc_check/master-arm and tcwg_gnu_native_check_gcc, but both of them ran before the improvement mentioned above; in these cases, the information is present inside console.log.xz in the relevant CI step directory (03-build_abe-gcc for tcwg_gcc_check/master-arm and 04-build_abe-gcc for tcwg_gnu_native_check_gcc/master-arm, the "-gcc" suffix meaning it's the step is which we build gcc) Anyway, here is the GCC configure line for tcwg_gcc_check/master-arm: /configure SHELL=/bin/bash --with-mpc=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf --with-mpfr=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf --with-gmp=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabihf --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared --without-included-gettext --enable-nls --with-system-zlib --disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id --disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu --enable-libstdcxx-debug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no --disable-multilib --with-float=hard --with-fpu=neon-fp-armv8 --with-mode=thumb --with-arch=armv8-a --enable-threads=posix --enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function --enable-checking=yes --disable-bootstrap --enable-languages=default --prefix=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/armv8l-unknown-linux-gnueabih
[Bug c/113489] aarch64: ICE on gcc/gcc/tree-vect-slp.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- (In reply to Adhemerval Zanella from comment #0) > > The configuration used can be found at > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/ > 1215/artifact/artifacts/08-build_abe-stage2/console.log.xy (line 356). There's a typo in the link, it should end with '.xz' not '.xy': https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1215/artifact/artifacts/08-build_abe-stage2/console.log.xz Anyway we now extract the configure / make commands, the relevant one is at step 08-build_abe-stage2 in https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1215/artifact/artifacts/notify/configure-make.txt
[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #13 from Christophe Lyon ---
(In reply to Adhemerval Zanella from comment #12)
> I am not sure if this is a test contraint failure or something else.
I think this is a test issue, the test is for v8.1-m, so requires thumb mode
and our scripts force -marm, leading to the error.
The test should check whether it can use the options it wants to use, like
other tests do.
Something around
/* { dg-require-effective-target arm_hard_ok } */
/* { dg-require-effective-target arm_v8_1m_mve_ok } */
/* { dg-add-options arm_v8_1m_mve } */
/* { dg-additional-options "-O2 -mfloat-abi=hard" } */
Not sure if/why fp.dp nor mve.fp are required? (#c6 does not mention them)
[Bug testsuite/113428] [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428 Christophe Lyon changed: What|Removed |Added Target|powerpc64-linux-gnu |powerpc64-linux-gnu arm CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Also seen on arm targets.
[Bug testsuite/113437] New: gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437 Bug ID: 113437 Summary: gcc.dg/tree-ssa/pr95906.c fails on arm since g:6686e16fda4 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: liuhongt at gcc dot gnu.org Target Milestone: --- We have detected the following regression since gcc-14-7124-g6686e16fda4: FAIL: gcc.dg/tree-ssa/pr95906.c scan-tree-dump-times forwprop3 "max_expr" 1 on arm targets where Neon or MVE is not enabled by default. In these cases VECTOR_MODE_P (V16QImode) returns false, thus the optimization introduced by this commit. I'm not sure how/if we want to add an effective-target to handle this case.
[Bug target/113425] New: gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425 Bug ID: 113425 Summary: gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: tamar.christina at arm dot com Target Milestone: --- Since g:7cbe41d35e6 (gcc-14-7115-g7cbe41d35e6), we have noticed the following regression on arm-* targets: FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 1 FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "__builtin_copysign" 1
[Bug testsuite/113278] New: analyzer tests relying on fileno() fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278 Bug ID: 113278 Summary: analyzer tests relying on fileno() fail on arm-eabi Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: arm-eabi A few analyzer tests relying on fileno() fail on arm-eabi: c-c++-common/analyzer/fileno-1.c c-c++-common/analyzer/flex-with-call-summaries.c c-c++-common/analyzer/flex-without-call-summaries.c g++.log contains: gcc/testsuite/c-c++-common/analyzer/fileno-1.c:5:10: error: 'fileno' was not declared in this scope newlib does provide fileno() but maybe it's actually a newlib bug, or a bug in the way we build it.
[Bug target/113276] New: gcc.dg/torture/fp-double-convert-float-1.c fails at execution on arm cortex-m33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113276 Bug ID: 113276 Summary: gcc.dg/torture/fp-double-convert-float-1.c fails at execution on arm cortex-m33 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: arm-eabi As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637422.html , gcc.dg/torture/fp-double-convert-float-1.c fails at execution time when targeting cortex-m33 (-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto) FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O0 execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O1 execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O2 execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -O3 -g execution test FAIL: gcc.dg/torture/fp-double-convert-float-1.c -Os execution test
[Bug target/113275] New: tests pr110268-1.c pr110268-2.c csinc-1.c csinv-1.c fail after gcc-14-5396-ged52bc2e30c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113275 Bug ID: 113275 Summary: tests pr110268-1.c pr110268-2.c csinc-1.c csinv-1.c fail after gcc-14-5396-ged52bc2e30c Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- After commit g:ed52bc2e30c (arm: testsuite: avoid hard-float ABI incompatibility with -march) a few testcases started to fail on arm-eabi: * when targeting cortex-m33 (-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto) FAIL: gcc.target/arm/pr110268-1.c (test for excess errors) FAIL: gcc.target/arm/pr110268-2.c (test for excess errors) * when targeting cortex-m7 (-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto) FAIL: gcc.target/arm/csinc-1.c scan-assembler csinc\tr[0-9]*.*ne FAIL: gcc.target/arm/csinv-1.c scan-assembler csinv\tr[0-9]*.*ne FAIL: gcc.target/arm/pr110268-1.c (test for excess errors) FAIL: gcc.target/arm/pr110268-2.c (test for excess errors) GCC is configured with --disable-multilib --with-mode=thumb --with-cpu=cortex-m7 --with-float=hard (or with --with-cpu=cortex-m33) For gcc.target/arm/pr110268-[12].c, gcc.log says: Executing on host: /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr110268-1.c -mthumb -march=armv7e-m+fp.dp -mtune=cortex-m7 -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output -ansi -pedantic-errors -mfloat-abi=softfp -mfpu=auto -march=armv8.1-m.main+mve -mthumb --save-temps -O2 -flto -specs=rdimon.specs -lm -o pr110268-1.exe(timeout = 600) /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.0/../../../../arm-eabi/bin/ld: error: pr110268-1.exe uses VFP register arguments, ./pr110268-1.ltrans0.ltrans.o does not /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.0/../../../../arm-eabi/bin/ld: failed to merge target specific data of file ./pr110268-1.ltrans0.ltrans.o
[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 Christophe Lyon changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- adding maintainers who might provide larger context wrt compatibility with other compilers.
[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 --- Comment #4 from Christophe Lyon --- @mkretz, this commit may also be of interest for some more context: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d12d2aa4fccc76a9a08c8120c5e37d9cab8683e8
[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 Christophe Lyon changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-30 --- Comment #3 from Christophe Lyon --- gcc.target/arm/bfloat16_vector_typecheck_[12].c testcases fixed. There's still a problem with experimental/simd/pr109261_constexpr_simd.cc, which may involve a change to simd_neon.h or simd.h
[Bug target/112698] gcc-14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 --- Comment #1 from Christophe Lyon --- For gcc.target/arm/bfloat16_vector_typecheck* tests, the log says: FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors) Excess errors: bfloat16_vector_typecheck_1.c:122:17: error: incompatible types when initializing type 'long int' using type 'bfloat16x4_t' bfloat16_vector_typecheck_1.c:124:17: error: incompatible types when initializing type 'long int' using type 'bfloat16x4_t' FAIL: gcc.target/arm/bfloat16_vector_typecheck_2.c (test for excess errors) Excess errors: bfloat16_vector_typecheck_2.c:114:17: error: incompatible types when initializing type 'long int' using type 'bfloat16x8_t' For experimental/simd/pr109261_constexpr_simd.cc, the log says: FAIL: experimental/simd/pr109261_constexpr_simd.cc -mfpu=neon -mfloat-abi=softfp -march=armv7-a -ffast-math -O2 -Wno-psabi (test for excess errors) Excess errors: simd_neon.h:332: error: cannot convert '__vector(2) int' to 'int32x2_t' simd_neon.h:332: error: cannot convert '__vector(2) int' to 'int32x2_t' simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization simd_neon.h:497: error: cannot convert '__vector(2) int' to 'int32x2_t' in initialization
[Bug target/112698] New: gcc-14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 Bug ID: 112698 Summary: gcc-14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: clyon at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: arm-eabi Commit g:b8592186611b671d6dc47332ecaf4a4b9c3802fb introduced regressions on arm-eabi as follows: * for cortex-m0: Running gcc:gcc.target/arm/arm.exp ... FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for errors, line 122) FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for errors, line 124) FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors) FAIL: gcc.target/arm/bfloat16_vector_typecheck_2.c (test for errors, line 114) FAIL: gcc.target/arm/bfloat16_vector_typecheck_2.c (test for excess errors) * for cortex-m3: Running gcc:gcc.target/arm/arm.exp ... FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for errors, line 122) FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for errors, line 124) FAIL: gcc.target/arm/bfloat16_vector_typecheck_1.c (test for excess errors) FAIL: gcc.target/arm/bfloat16_vector_typecheck_2.c (test for errors, line 114) FAIL: gcc.target/arm/bfloat16_vector_typecheck_2.c (test for excess errors) Running libstdc++:libstdc++-dg/conformance.exp ... FAIL: experimental/simd/pr109261_constexpr_simd.cc -mfpu=neon -mfloat-abi=softfp -march=armv7-a -ffast-math -O2 -Wno-psabi (test for excess errors)
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #5 from Christophe Lyon ---
The new test pr111309-2.c has a few failures on arm-eabi:
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++14 (test for errors,
line 35)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++14 (test for errors,
line 54)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++17 (test for errors,
line 35)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++17 (test for errors,
line 54)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++20 (test for errors,
line 35)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++20 (test for errors,
line 54)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++98 (test for errors,
line 35)
FAIL:g++:g++.dg/dg.exp=c-c++-common/pr111309-2.c -std=c++98 (test for errors,
line 54)
That is, no error message for lines 35 and 54:
/* { dg-error "does not have 'int' type" "" { target c++ } } */
[Bug libstdc++/111238] libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 --- Comment #3 from Christophe Lyon --- The original problem is fixed by https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628998.html, and it seems better not to call GLIBCXX_CHECK_LINKER_FEATURES and silently hide a potential problem. Maybe we should actually remove -gc-sections from native builds too, so that all configurations are consistent? https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629031.html
[Bug libstdc++/111238] libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 --- Comment #2 from Christophe Lyon --- Oops sorry I pushed an unwanted patch, which I reverted with https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 --- Comment #12 from Christophe Lyon --- (In reply to Jonathan Wakely from comment #11) > Please file a separate bug for these failures. Thanks for the pointers, I digged a bit more, and filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
[Bug libstdc++/111238] New: libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 Bug ID: 111238 Summary: libstdc++ tests should use -Wl,-gc-sections in more configurations Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: jwakely.gcc at gmail dot com Target Milestone: --- As a follow-up to bug #104167, I've looked in more detail after Jonathan's last comment there: > Does arm-eabi build libstdc++.a with -ffunction-sections? > The tests should be built with -Wl,--gc-sections which combined with > -ffunction-sections should mean that the tests do not pull in symbols > they don't need. So on arm-eabi, libstdc++'s configure correctly detects that -ffunction-sections is supported, and builds with it. However, when running the testsuite, it lacks -Wl,-gc-sections. I checked manually that adding this flag makes the link succeed for the offending testcase I reported in PR #104167. This happens because we are not in a native mode build, so configure.ac does not run GLIBCXX_CHECK_LINKER_FEATURES, and even when running the "cross target environment" part of the configuration, we do not even make use of GLIBCXX_CROSSCONFIG because I configure with --with-newlib. That being said, GLIBCXX_CROSSCONFIG makes use of -Wl,--gc-sections only for *-tpf targets, so even configuring without --with-newlib wouldn't help. Maybe we could call GLIBCXX_CHECK_LINKER_FEATURES only when not in canadian-cross mode?
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 --- Comment #10 from Christophe Lyon --- (In reply to Jonathan Wakely from comment #9) > (In reply to Christophe Lyon from comment #8) > > On arm-eabi targets (thus, using newlib), we've noticed new errors: > > New since when? These files haven't changed in the last two weeks. The bisection pointed to the patch in comment #6.
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #8 from Christophe Lyon --- On arm-eabi targets (thus, using newlib), we've noticed new errors: FAIL: std/time/clock/gps/io.cc (test for excess errors) UNRESOLVED: std/time/clock/gps/io.cc compilation failed to produce executable FAIL: std/time/clock/tai/io.cc (test for excess errors) UNRESOLVED: std/time/clock/tai/io.cc compilation failed to produce executable The logs say: FAIL: std/time/clock/gps/io.cc (test for excess errors) Excess errors: ld: /arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o): in function `std::filesystem::current_path(std::filesystem::__cxx11::path const&, std::error_code&)': /libstdc++-v3/src/c++17/fs_ops.cc:806:(.text._ZNSt10filesystem12current_pathERKNS_7__cxx114pathE+0x10): undefined reference to `chdir' ld: /libstdc++-v3/src/c++17/fs_ops.cc:806:(.text._ZNSt10filesystem12current_pathERKNS_7__cxx114pathERSt10error_code+0x6): undefined reference to `chdir' ld: /arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o): in function `(anonymous namespace)::create_dir(std::filesystem::__cxx11::path const&, std::filesystem::perms, std::error_code&)': /libstdc++-v3/src/c++17/fs_ops.cc:583:(.text._ZN12_GLOBAL__N_110create_dirERKNSt10filesystem7__cxx114pathENS0_5permsERSt10error_code+0xa): undefined reference to `mkdir' ld: /arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o): in function `std::filesystem::create_directory(std::filesystem::__cxx11::path const&, std::error_code&)': /libstdc++-v3/src/c++17/fs_ops.cc:583:(.text._ZNSt10filesystem16create_directoryERKNS_7__cxx114pathERSt10error_code+0xe): undefined reference to `mkdir' ld: /arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o): in function `std::filesystem::permissions(std::filesystem::__cxx11::path const&, std::filesystem::perms, std::filesystem::perm_options, std::error_code&)': /libstdc++-v3/src/c++17/fs_ops.cc:1134:(.text._ZNSt10filesystem11permissionsERKNS_7__cxx114pathENS_5permsENS_12perm_optionsERSt10error_code+0x7c): undefined reference to `chmod' ld: /libstdc++-v3/src/c++17/fs_ops.cc:1134:(.text._ZNSt10filesystem11permissionsERKNS_7__cxx114pathENS_5permsENS_12perm_optionsERSt10error_code+0x9c): undefined reference to `chmod' ld: /arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o): in function `std::filesystem::current_path[abi:cxx11](std::error_code&)': /libstdc++-v3/src/c++17/fs_ops.cc:750:(.text._ZNSt10filesystem12current_pathB5cxx11ERSt10error_code+0x22): undefined reference to `pathconf' ld: /libstdc++-v3/src/c++17/fs_ops.cc:769:(.text._ZNSt10filesystem12current_pathB5cxx11ERSt10error_code+0x54): undefined reference to `getcwd' ld: /arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o): in function `std::filesystem::do_copy_file(char const*, char const*, std::filesystem::copy_options_existing_file, stat*, stat*, std::error_code&)': /libstdc++-v3/src/c++17/../filesystem/ops-common.h:553:(.text._ZNSt10filesystem12do_copy_fileEPKcS1_NS_26copy_options_existing_fileEP4statS4_RSt10error_code+0x114): undefined reference to `chmod' collect2: error: ld returned 1 exit status BTW I noticed the same error messages for other tests (eg. std/time/clock/gps/1.cc)
[Bug tree-optimization/110986] New: aarch64 regressions after r14-3110-g7fb65f10285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986 Bug ID: 110986 Summary: aarch64 regressions after r14-3110-g7fb65f10285 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- After commit r14-3110-g7fb65f10285 (MATCH: [PR110937/PR100798] (a ? ~b : b) should be optimized to b ^ -(a)), I have noticed regressions on aarch64: Running gcc:gcc.target/aarch64/aarch64.exp ... FAIL: gcc.target/aarch64/cond_op_imm_1.c scan-assembler csinv\tw[0-9]*.* FAIL: gcc.target/aarch64/cond_op_imm_1.c scan-assembler csinv\tx[0-9]*.* Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ... FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-not \\tmov\\tz FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-times \\tneg\\tz[0-9]+\\.b, p[0-7]/m, 3 FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-times \\tneg\\tz[0-9]+\\.h, p[0-7]/m, 2 FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-times \\tneg\\tz[0-9]+\\.s, p[0-7]/m, 1 FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-times \\tnot\\tz[0-9]+\\.b, p[0-7]/m, 3 FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-times \\tnot\\tz[0-9]+\\.h, p[0-7]/m, 2 FAIL: gcc.target/aarch64/sve/cond_unary_5.c scan-assembler-times \\tnot\\tz[0-9]+\\.s, p[0-7]/m, 1
[Bug ipa/110378] IPA-SRA for destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378 --- Comment #8 from Christophe Lyon --- Created attachment 55707 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55707&action=edit pr110378-1.C.083i.sra
[Bug ipa/110378] IPA-SRA for destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #7 from Christophe Lyon --- The new test fails on arm: FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++14 scan-ipa-dump sra "Will split parameter 0" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++14 scan-tree-dump-not optimized "shouldnotexist" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++17 scan-ipa-dump sra "Will split parameter 0" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++17 scan-tree-dump-not optimized "shouldnotexist" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++20 scan-ipa-dump sra "Will split parameter 0" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++20 scan-tree-dump-not optimized "shouldnotexist" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++98 scan-ipa-dump sra "Will split parameter 0" FAIL: g++.dg/ipa/pr110378-1.C -std=gnu++98 scan-tree-dump-not optimized "shouldnotexist" I'm attaching pr110378-1.C.083i.sra
[Bug target/110268] [14 Regression] arm MVE intrinsics support broken with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Christophe Lyon --- Fixed.
[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381 --- Comment #20 from Christophe Lyon --- Sorry for the typo in the date in the commit message :-(
[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381 --- Comment #17 from Christophe Lyon --- Thanks Andrew, I wasn't aware of vect_float_strict. I confirm it makes the test UNSUPPORTED. Can you commit the fix or do you want me to do it on your behalf?
[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381 --- Comment #15 from Christophe Lyon --- (In reply to Richard Biener from comment #14) > (In reply to Christophe Lyon from comment #12) > > The new testcase (gcc.dg/vect/pr110381.c) fails: > > FAIL: gcc.dg/vect/pr110381.c -flto -ffat-lto-objects execution test > > FAIL: gcc.dg/vect/pr110381.c execution test > > > > on arm-linux-gnueabihf configured with --with-float=hard > > --with-fpu=neon-fp-armv8 --with-mode=thumb --with-arch=armv8-a > > Can you check if it works now? I've added a missing check_vect () call in > case the harness passes in command-line options that your HW doesn't > support. Otherwise I'd appreciate command-line options to reproduce. I still fails (check_vect() passes on my config, so there's no change). Here is what sum_8_foos looks like: sum_8_foos: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. vmov.i64d0, #0 @ float add r3, r0, #192 .L10: vldr.64 d16, [r0, #8] addsr0, r0, #24 vldr.64 d18, [r0, #-24] vldr.64 d17, [r0, #-8] cmp r3, r0 vadd.f64d16, d16, d18 vadd.f64d16, d16, d17 vadd.f64d0, d0, d16 bne .L10 bx lr so we load: d16=5 d17=-__DBL_MAX__ d18=__DBL_MAX__ the first addition makes d16=__DBL_MAX__ and the second one makes d16=0 > I cannot get anything to vectorize with a cc1 cross using > > > ./cc1 -quiet t.c -O2 -ftree-vectorize -fno-vect-cost-model -fopt-info-vec > > -I include tri > > but I have a cross configured with --with-float=hard --with-cpu=cortex-a9 > --with-fpu=neon-fp16 Not sure what happens. I tried my native compiler with the above flags, I get the same code. I tried to build my native compiler with the same flags, same code too. > > I hope the FPU is compliant enough to compute __DBL_MAX__ + -__DBL_MAX__ + > 5. to 5.
[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #12 from Christophe Lyon --- The new testcase (gcc.dg/vect/pr110381.c) fails: FAIL: gcc.dg/vect/pr110381.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/pr110381.c execution test on arm-linux-gnueabihf configured with --with-float=hard --with-fpu=neon-fp-armv8 --with-mode=thumb --with-arch=armv8-a
[Bug target/110268] [14 Regression] arm MVE intrinsics support broken with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268 Christophe Lyon changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Christophe Lyon --- Indeed, a small update to arm_builtin_decl() does the trick. Investigating how to decide whether to call arm_mve::handle_arm_mve_h (false); or arm_mve::handle_arm_mve_h (true); which is normally controlled at preprocessing time depending on __ARM_MVE_PRESERVE_USER_NAMESPACE
[Bug target/110268] [14 Regression] arm MVE intrinsics support broken with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
--- Comment #2 from Christophe Lyon ---
This regression appeared after the patch that re-implements vdupq, but the
issue is likely more generic.
velo r
I tried to update arm_init_mve_builtins() with:
+ if (in_lto_p)
+ {
+ arm_mve::handle_arm_mve_types_h ();
+ arm_mve::handle_arm_mve_h (false);
+ }
but that's not sufficient, we still get the same error although the MVE
intrinsics are registered.
I noticed that the error happens in unpack_ts_function_decl_value_fields() with
fcode==885, not sure where it comes from?
Besides, we'll also have to check how to compute the right value for
handle_arm_mve_h's parameter.
[Bug target/110268] New: arm MVE intrinsics support broken with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110268
Bug ID: 110268
Summary: arm MVE intrinsics support broken with LTO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since I rewrote (a lot of) MVE intrinsics, use of LTO is broken:
$ cat ~/t.c
#include
int main(void)
{
return vaddvq(vdupq_n_s8 (1));
}
# no LTO, OK:
$ arm-none-eabi-gcc ~/t.c -march=armv8.1-m.main+mve -mfloat-abi=hard
-specs=rdimon.specs
# with LTO, broken:
$ arm-none-eabi-gcc ~/t.c -march=armv8.1-m.main+mve -mfloat-abi=hard
-specs=rdimon.specs -flto
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
compilation terminated.
/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/14.0.0/../../../../arm-none-eabi/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050 --- Comment #3 from Christophe Lyon --- So we have a different behavior in libstdc++-v3/include/experimental/bits/simd_detail.h: #if defined __ARM_NEON && (__ARM_ARCH >= 8 || defined __aarch64__) #define _GLIBCXX_SIMD_HAVE_NEON_A32 1 #else #define _GLIBCXX_SIMD_HAVE_NEON_A32 0 #endif
[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050 --- Comment #2 from Christophe Lyon --- Just noticed that the test passes if GCC is configured --with-arch=armv7-a, but fails when forcing -march=armv8-a
[Bug target/110039] [14 Regression] FAIL: gcc.target/aarch64/rev16_2.c scan-assembler-times rev16\\tw[0-9]+ 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Christophe Lyon --- Fixed.
[Bug libstdc++/110050] New: experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
Bug ID: 110050
Summary: experimental/simd/pr109822_cast_functions.cc fails on
arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After commit g:668d43502f465d48adbc1fe2956b979f36657e5f, I've noticed that
experimental/simd/pr109822_cast_functions.cc is now failing on arm targets:
FAIL: experimental/simd/pr109822_cast_functions.cc -ffast-math -O2 -Wno-psabi
(test for excess errors)
Excess errors:
/libstdc++-v3/include/experimental/bits/simd.h:2418: error: static assertion
failed: should use explicit specialization above
/libstdc++-v3/include/experimental/bits/simd.h:2421: error: invalid use of
incomplete type 'struct
std::experimental::parallelism_v2::__intrinsic_type'
/libstdc++-v3/include/experimental/bits/simd_builtin.h:827: error: invalid
application of '__alignof__' to incomplete type
'std::experimental::parallelism_v2::_GnuTraits, 2>::_SimdMember'
{aka 'std::experimental::parallelism_v2::_SimdWrapper'}
/libstdc++-v3/include/experimental/bits/simd.h:5492: error: requested alignment
is not an integer constant
/libstdc++-v3/include/experimental/bits/simd.h:5492: error:
'std::experimental::parallelism_v2::simd<_Tp, _Abi>::_M_data' has incomplete
type
/libstdc++-v3/include/experimental/bits/simd.h:4529: [ skipping 2
instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ]
[...]
I noticed this on trunk, I didn't check all the releases branches, but I
noticed that this commit was backported to gcc 11, 12 and 13.
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #11 from Christophe Lyon --- Thanks, trunk is now OK on both arm and aarch64.
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #8 from Christophe Lyon --- I guess gcc185 is an aarch64 machine? (as opposed to arm) I confirm your patch fixes the problem on aarch64 (the testcase now passes), but it still fails on arm, with: /arm-linux-gnueabihf/libstdc++-v3/include/experimental/bits/simd.h:2412: error: static assertion failed: should use explicit specialization above /arm-linux-gnueabihf/libstdc++-v3/include/experimental/bits/simd.h:2415: error: invalid use of incomplete type 'struct std::experimental::parallelism_v2::__intrinsic_type'
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 --- Comment #6 from Christophe Lyon --- > trunk or the backport? I tested trunk on gcc185. Will check. That's on trunk (didn't check on the branch)
[Bug libstdc++/109261] std::experimental::simd is not usable in several constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- The new testcase fails on arm and aarch64. For instance on arm, the log shows: /libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:45: error: non-constant condition for static assertion /libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:46: error: non-constant condition for static assertion /libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:56: error: non-constant condition for static assertion /libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:56: error: 'constexpr _Tp std::experimental::parallelism_v2::hmin(const simd<_Tp, _Ap>&) [with _Tp = char; _Abi = simd_abi::_VecBuiltin<16>]' called in a constant expression /libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:57: error: non-constant condition for static assertion /libstdc++-v3/testsuite/experimental/simd/pr109261_constexpr_simd.cc:57: error: 'constexpr _Tp std::experimental::parallelism_v2::hmax(const simd<_Tp, _Ap>&) [with _Tp = char; _Abi = simd_abi::_VecBuiltin<16>]' called in a constant expression
[Bug analyzer/109570] detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570 --- Comment #5 from Christophe Lyon --- Not sure how to update/fix the testcases though? Since they get the declaration of fclose from stdio.h, we'd need to make dg-error conditional to the glibc version in use, which seems unpractical. Should we instead remove #include and provide suitable declarations in the testcase?
[Bug analyzer/109570] detect fclose on unopened or NULL files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- The glibc change is now causing failures in the GCC testsuite: FAIL: gcc.dg/analyzer/torture/conftest-1.c -O0 (test for excess errors) Excess errors: /gcc/testsuite/gcc.dg/analyzer/torture/conftest-1.c:6:24: warning: use of possibly-NULL 'f' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] FAIL: gcc.dg/analyzer/data-model-4.c (test for excess errors) Excess errors: /gcc/testsuite/gcc.dg/analyzer/data-model-4.c:11:24: warning: use of possibly-NULL 'f' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 Christophe Lyon changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- Looking at #c6 again, the behavior of aarch64_function_arg_alignment does not seem to match the comment preceding it. IIUC, it should ignore user alignment. So is it expected that the alignment of TYPE_MAIN_VARIANT(type) is 512? (ie. is the bug in aarch64_function_arg_alignment or earlier, when we build "type"?)
[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 --- Comment #10 from Christophe Lyon --- (In reply to Jonathan Wakely from comment #2) > (In reply to Christophe Lyon from comment #0) > > Maybe there's something wrong with the detection of HAVE_GETENTROPY in > > configure? > > We only do a compile test, not link, so if newlib declares it in > but doesn't define it, we detect it incorrectly. But we avoid link tests in > configure, because there are problems for cross-compilers. Why do we avoid link tests? Is that because of something like https://lists.gnu.org/archive/html/autoconf/2007-03/msg00085.html ? Also I am not sure to understand how this patch fixed the problem? Before and after this patch we are happy if compilation succeeds, right? What does the "OR_LINK" part gives us?
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 Christophe Lyon changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- I can see that aarch64_function_arg_alignment has: if (!AGGREGATE_TYPE_P (type)) return TYPE_ALIGN (TYPE_MAIN_VARIANT (type)); which returns 512 with the testcase from comment #0 type is (TYPE_MAIN_VARIANT(type) is the same): unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x776222a0 precision:32 pointer_to_this > sizes-gimplified public unsigned DI size constant 64> unit-size constant 8> user align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77622888 attributes value >>>
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- I may be reading the code incorrectly, but ISTM that rtu_AngleMecIn is the 3rd parameter of the function, so you pass &UnitDelay_DSTATE, while you pass &Sig_MechanicalAngle as 5th parameter. So it's normal that (*rtu_AngleMecIn) and (Sig_MechanicalAngle) have different values.
[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Christophe Lyon --- Fixed.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Christophe Lyon --- Fixed.
[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 --- Comment #5 from Christophe Lyon --- Fixed on trunk
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #10 from Christophe Lyon --- Can you try to revert my patches: f0d3b6e384a68f8b58bc750f240a15cad92600cd ccb9c7b129206209cfc315ab1a0432b5f517bdd9 and remove your patch at comment #5 ? You should still see the problem you reported in bug #108011 However, I don't understand why you had to do what you describe in comment #8. When multilibs are disabled, the build shouldn't try to use MULTILIB_OPTIONS etc...
