[Bug c++/98810] [9/10 Regression] [C++20] ICE in tsubst_copy, at cp/pt.c:16771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #7 from Christophe Lyon ---
Hi, the backport in gcc-9 branch is causing errors:
ERROR: g++.dg/cpp2a/nontype-class-defarg1.C -std=c++14: syntax error in target
selector "target c++20" for " dg-do 2 compile { target c++20 } "
[Bug c++/99459] [11 Regression] Many coroutines regressions on armv7hl-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- They appeared between r11-7517 (g:67f10d28f05fdae7ab25107d5be0b66b065b819b) and r11-7537 (g:ceae9533826aabaf4c78d173c60e3bedeffc6955)
[Bug testsuite/99498] [11 regression] new test case g++.dg/opt/pr99305.C in r11-7587 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99498 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu ||aarch64 arm --- Comment #1 from Christophe Lyon --- Seen on arm and aarch64 too
[Bug c++/99547] New: [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547 Bug ID: 99547 Summary: [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Between r11-7602 and r11-7616, I've noticed a regression: FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (internal compiler error) on arm-eabi targets, and aarch64-elf (that is, configs using newlib vs glibc for *linux* targets) When using -mfloat-abi=hard on arm-eabi, I can see: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/gcc/testsuite/g++1/../../xg++ -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3 /gcc/testsuite/g++1/../../ /gcc/testsuite/g++.dg/modules/xtreme-header-5_c.C -mcpu=cortex-a7 -mfloat-abi=hard -march=armv7ve+simd -fdiagnostics-plain-output -nostdinc++ -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/arm-none-eabi -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/ obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include -I/libstdc++-v3/libsupc++ -I/libstdc++-v3/include/backward -I/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -fmodules-ts -fno-module-lazy -S -o xtreme-header-5_c.s /gcc/testsuite/g++.dg/modules/xtreme-header-5_c.C:3:30: internal compiler error: same canonical type node for different types 'void' and 'std::__void_t::value, std::is_volatile<_Tp>::value>::__type& (&)()>()() : declval::value, std::is_volatile<_Yp>::value>::__type& (&)()>()()))>' 0x97390f comptypes(tree_node*, tree_node*, int) /gcc/cp/typeck.c:1555 0x899d4c template_args_equal(tree_node*, tree_node*, bool) /gcc/cp/pt.c:9207 0x8998ed comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) /gcc/cp/pt.c:9254 0x8a6243 spec_hasher::equal(spec_entry*, spec_entry*) /gcc/cp/pt.c:1725 0x90e5ae hash_table::find_slot_with_hash(spec_entry* const&, unsigned int, insert_option) /gcc/hash-table.h:981 0x8ad6bb add_mergeable_specialization(bool, spec_entry*, tree_node*, unsigned int) /gcc/cp/pt.c:30018 0x80bfb1 trees_in::decl_value() /gcc/cp/module.cc:8068 0x80dc47 trees_in::tree_node(bool) /gcc/cp/module.cc:9174 0x816a3b module_state::read_cluster(unsigned int) /gcc/cp/module.cc:14858 0x816dd4 module_state::load_section(unsigned int, binding_slot*) /gcc/cp/module.cc:18129 0x817d37 module_state::read_language(bool) /gcc/cp/module.cc:18058 0x81800a direct_import /gcc/cp/module.cc:18920 0x88c2b4 cp_parser_translation_unit /gcc/cp/parser.c:4905 0x88c2b4 c_parse_file() /gcc/cp/parser.c:45241 0xa0a37c c_common_parse_file() /gcc/c-family/c-opts.c:1218
[Bug c++/99547] [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547 --- Comment #1 from Christophe Lyon --- I read too quickly, on aarch64 the failing test is xtreme-header-3_c.C.
[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593 Christophe Lyon changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- I have updated the test in the initial description to call intrinsics, added relevant dg-* directives. Testing with several configurations under progress. Is it really r11-6708 that introduced the problem? It doesn't modify vshq unlike it's predecessor r11-6707-g7432f255b70811dafaf325d94036ac580891de69. And that one only moves the offending pattern from neon.md to vec-common.md, so the bug was probably already present? As of -mtune=generic-armv7-a, I can reproduce the ICE with -mcpu=generic-armv7-a, but I haven't found a -march equivalent (-march=armv7-a+fp does not trigger the ICE)
[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593 --- Comment #7 from Christophe Lyon --- Created attachment 50412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50412&action=edit proposed testcase Here is a proposal for a testcase derived from the initial description: - added relevant dg-* directives - replaced builtin calls with intrinsics Jakub, Kyrill, is that OK with you?
[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593 --- Comment #12 from Christophe Lyon --- I have tests in progress too (with and without the fix), except that I have typedef uint32x4_t i; instead of typedef uint32x2_t i; and I replaced the (__builtin_neon_hi *) cast with (int16_t*)
[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593 --- Comment #14 from Christophe Lyon --- I can confirm that the new test (as described in comment #12) works: - alone it results in ICE in the relevant configurations (skipped otherwise) - with the patch, it passes in the relevant configurations (skipped otherwise)
[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #13 from Christophe Lyon --- For arm yes, but according to gcc-testresults, it's failing on ia64 and s390 too, at least.
[Bug target/99665] New: GCC can generate FPU instructions not supported by the .fpu directive it emits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99665 Bug ID: 99665 Summary: GCC can generate FPU instructions not supported by the .fpu directive it emits Product: gcc Version: 11.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: --- While looking at the gcc.target/arm/simd/vmmla_1.c testcase, I noticed that when GCC is configured --target=arm-none-linux-gnueabihf --with-float=hard --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16 and invoked with -march=armv8.2-a+i8mm only (ie. no -mfpu, no -mfloat-abi option) we have #define __ARM_FEATURE_MATMUL_INT8 1, (so check_effective_target_arm_v8_2a_i8mm_ok_nocache decides no float-abi/fpu option is necessary) and the generated code has: .arch armv8.2-a .fpu neon-fp16 vsmmla.s8 q0, q1, q2 this instruction is not supported by neon-fp16, but the compiler still decided it could generate it. Using -mfpu=auto fixes this by emitting .fpu neon-fp-armv8, but it seems surprising that the compiler generates illegal code.
[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99593 --- Comment #18 from Christophe Lyon --- Not a big deal if you forget, that's a detail :-)
[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724 --- Comment #4 from Christophe Lyon --- Oops sorry, indeed it's likely that several of my other patches in this area introduced the same problem. I did lots of 'make check' though, too bad iwmmxt isn't covered well.
[Bug target/99724] [11 Regression] CE in in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724 --- Comment #6 from Christophe Lyon --- Looks good to me, thanks
[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99727 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-23 Ever confirmed|0 |1 --- Comment #2 from Christophe Lyon --- Looks like a constraint problem: I kept the Um constraint as used by Neon, while MVE needs Ux. This patch fixes the ICE: diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md index 440fd6a..1351863 100644 --- a/gcc/config/arm/mve.md +++ b/gcc/config/arm/mve.md @@ -10858,7 +10858,7 @@ (define_insn "arm_vcx3q_p_v16qi" ) (define_insn "*movmisalign_mve_store" - [(set (match_operand:MVE_VLD_ST 0 "neon_permissive_struct_operand" "=Um") + [(set (match_operand:MVE_VLD_ST 0 "neon_permissive_struct_operand" "=Ux") (unspec:MVE_VLD_ST [(match_operand:MVE_VLD_ST 1 "s_register_operand" " w")] UNSPEC_MISALIGNED_ACCESS))] "((TARGET_HAVE_MVE && VALID_MVE_SI_MODE (mode)) @@ -10871,7 +10871,7 @@ (define_insn "*movmisalign_mve_store" (define_insn "*movmisalign_mve_load" [(set (match_operand:MVE_VLD_ST 0 "s_register_operand" "=w") - (unspec:MVE_VLD_ST [(match_operand:MVE_VLD_ST 1 "neon_permissive_struct_operand" " Um")] + (unspec:MVE_VLD_ST [(match_operand:MVE_VLD_ST 1 "neon_permissive_struct_operand" " Ux")] UNSPEC_MISALIGNED_ACCESS))] "((TARGET_HAVE_MVE && VALID_MVE_SI_MODE (mode)) || (TARGET_HAVE_MVE_FLOAT && VALID_MVE_SF_MODE (mode)))
[Bug target/99727] [11 Regression] MVE: ICE (segfault) in arm_print_operand at -O3 since r11-6616-g25bef689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99727 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Christophe Lyon --- Fixed
[Bug target/99773] New: ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
Bug ID: 99773
Summary: ARM v8.1-m MVE interaction with -mfloat-abi not clear
Product: gcc
Version: 11.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: ---
I noticed an unexpected linker error when compiling with
-march=armv8.1-m.main+mve -mfloat-abi=hard -mcpu=cortex-m55 -mthumb
error: /tmp/ccQvvmcJ.o uses VFP register arguments, ./XXX.exe does not
Using mve.fp instead of mve fixes that.
However, I'm used to -mfloat-abi=hard defining the eabi attribute:
Tag_ABI_VFP_args: VFP registers
Compiling
===
typedef int __attribute((vector_size(16))) v4si;
float g(float x, float y)
{
x += y;
return x;
}
v4si f(v4si x, v4si y)
{
return x + y;
}
===
with -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard
generates for f:
vadd.i32 q0, q0, q1
bx lr
which uses the MVE registers for the parameters, but the object files does not
have the Tag_ABI_VFP_args: VFP registers attribute I would expect.
It does have
Tag_MVE_arch: MVE Integer only
is that enough?
Is the current behavior expected or is there a bug?
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #3 from Christophe Lyon ---
I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
#define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
&& (bitmap_bit_p (arm_active_target.isa, \
isa_bit_vfpv2) \
|| bitmap_bit_p (arm_active_target.isa, \
isa_bit_mve)) \
&& TARGET_32BIT)
but that has other implications, like enabing VFP patterns: for instance
mulsf3_vfp becomes enabled, leading to a failure when builing libgcc (vmul.f32
is generated for powisf2, but rejected by the assembler)
So maybe we just change the condition to emit the attributes in arm_file_start?
Something like:
if (! TARGET_SOFT_FLOAT || TARGET_HAVE_MVE)
{
if ((TARGET_HARD_FLOAT && TARGET_VFP_SINGLE) || TARGET_HAVE_MVE)
arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);
if (TARGET_HARD_FLOAT_ABI || TARGET_HAVE_MVE)
arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
}
but that does not look very clean
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Looks like a similar problem to PR99724 and PR98849. IIUC, iwmmxt only supports mult:V4HI (see mulv4hi3_iwmmxt in iwmmxt.md), so the condition ARM_HAVE__ARITH on define_expand "mul3" in vec-common.md is not strict enough.
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 --- Comment #2 from Christophe Lyon --- This fixes the ICE: diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md index 48ee659..86563d9 100644 --- a/gcc/config/arm/vec-common.md +++ b/gcc/config/arm/vec-common.md @@ -103,7 +103,7 @@ (define_expand "mul3" [(set (match_operand:VDQWH 0 "s_register_operand") (mult:VDQWH (match_operand:VDQWH 1 "s_register_operand") (match_operand:VDQWH 2 "s_register_operand")))] - "ARM_HAVE__ARITH" + "ARM_HAVE__ARITH && (!TARGET_REALLY_IWMMXT || mode == V4HImode)" ) However, I am getting errors from the assembler: pr79904.s:29: Error: selected processor does not support `wldrd wr0,[r3]' in ARM mode pr79904.s:30: Error: selected processor does not support `wldrd wr2,.L2' in ARM mode pr79904.s:31: Error: selected processor does not support `wmulul wr0,wr0,wr2' in ARM mode pr79904.s:33: Error: selected processor does not support `wstrd wr0,[r3]' in ARM mode I am compiling with arm-eabi-gcc -mcpu=iwmmxt. These errors are unrelated to the PR, but I am wondering why they appear?
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 --- Comment #5 from Christophe Lyon --- Compiling with -march=armv8.1-m.main+mve -mfloat-abi=hard defines: TARGET_SOFT_FLOAT 1 TARGET_HARD_FLOAT 0 TARGET_HARD_FLOAT_ABI 1 TARGET_VFP_SINGLE 1 so indeed what you propose does the trick. (Sorry I proposed comment #3 yesterday too in a hurry)
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Christophe Lyon changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Christophe Lyon --- I'd like to submit the small patch I proposed in comment #2, but I have a trouble writing a testcase that is accepted by the assembler as described. The testcase would be the same as ubsan/pr79904.c, with the addition of V4HI vectors.
[Bug fortran/93660] Decl mismatch between fndecl TYPE and used arglist / ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #7 from Christophe Lyon --- Hi, the new test fails on aarch64: FAIL: gfortran.dg/gomp/declare-simd-coarray-lib.f90 -O (test for excess errors) Excess errors: /gcc/testsuite/gfortran.dg/gomp/declare-simd-coarray-lib.f90:8:18: Warning: GCC does not currently support mixed size types for 'simd' functions
[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773 Christophe Lyon changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Christophe Lyon --- Fixed
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed
[Bug target/99937] Optimization needed for ARM with single cycle multiplier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99937 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- Note that gcc also has another -mcpu: cortex-m0plus.small-multiply
[Bug c++/99547] [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99547 --- Comment #3 from Christophe Lyon --- Apparently not, the last occurrence was with r11-7662 (g:9844eeff5abd129fab5a4cbd004b814c073a95a1)
[Bug target/97726] simd intrinsics tests fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97726 --- Comment #3 from Christophe Lyon --- Almost, but I still see vstn_lane_bf16_1.c failures in check-function-bodies on armeb. vdot-2-[12].c still fail, but I see failures on little-endian configs too, so probably a different issue (I didn't check the logs/details)
[Bug target/100049] New: loop counter double increment with longjmp inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049
Bug ID: 100049
Summary: loop counter double increment with longjmp inside
Product: gcc
Version: 11.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 50572
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50572&action=edit
Example code
As described in https://bugs.linaro.org/show_bug.cgi?id=5755
the following loop:
for(i = 0; i < CNT; i++) {
printf("Message %d\n", i);
if (setjmp((&ctx.jmp_buf[ctx.cnt])->env) == 0) {
++ctx.cnt;
do_jump();
--ctx.cnt;
}
}
has the following output:
Message 0
Message 2
It's sufficient to use -O2, and the offending code sequence is:
bl _setjmp
(*) ldr w1, [sp, 44]
add w1, w1, 1
str w1, [sp, 44]
cbnzw0, .L3
[]
bl do_jump (which calls longjmp)
where w1 contains "i", the line marked (*) is where longjmp jumps to.
So "i" is incremented before calling longjmp, and a second time when longjmp
gives control back to the test() function.
The attached archive contains:
helper.h, helper.c
example.c
Makefile
[Bug target/100049] loop counter double increment with longjmp inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049 --- Comment #3 from Christophe Lyon --- Thanks for the prompt answers! I did notice that putting the code into a single source file made behave "as expected". I did check the longjmp docs but unfortunately missed the section describing this case near the end.
[Bug target/100049] loop counter double increment with longjmp inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049 --- Comment #4 from Christophe Lyon --- Actually 'man longjmp' says: The compiler may optimize variables into registers, and longjmp() may restore the values of other registers in addition to the stack pointer and program counter. Consequently, the values of automatic variables are unspecified after a call to longjmp() if they meet all the follow‐ ing criteria: • they are local to the function that made the corresponding setjmp() call; • their values are changed between the calls to setjmp() and longjmp(); and • they are not declared as volatile. In this case, "i" is not modified between setjmp() and longjmp(), but it seems the compiler moves the increment between them.
[Bug target/100049] loop counter double increment with longjmp inside
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100049 --- Comment #7 from Christophe Lyon --- I'm told that -fno-sched-interblock helps
[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- Unfortunately this is causing many regressions in the GCC testsuite. For instance: --target arm-none-linux-gnueabi --with-mode arm --with-cpu cortex-a9 --with-fpu default gcc.target/arm/armv8_2-fp16-neon-1.c is compiled with -mfloat-abi=softfp -march=armv8.2-a+fp16 /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c: In function 'test_vceqz_16x4': /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: warning: implicit declaration of function 'vceqz_f16'; did you mean 'vceqq_u16'? [-Wimplicit-function-declaration] /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:10:25: note: in definition of macro 'MSTRCAT' /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:1: note: in expansion of macro 'VCMP1_TEST' /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: error: incompatible types when returning type 'int' but 'uint16x4_t' was expected [...] --target arm-none-linux-gnueabi --with-mode arm --with-cpu cortex-a9 --with-fpu default Dejagnu flags: -march=armv5t gcc.target/arm/aes-fuse-1.c is compiled with -march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72 cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch '-march=armv5t' FAIL: gcc.target/arm/aes-fuse-1.c (test for excess errors) For a full picture of the regressions I noticed: https://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/r11-8168-gd1e4368ddb76a92c44f824c8e4ca1a3de8149342/report-build-info.html (click on "log" to download the corresponding gcc.log and see the error messages) (you can ignore the regressions in g++, they are caused by a previous commit)
[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 --- Comment #5 from Christophe Lyon --- (In reply to Richard Earnshaw from comment #4) > (In reply to Christophe Lyon from comment #3) > > Unfortunately this is causing many regressions in the GCC testsuite. > > Sigh! I'm not entirely surprised. I suspect most of this is testisms, > though. > :-) Yes, probably. > > --target arm-none-linux-gnueabi > > --with-mode arm > > --with-cpu cortex-a9 > > --with-fpu default > > Dejagnu flags: -march=armv5t > > gcc.target/arm/aes-fuse-1.c is compiled with > > > > -march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72 > > cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch > > '-march=armv5t' > > The warning is correct. That's a stupid combination to pass to the compiler > (arch=armv5 and cpu=). What's less clear is why this wasn't > happening before. Indeed. I just checked the command line was the same before your patch (i.e. your patch has no impact on the effective-targets that could change the flags used) FTR, even before your patch there were several such annoying warnings.
[Bug libstdc++/100179] New: [12 regression] xtreme-header-2_a.H fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179 Bug ID: 100179 Summary: [12 regression] xtreme-header-2_a.H fails on arm-eabi Product: gcc Version: 11.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: --- Between r11-8253 and r12-12, I've noticed new failures on arm-eabi (using newlib) g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-2_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm) g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-2_c.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-5_a.H -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-5_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm) g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-6_a.H -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-6_a.H -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-6_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header-6_a.H.gcm) g++.dg/modules/xtreme-header-6_b.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-6_b.C -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header-6_c.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header-6_c.C -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors) g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors) g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) g++.log says: FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/bits/semaphore_base.h:259:4: error: #error "No suitable semaphore implementation available" /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:43:42: error: '__semaphore_impl' has not been declared /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:47:42: error: '__semaphore_impl' has not been declared /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:49:7: error: '__semaphore_impl' does not name a type /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:66:57: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:70:35: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:74:39: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:53:11: error: class 'std::counting_semaphore<__least_max_value>' does not have any field named '_M_sem' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:67:9: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:71:9: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:75:16: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:80:18: error: '_M_sem' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:85:18: error: '_M_sem' was not declared in this scope /gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: warning: not writing module '/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H' due to errors
[Bug libstdc++/100179] [12 regression] xtreme-header-2_a.H fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179 --- Comment #1 from Christophe Lyon --- Similar errors noticed in libstdc++ testsuite: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors) 17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors) 17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors) 17_intro/headers/c++2020/all_pedantic_errors.cc (test for excess errors) 17_intro/headers/c++2020/operator_names.cc (test for excess errors) 17_intro/headers/c++2020/stdc++.cc (test for excess errors) 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess errors) 20_util/polymorphic_allocator/allocate_object.cc (test for excess errors) 20_util/polymorphic_allocator/construct_c++2a.cc (test for excess errors) 20_util/polymorphic_allocator/lwg3237.cc (test for excess errors) 20_util/scoped_allocator/construct_pair_c++2a.cc (test for excess errors) 20_util/uses_allocator/make_obj.cc (test for excess errors) 21_strings/basic_string/hash/hash_char8_t.cc (test for excess errors) 24_iterators/normal_iterator/cmp_c++20.cc (test for excess errors) 27_io/basic_istringstream/cons/char/1.cc (test for excess errors) 27_io/basic_istringstream/cons/wchar_t/1.cc (test for excess errors) 27_io/basic_istringstream/str/char/2.cc (test for excess errors) 27_io/basic_istringstream/str/wchar_t/2.cc (test for excess errors) 27_io/basic_ostringstream/cons/char/1.cc (test for excess errors) 27_io/basic_ostringstream/cons/wchar_t/1.cc (test for excess errors) 27_io/basic_ostringstream/str/char/3.cc (test for excess errors) 27_io/basic_ostringstream/str/wchar_t/3.cc (test for excess errors) 27_io/basic_stringbuf/cons/char/2.cc (test for excess errors) 27_io/basic_stringbuf/cons/wchar_t/2.cc (test for excess errors) 27_io/basic_stringbuf/str/char/4.cc (test for excess errors) 27_io/basic_stringbuf/str/wchar_t/4.cc (test for excess errors) 27_io/basic_stringstream/cons/char/1.cc (test for excess errors) 27_io/basic_stringstream/cons/wchar_t/1.cc (test for excess errors) 27_io/basic_stringstream/str/char/5.cc (test for excess errors) 27_io/basic_stringstream/str/wchar_t/5.cc.cc (test for excess errors) 27_io/basic_syncbuf/basic_ops/1.cc (test for excess errors) 27_io/basic_syncstream/basic_ops/1.cc (test for excess errors)
[Bug libstdc++/100180] New: experimental/net/internet/address/v6/members.cc fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180 Bug ID: 100180 Summary: experimental/net/internet/address/v6/members.cc fails on arm-eabi Product: gcc Version: 9.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: --- The new test experimental/net/internet/address/v6/members.cc fails on arm-eabi (using newlib). On gcc-9, I'm seeing these errors in the logs: FAIL: experimental/net/internet/address/v6/members.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:509: error: 'mutex' in namespace 'std' does not name a type /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556: error: 'mutex' is not a member of 'std' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556: error: 'mutex' is not a member of 'std' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556: error: template argument 1 is invalid /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556: error: 'class std::experimental::net::v1::execution_context' has no member named '_M_mutex' [...] I think I saw similar errors on trunk a few days ago, but didn't have time to report them earlier.
[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180 --- Comment #2 from Christophe Lyon --- On trunk, the error message is: FAIL: experimental/net/internet/address/v6/members.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:602: error: '__fdvec' is not a member of 'std::experimental::net::v1::io_context::__reactor' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:677: error: 'struct std::experimental::net::v1::io_context::__reactor' has no member named 'wait' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:677: error: '__fds' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:679: error: '_S_retry' is not a member of 'std::experimental::net::v1::io_context::__reactor' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:682: error: '_S_timeout' is not a member of 'std::experimental::net::v1::io_context::__reactor' [...]
[Bug target/98143] arm: missed vectorization with MVE compared to Neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98143 --- Comment #1 from Christophe Lyon --- Current trunk generates for MVE: ldr r3, .L3+16 @ 5 [c=12 l=4] *thumb2_movsi_vfp/5 vldr.64 d6, .L3 @ 7 [c=8 l=4] *mve_movv8hi/8 vldr.64 d7, .L3+8 ldr r3, [r3]@ 14[c=12 l=4] *thumb2_movsi_vfp/5 mov r2, r3 @ 17[c=4 l=2] *thumb2_movsi_vfp/0 addsr3, r3, #16 @ 18[c=4 l=2] *thumb2_addsi_short/1 vstrh.16q3, [r2]@ 8 [c=8 l=4] *movmisalignv8hi_mve_store vstrh.16q3, [r3]@ 11[c=8 l=4] *movmisalignv8hi_mve_store bx lr @ 45[c=8 l=4] *thumb2_return .L4: .align 3 .L3: .short 3 .short 3 .short 3 .short 3 .short 3 .short 3 .short 3 .short 3
[Bug libstdc++/100179] [12 regression] xtreme-header-2_a.H fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179 --- Comment #6 from Christophe Lyon --- Yes, I confirm it's now fixed, thanks!
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 --- Comment #3 from Christophe Lyon --- Well, why does the warning remove the extensions? (+) It seems to indicate they are not taken into account, which is confusing: it doesn't really say why there is a conflict. Why do you think -mcpu=cortex-m55+nomve -march=armv8.1-m.main should conflict? It's not clear to me when I look at arm-cpus.in
[Bug testsuite/97426] [11 regression] new test case gcc.dg/ipa/modref-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97426 Christophe Lyon changed: What|Removed |Added Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu ||aarch64 arm CC||clyon at gcc dot gnu.org --- Comment #1 from Christophe Lyon --- Seen on arm & aarch64 too
[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757 --- Comment #4 from Christophe Lyon --- Yes I still see FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 378) for arm-none-linux-gnueabihf --with-cpu=cortex-a5 arm-none-eabi -mcpu=cortex-m[034] but for instance arm-none-linux-gnueabihf --with-cpu=cortex-a9 works.
[Bug tree-optimization/96376] [11 regression] vect/vect-alias-check.c and vect/vect-live-5.c fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96376 --- Comment #3 from Christophe Lyon --- I mentioned the configuration flags above: --target armeb-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16
[Bug tree-optimization/97494] [11 regression] several vector test case failures starting with r11-3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97494 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- Similar problems seen on arm too.
[Bug tree-optimization/97513] New: [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 Bug ID: 97513 Summary: [11 regression] aarch64 SVE regressions since r11-3822 Product: gcc Version: 11.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: --- Since r11-3822 (g:7e7352b2ad089ea68d689f3b79d93e3ee26326f7), I have noticed several aarch64/SVE regressions: gcc.target/aarch64/sve/mask_load_slp_1.c -march=armv8.2-a+sve scan-assembler-times \\tld1w\\t 48 gcc.target/aarch64/sve/mask_load_slp_1.c -march=armv8.2-a+sve scan-assembler-times \\tst1w\\t 40 gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times \\tld1d\\t 15 gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times \\tst1d\\t 15 gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecd\\t 6 gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecw\\t 9 gcc.target/aarch64/sve/slp_10.c -march=armv8.2-a+sve scan-assembler-times \\twhilelo\\tp[0-7]\\.d 30 gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times \\tld1d\\t 15 gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times \\tst1d\\t 15 gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecd\\t 6 gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecw\\t 9 gcc.target/aarch64/sve/slp_12.c -march=armv8.2-a+sve scan-assembler-times \\twhilelo\\tp[0-7]\\.d 30 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tld1d\\t 6 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #25\\n 2 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #31\\n 2 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #41\\n 2 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #62\\n 2 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, x[0-9]+\\n 3 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tst1d\\t 6 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecd\\t 3 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\twhilelo\\tp[0-7]\\.d 12 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tzip1\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 9 gcc.target/aarch64/sve/slp_3.c -march=armv8.2-a+sve scan-assembler-times \\tzip2\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 3 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-not \\tldr gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tld1d\\t 12 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tld1rd\\tz[0-9]+\\.d, 18 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tld1w\\t 6 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #11\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #17\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #24\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #37\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #63\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #80\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #81\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, #99\\n 2 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.d, x[0-9]+\\n 4 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tst1d\\t 12 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tst1w\\t 6 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecd\\t 6 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tuqdecw\\t 6 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\twhilelo\\tp[0-7]\\.d 24 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\twhilelo\\tp[0-7]\\.s 12 gcc.target/aarch64/sve/slp_4.c -march=armv8.2-a+sve scan-assembler-times \\tzip1\\tz[0-9]+\\.d, z[0-9]+\\.d, z[0-9]+\\.d\\n 33 gcc.target/aarch64/s
[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 --- Comment #2 from Christophe Lyon --- Right, but the builds were broken before that (did not work with gcc-4.8.5 on the host), so I didn't notice this problem ealier.
[Bug tree-optimization/97616] New: [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97616 Bug ID: 97616 Summary: [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428 Product: gcc Version: 11.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: --- Since r11-4428 (g:4a369d199bf2f34e037030b18d0da923e8a24997) I have noticed regressions on arm: FAIL: gcc.dg/vect/bb-slp-58.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-58.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "transform load" 2 FAIL: gcc.dg/vect/bb-slp-58.c scan-tree-dump-times slp1 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-58.c scan-tree-dump-times slp1 "transform load" 2 FAIL: gcc.dg/vect/bb-slp-59.c -flto -ffat-lto-objects scan-tree-dump-times loopdone "VEC_PERM_EXPR" 1 FAIL: gcc.dg/vect/bb-slp-59.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-59.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "transform load" 2 FAIL: gcc.dg/vect/bb-slp-59.c scan-tree-dump-times loopdone "VEC_PERM_EXPR" 1 FAIL: gcc.dg/vect/bb-slp-59.c scan-tree-dump-times slp1 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-59.c scan-tree-dump-times slp1 "transform load" 2 The expected patterns are found 0 times.
[Bug tree-optimization/97616] [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97616 Christophe Lyon changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/97616] [11 regression] bb-slp-58.c and bb-slp-59.c fail on arm after r11-4428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97616 --- Comment #1 from Christophe Lyon --- Actually these are not regressions, but new failures since the tests were just added.
[Bug tree-optimization/96967] [11 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96967 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- Sorry comment #4 is unrelated to this PR, I made a typo and meant PR96767.
[Bug target/96767] -mpure-code produces indirect loads for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Christophe Lyon --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:4d9af90d6a216822fe117337fb9836ba656dc3af commit r11-4598-g4d9af90d6a216822fe117337fb9836ba656dc3af Author: Christophe Lyon Date: Mon Nov 2 07:31:22 2020 + arm: Avoid indirection with -mpure-code on v6m (PR96967) With -mpure-code on v6m (thumb-1), to avoid a useless indirection when building the address of a symbol, we want to consider SYMBOL_REF as a legitimate constant. This way, we build the address using a series of upper/lower relocations instead of loading the address from memory. This patch also fixes a missing "clob" conds attribute for thumb1_movsi_insn, needed because that alternative clobbers the flags. 2020-11-02 Christophe Lyon gcc/ PR target/96967 * config/arm/arm.c (thumb_legitimate_constant_p): Add support for disabled literal pool in thumb-1. * config/arm/thumb1.md (thumb1_movsi_symbol_ref): Remove. (*thumb1_movsi_insn): Add support for SYMBOL_REF with -mpure-code. gcc/testsuite PR target/96967 * gcc.target/arm/pure-code/pr96767.c: New test.
[Bug tree-optimization/97691] New: [11 regression] pr91293-3.c fails since r11-4614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97691 Bug ID: 97691 Summary: [11 regression] pr91293-3.c fails since r11-4614 Product: gcc Version: 11.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: --- Since commit r11-4614 (g:e881774d0dda6d5127eb8f0642f6edc16dc0b1e7), I've noticed: FAIL: gcc.dg/vect/pr91293-3.c execution test on arm and aarch64
[Bug middle-end/97699] New: [11 regression] zero-scratch-regs tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699 Bug ID: 97699 Summary: [11 regression] zero-scratch-regs tests fail on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Some of the recently added zero-scratch-regs-* tests fail on arm. For instance when configuring GCC --target arm-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16 I can see: FAIL: c-c++-common/zero-scratch-regs-10.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/zero-scratch-regs-11.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/zero-scratch-regs-9.c -Wc++-compat (test for excess errors) The logs say: /gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:77:1: sorry, unimplemented: '-fzero-call-used_regs' not supported on this target The other tests pass. BTW, there's a typo in the error message, it should say fzero-call-used-regs rather than fzero-call-used_regs (that is '-' instead of '_' before 'regs')
[Bug tree-optimization/97691] [11 regression] pr91293-3.c fails since r11-4614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97691 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christophe Lyon --- It is, thanks.
[Bug target/97726] New: simd intrinsics tests fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97726 Bug ID: 97726 Summary: simd intrinsics tests fail on armeb Product: gcc Version: 11.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: --- Several arm/simd tests fail on armeb (as opposed to arm): FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2_dup_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2q_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld2q_dup_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld3_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld3_dup_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld3q_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld3q_dup_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld4_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld4_dup_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld4q_bf16 FAIL: gcc.target/arm/simd/bf16_vldn_1.c check-function-bodies test_vld4q_dup_bf16 FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst2_bf16 FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst2q_bf16 FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst3_bf16 FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst3q_bf16 FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst4_bf16 FAIL: gcc.target/arm/simd/bf16_vstn_1.c check-function-bodies test_vst4q_bf16 FAIL: gcc.target/arm/simd/vdot-2-1.c (test for excess errors) FAIL: gcc.target/arm/simd/vdot-2-2.c (test for excess errors) FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies test_vld2_lane_bf16 FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies test_vld2q_lane_bf16 FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies test_vld3_lane_bf16 FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies test_vld3q_lane_bf16 FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies test_vld4_lane_bf16 FAIL: gcc.target/arm/simd/vldn_lane_bf16_1.c check-function-bodies test_vld4q_lane_bf16 FAIL: gcc.target/arm/simd/vmmla_1.c (test for excess errors) FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies test_vst2_lane_bf16 FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies test_vst2q_lane_bf16 FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies test_vst3_lane_bf16 FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies test_vst3q_lane_bf16 FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies test_vst4_lane_bf16 FAIL: gcc.target/arm/simd/vstn_lane_bf16_1.c check-function-bodies test_vst4q_lane_bf16 For instance when GCC is configured: --target armeb-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #7 from Christophe Lyon --- I see it again rather frequently since a couple of days ago. (cross x86_64 -> arm)
[Bug target/97727] New: bf16_vstN_lane_2 test fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97727
Bug ID: 97727
Summary: bf16_vstN_lane_2 test fails on aarch64_be
Product: gcc
Version: 11.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: ---
The intrinsics test bf16_vstN_lane_2.c fails on aarch64_be:
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O0
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O0
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O0
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O0
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O1
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O1
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O1
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O1
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler-times st2\\t{v0.h
- v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler-times st2\\t{v2.h
- v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler-times st4\\t{v0.h
- v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none scan-assembler-times st4\\t{v4.h
- v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times st2\\t{v0.h -
v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times st2\\t{v2.h -
v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times st4\\t{v0.h -
v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects scan-assembler-times st4\\t{v4.h -
v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O3 -g
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O3 -g
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O3 -g
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -O3 -g
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Og -g
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Og -g
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Og -g
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Og -g
scan-assembler-times st4\\t{v4.h - v7.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Os
scan-assembler-times st2\\t{v0.h - v1.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Os
scan-assembler-times st2\\t{v2.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c -Os
scan-assembler-times st4\\t{v0.h - v3.h}\\[2\\], \\[x0\\] 1
FAIL: gcc.target/aarch64/advsimd-intrinsics/bf16
[Bug ipa/97766] New: ipa/modref-2.c fails on 32 bits targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766 Bug ID: 97766 Summary: ipa/modref-2.c fails on 32 bits targets Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The new test gcc.dg/ipa/modref-2.c fails on arm and other 32-bits targets: FAIL: gcc.dg/ipa/modref-2.c scan-ipa-dump modref "Parm 1 param offset:0 offset:0 size:-1 max_size:64"
[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Christophe Lyon --- Fixed on trunk
[Bug tree-optimization/97875] New: suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
Bug ID: 97875
Summary: suboptimal loop vectorization
Product: gcc
Version: 11.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: ---
Looking at the code generated for gcc.target/arm/simd/mve-vsub_1.c:
#include
void test_vsub_i32 (int32_t * dest, int32_t * a, int32_t * b) {
int i;
for (i=0; i<4; i++) {
dest[i] = a[i] - b[i];
}
}
Compiled with -mfloat-abi=hard -mfpu=auto -march=armv8.1-m.main+mve -mthumb
-O3, we get:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r1, #4
addsr3, r2, #4
sub ip, r0, ip
subsr3, r0, r3
cmp ip, #8
it hi
cmphi r3, #8
bls .L2
orr r3, r2, r0
orrsr3, r3, r1
lslsr3, r3, #28
bne .L2
vldrw.32q3, [r1]
vldrw.32q2, [r2]
vsub.i32q3, q3, q2
vstrw.32q3, [r0]
bx lr
.L2:
ldr r3, [r1]
push{r4}
ldr r4, [r2]
subsr3, r3, r4
str r3, [r0]
ldr r4, [r2, #4]
ldr r3, [r1, #4]
subsr3, r3, r4
str r3, [r0, #4]
ldr r4, [r2, #8]
ldr r3, [r1, #8]
subsr3, r3, r4
str r3, [r0, #8]
ldr r3, [r1, #12]
ldr r2, [r2, #12]
ldr r4, [sp], #4
subsr3, r3, r2
str r3, [r0, #12]
bx lr
but only the short vectorized part is necessary:
vldrw.32q3, [r1]
vldrw.32q2, [r2]
vsub.i32q3, q3, q2
vstrw.32q3, [r0]
bx lr
Since the loop trip count is constant (=4), why isn't this better optimized?
If I declare 'dest' as __restrict__, I get something better, but still not
perfect:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
orr r3, r2, r0
orrsr3, r3, r1
lslsr3, r3, #28
bne .L2
vldrw.32q3, [r1]
vldrw.32q2, [r2]
vsub.i32q3, q3, q2
vstrw.32q3, [r0]
bx lr
.L2:
push{r4, r5}
ldr r3, [r1]
ldr r4, [r2]
subsr4, r3, r4
str r4, [r0]
ldr r3, [r1, #4]
ldr r4, [r2, #4]
subsr5, r3, r4
str r5, [r0, #4]
ldrdr4, r3, [r1, #8]
ldrdr5, r1, [r2, #8]
subsr4, r4, r5
subsr3, r3, r1
strdr4, r3, [r0, #8]
pop {r4, r5}
bx lr
Compiling for cortex-a9 and Neon:
-mfloat-abi=hard -mcpu=cortex-a9 -mfpu=neon -O3
test_vsub_i32:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r2, #4
addsr3, r1, #4
sub ip, r0, ip
subsr3, r0, r3
cmp ip, #8
it hi
cmphi r3, #8
bls .L2
vld1.32 {q8}, [r1]
vld1.32 {q9}, [r2]
vsub.i32q8, q8, q9
vst1.32 {q8}, [r0]
bx lr
.L2:
ldr r3, [r1]
push{r4}
ldr r4, [r2]
subsr3, r3, r4
str r3, [r0]
ldr r4, [r2, #4]
ldr r3, [r1, #4]
subsr3, r3, r4
str r3, [r0, #4]
ldr r4, [r2, #8]
ldr r3, [r1, #8]
subsr3, r3, r4
ldr r4, [sp], #4
str r3, [r0, #8]
ldr r3, [r1, #12]
ldr r2, [r2, #12]
subsr3, r3, r2
str r3, [r0, #12]
bx lr
But in this case adding __restrict__ works well:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vld1.32 {q8}, [r1]
vld1.32 {q9}, [r2]
vsub.i32q8, q8, q9
vst1.32 {q8}, [r0]
bx lr
[Bug target/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875 --- Comment #2 from Christophe Lyon --- Checking the Arm v8-M manual, my understanding is that this architecture does not support unaligned vector loads/stores. However, my understanding is that vldrw.32 accepts to load from addresses aligned on 32 bits, which is the case since a and b are pointers to int32_t.
[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 --- Comment #4 from Christophe Lyon --- Not quite: as of r11-5140, I see: FAIL: gcc.target/aarch64/sve/slp_perm_1.c -march=armv8.2-a+sve scan-assembler-times \\trevb\\tz[0-9]+\\.d, p[0-7]/m, z[0-9]+\\.d\\n 1 FAIL: gcc.target/aarch64/sve/slp_perm_2.c -march=armv8.2-a+sve scan-assembler-times \\trevb\\tz[0-9]+\\.s, p[0-7]/m, z[0-9]+\\.s\\n 1 FAIL: gcc.target/aarch64/sve/slp_perm_3.c -march=armv8.2-a+sve scan-assembler-times \\trevb\\tz[0-9]+\\.h, p[0-7]/m, z[0-9]+\\.h\\n 1 FAIL: gcc.target/aarch64/sve/slp_perm_6.c -march=armv8.2-a+sve scan-assembler-times \\ttbl\\tz[0-9]+\\.b, z[0-9]+\\.b, z[0-9]+\\.b\\n 1 FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #-32768\\n 3 FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #256\\n 3 FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.[hsd], p[0-7]/z, #2\\n 3 FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #-128\\n 1 FAIL: gcc.target/aarch64/sve/vcond_3.c -march=armv8.2-a+sve scan-assembler-times \\tmov\\tz[0-9]+\\.b, p[0-7]/z, #2\\n 1 gcc.target/aarch64/sve/loop_add_4.c started passing between r4882 and r4894.
[Bug libstdc++/97944] New: 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Bug ID: 97944 Summary: 30_threads/jthread/95989.cc fails randomly Product: gcc Version: 11.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: --- Since this new test was introduced, it fails randomly on arm, aarch64 and other targets (apparently powerpc, ia64, m68k according to gcc-testresults). The logs say: terminate called after throwing an instance of 'std::system_error' what(): Unknown error -8461584
[Bug libstdc++/97948] New: C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Bug ID: 97948 Summary: C++2a synchronization tests fail to link on arm Product: gcc Version: 11.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: --- These new tests fails to link on arm: 29_atomics/atomic_float/wait_notify.cc (test for excess errors) 29_atomics/atomic_integral/wait_notify.cc (test for excess errors) 29_atomics/atomic_ref/wait_notify.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' collect2: error: ld returned 1 exit status This happens for instance with arm-none-linux-gnueabi-gcc and compiling with -march=armv5t
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Christophe Lyon changed: What|Removed |Added Version|11.0|10.2.1 --- Comment #1 from Christophe Lyon --- This is also affects gcc-10
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 --- Comment #3 from Christophe Lyon --- My testing is with cross-compilers, binutils-2.34, glibc-2.29, host is RHEL7 x86_64. Note that Toon reported a failure on x86_64: https://gcc.gnu.org/pipermail/gcc-testresults/2020-November/630321.html
[Bug tree-optimization/98015] New: [11 regression] ICE in gimple_expand_vec_cond_expr since g:fddc7f0080f1f056c4d145451608ebd3e807422a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98015 Bug ID: 98015 Summary: [11 regression] ICE in gimple_expand_vec_cond_expr since g:fddc7f0080f1f056c4d145451608ebd3e807422a Product: gcc Version: 11.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: --- Since commit g:fddc7f0080f1f056c4d145451608ebd3e807422a, I have noticed ICEs on aarch64: Executed from: gcc.dg/dg.exp gcc.dg/pr96466.c (internal compiler error) Executed from: gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -O0 (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -O1 (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -O2 (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -O3 -g (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -Og -g (internal compiler error) gcc.target/aarch64/advsimd-intrinsics/p64_p128.c -Os (internal compiler error) Executed from: gcc.target/aarch64/aarch64.exp gcc.target/aarch64/pr65235_1.c (internal compiler error) Executed from: gcc.target/aarch64/simd/simd.exp gcc.target/aarch64/simd/int_comparisons_1.c (internal compiler error) gcc.target/aarch64/simd/int_comparisons_2.c (internal compiler error) gcc.target/aarch64/simd/vceq_poly_1.c (internal compiler error) Executed from: gcc.target/aarch64/aarch64.exp gcc.target/aarch64/singleton_intrinsics_1.c (internal compiler error) The log says: FAIL: gcc.dg/pr96466.c (internal compiler error) FAIL: gcc.dg/pr96466.c (test for excess errors) Excess errors: during GIMPLE pass: isel /gcc/testsuite/gcc.dg/pr96466.c:9:1: internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:145 0x106322c gimple_expand_vec_cond_expr /gcc/gimple-isel.cc:144 0x106456b gimple_expand_vec_exprs /gcc/gimple-isel.cc:267 0x106456b execute /gcc/gimple-isel.cc:318
[Bug tree-optimization/96075] [8 Regression] bogus alignment for negative step grouped access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #13 from Christophe Lyon --- The new test fails on gcc-9 on aarch64: FAIL: gcc.dg/vect/slp-46.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-46.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 The log says "pattern found 0 times"
[Bug tree-optimization/96075] [8 Regression] bogus alignment for negative step grouped access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075 --- Comment #15 from Christophe Lyon --- Yes, the test fails on gcc-10 too. I tried adding xfail vect_load_lanes in gcc-9, and it correctly makes the test XFAIL.
[Bug tree-optimization/98123] New: if-to-switch tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123 Bug ID: 98123 Summary: if-to-switch tests fail on arm Product: gcc Version: 11.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: --- The recently introduced if-to-switch-* tests fail on arm: gcc.dg/tree-ssa/if-to-switch-2.c scan-tree-dump iftoswitch "Condition chain with 3 BBs transformed into a switch statement." gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition chain with 3 BBs transformed into a switch statement." gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-5.c scan-tree-dump iftoswitch "Condition chain with 5 BBs transformed into a switch statement." gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition chain" When GCC is configured with: --target arm-none-linux-gnueabihf --with-mode thumb --with-cpu cortex-a5 --with-fpu vfpv3-d16-fp16 Configuring for cortex-a9 instead of cortex-a5 shows less failures, only: gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition chain" gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition chain"
[Bug tree-optimization/98123] if-to-switch tests fail on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123 Christophe Lyon changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Christophe Lyon --- Sorry I didn't reply earlier because I didn't have the most recent trunk results yet. What revision should have fixed them? With r11-5718 (g:4a3b9f48c3743c6737acdc93074d058c1603be2a) I still see: FAIL: gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition chain" FAIL: gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition chain" FAIL: gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition chain"
[Bug target/98143] New: arm: missed vectorization with MVE compared to Neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98143
Bug ID: 98143
Summary: arm: missed vectorization with MVE compared to Neon
Product: gcc
Version: 11.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: ---
While working on enabling auto-vectorization for MVE, I noticed a missed
optimization compared to Neon:
#include
uint16_t *dest;
void func()
{
int i;
for (i=0;i<16;i++)
dest[i]=3;
}
Compiled with -O3 -S -dp -mfloat-abi=hard -mfpu=auto -mcpu=cortex-a9 -mthumb:
func:
movwr3, #:lower16:.LANCHOR0 @ 15[c=4 l=4] *thumb2_movsi_vfp/4
vmov.i16q8, #3 @ v8hi @ 7 [c=4 l=4] *neon_movv8hi/2
movtr3, #:upper16:.LANCHOR0 @ 16[c=4 l=4] *arm_movt/0
ldr r3, [r3]@ 14[c=12 l=4] *thumb2_movsi_vfp/5
vst1.16 {q8}, [r3]! @ 8 [c=8 l=4] *movmisalignv8hi_neon_store
vst1.16 {q8}, [r3] @ 11[c=8 l=4] *movmisalignv8hi_neon_store
bx lr @ 44[c=8 l=4] *thumb2_return
Compiled with -O3 -S -dp -mfloat-abi=hard -mfpu=auto -march=armv8.1-m.main+mve
-mthumb:
func:
movsr2, #3 @ 7 [c=4 l=2] *thumb2_movsi_shortim
ldr r3, .L3 @ 5 [c=12 l=4] *thumb2_movsi_vfp/5
ldr r3, [r3]@ 6 [c=12 l=4] *thumb2_movsi_vfp/5
strhr2, [r3]@ movhi @ 9 [c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #2]@ movhi @ 12[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #4]@ movhi @ 15[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #6]@ movhi @ 18[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #8]@ movhi @ 21[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #10] @ movhi @ 24[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #12] @ movhi @ 27[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #14] @ movhi @ 30[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #16] @ movhi @ 33[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #18] @ movhi @ 36[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #20] @ movhi @ 39[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #22] @ movhi @ 42[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #24] @ movhi @ 45[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #26] @ movhi @ 48[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #28] @ movhi @ 51[c=4 l=4] *thumb2_movhi_vfp/4
strhr2, [r3, #30] @ movhi @ 54[c=4 l=4] *thumb2_movhi_vfp/4
bx lr @ 84[c=8 l=4] *thumb2_return
This PR is about building the const, as the problems with stores are probably
part of PR97875.
In summry, with Neon we build the constant vector with:
vmov.i16q8, #3 @ v8hi @ 7 [c=4 l=4] *neon_movv8hi/2
but with MVE:
movsr2, #3 @ 7 [c=4 l=2] *thumb2_movsi_shortim
and then store it as 16-bits value as many times as needed.
I haven't managed to understand why we can't make use of mve.md's mve_mov
where there is an alternative with "Dm", which should work?
[Bug target/94743] IRQ handler doesn't save scratch VFP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743 Christophe Lyon changed: What|Removed |Added Assignee|clyon at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #25 from Christophe Lyon --- Un-assigning myself: I do not plan to work more on this for the moment.
[Bug tree-optimization/95056] [11 Regression] slp-perm-9.c fails on aarch64 after gbc484e250990393e887f7239157cc85ce6fadcce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95056 --- Comment #4 from Christophe Lyon --- Yes, it started passing again with r11-4728 g:4d76079fdfa3d36ebd95ac8b489519945e8ee88f
[Bug c/98198] [11 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in decl_or_type_attrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198 --- Comment #2 from Christophe Lyon --- Can you check with gcc trunk? There were recent fixes in the handling of noinit/persistent attribute: g:762ca20364a590be2cb9c79c0101ccbff74b5de1
[Bug c/98198] [11 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in decl_or_type_attrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198 --- Comment #4 from Christophe Lyon --- This simple patch avoids the ICE: diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index 1d2ab7c..8847932 100644 --- a/gcc/c-family/c-attribs.c +++ b/gcc/c-family/c-attribs.c @@ -767,6 +767,10 @@ decl_or_type_attrs (tree node) return attrs; tree type = TREE_TYPE (node); + + if (type == error_mark_node) + return NULL_TREE; + return TYPE_ATTRIBUTES (type); }
[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- The new test if-to-switch-10.c fails on aarch64: FAIL: gcc.dg/tree-ssa/if-to-switch-10.c scan-tree-dump iftoswitch "Condition chain with [^\n\r]* BBs transformed into a switch statement."
[Bug tree-optimization/98182] [11 Regression] ICE: Segmentation fault (in gimple_verify_flow_info)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98182 --- Comment #8 from Christophe Lyon --- Indeed if-to-switch-1.c fails on aarch64 too, the other ones pass.
[Bug target/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875 --- Comment #4 from Christophe Lyon --- In both cases (Neon and MVE), DR_TARGET_ALIGNMENT is 8, so the decision to emit a useless loop tail comes from elsewhere. And yes, MVE vldrw.32 and vstrw.32 share the same alignment properties.
[Bug target/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875
--- Comment #5 from Christophe Lyon ---
Interestingly, if I make arm_builtin_support_vector_misalignment() behave the
same for MVE and Neon, the generated code (with __restrict__) becomes:
test_vsub_i32:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
push{r4, r5, r6, r7, r8, r9, r10, fp} @ 61[c=8 l=4]
*push_multi
ldrdr10, fp, [r1, #8] @ 75[c=8 l=4] *thumb2_ldrd
ldrdr6, r7, [r2, #8]@ 76[c=8 l=4] *thumb2_ldrd
ldr r4, [r2]@ 14[c=12 l=4] *thumb2_movsi_vfp/5
ldr r8, [r1]@ 9 [c=12 l=4] *thumb2_movsi_vfp/6
ldr r9, [r1, #4]@ 10[c=12 l=4] *thumb2_movsi_vfp/6
ldr r5, [r2, #4]@ 15[c=12 l=4] *thumb2_movsi_vfp/5
vmovd6, r8, r9 @ v4si @ 35[c=4 l=8] *mve_movv4si/1
vmovd7, r10, fp
vmovd4, r4, r5 @ v4si @ 36[c=4 l=8] *mve_movv4si/1
vmovd5, r6, r7
sub sp, sp, #16 @ 62[c=4 l=4] *arm_addsi3/11
mov r3, sp @ 37[c=4 l=2] *thumb2_movsi_vfp/0
vsub.i32q3, q3, q2 @ 18[c=80 l=4] mve_vsubqv4si
vstrw.32q3, [r3]@ 34[c=4 l=4] *mve_movv4si/7
ldrdr4, r1, [sp]@ 77[c=8 l=4] *thumb2_ldrd_base
ldrdr2, r3, [sp, #8]@ 78[c=8 l=4] *thumb2_ldrd
strdr4, r1, [r0]@ 79[c=8 l=4] *thumb2_strd_base
strdr2, r3, [r0, #8]@ 80[c=8 l=4] *thumb2_strd
add sp, sp, #16 @ 66[c=4 l=4] *arm_addsi3/5
@ sp needed @ 67[c=8 l=0] force_register_use
pop {r4, r5, r6, r7, r8, r9, r10, fp} @ 68[c=8 l=4]
*load_multiple_with_writeback
bx lr @ 69[c=8 l=4] *thumb2_return
The Neon version has:
vld1.32 {q8}, [r1] @ 8 [c=8 l=4] *movmisalignv4si_neon_load
vld1.32 {q9}, [r2] @ 9 [c=8 l=4] *movmisalignv4si_neon_load
vsub.i32q8, q8, q9 @ 10[c=80 l=4] *subv4si3_neon
vst1.32 {q8}, [r0] @ 11[c=8 l=4] *movmisalignv4si_neon_store
bx lr @ 21[c=8 l=4] *thumb2_return
So it seems MVE needs movmisalign pattern.
[Bug target/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875 Christophe Lyon changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #6 from Christophe Lyon --- Indeed enabling movmisalign for MVE greatly helps.
[Bug target/96767] -mpure-code produces indirect loads for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96767 --- Comment #1 from Christophe Lyon --- Patch sent for review: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554956.html
[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770 --- Comment #1 from Christophe Lyon --- Patch sent for review: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554957.html
[Bug tree-optimization/97228] New: [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97228 Bug ID: 97228 Summary: [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36 Product: gcc Version: 11.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: --- Since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36, I have noticed several regressions on arm, for instance: --target arm-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16 FAIL: gcc.dg/tree-ssa/ifc-cd.c (internal compiler error) FAIL: gcc.dg/vect/pr59591-1.c (internal compiler error) FAIL: gcc.dg/vect/pr59591-1.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/slp-cond-5.c (internal compiler error) FAIL: gcc.dg/vect/slp-cond-5.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/vect-23.c (internal compiler error) FAIL: gcc.dg/vect/vect-23.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/vect-cond-reduc-6.c (internal compiler error) FAIL: gcc.dg/vect/vect-cond-reduc-6.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/pr59591-1.c (internal compiler error) FAIL: gcc.dg/vect/pr59591-1.c (test for excess errors) Excess errors: during RTL pass: expand /gcc/testsuite/gcc.dg/vect/pr59591-1.c:23:1: internal compiler error: in do_store_flag, at expr.c:12388 0x913726 do_store_flag /gcc/expr.c:12388 0x914e01 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /gcc/expr.c:9623 0x91d8d0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:10165 0xa37e6d expand_normal /gcc/expr.h:288 0xa37e6d expand_vect_cond_optab_fn /gcc/internal-fn.c:2602 0x7d28ef expand_call_stmt /gcc/cfgexpand.c:2612 0x7d28ef expand_gimple_stmt_1 /gcc/cfgexpand.c:3686 0x7d28ef expand_gimple_stmt /gcc/cfgexpand.c:3851 0x7d43bd expand_gimple_basic_block /gcc/cfgexpand.c:5892 0x7d6530 execute /gcc/cfgexpand.c:6576
[Bug tree-optimization/97228] [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97228 --- Comment #1 from Christophe Lyon --- It causes regressions in fortran too: gfortran.dg/assumed_rank_bounds_3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) gfortran.dg/assumed_rank_bounds_3.f90 -O3 -g (internal compiler error)
[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94595 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Christophe Lyon --- Fixed on trunk
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #1 from Christophe Lyon --- The following intrinsics are implemented, but not documented: __arm_vqrdmlashq_n_u8 __arm_vqrdmlahq_n_u8 __arm_vqdmlahq_n_u8 __arm_vqrdmlashq_n_u16 __arm_vqrdmlahq_n_u16 __arm_vqdmlahq_n_u16 __arm_vqrdmlashq_n_u32 __arm_vqrdmlahq_n_u32 __arm_vqdmlahq_n_u32 __arm_vmlaldavaxq_p_u32 __arm_vmlaldavaxq_p_u16
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #2 from Christophe Lyon --- Patch for __arm_vcvtnq_u32_f32 sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555485.html
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #3 from Christophe Lyon --- Patch for vqdmlash* sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555497.html
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #4 from Christophe Lyon --- (In reply to Christophe Lyon from comment #1) > The following intrinsics are implemented, but not documented: > __arm_vqrdmlashq_n_u8 > __arm_vqrdmlahq_n_u8 > __arm_vqdmlahq_n_u8 > __arm_vqrdmlashq_n_u16 > __arm_vqrdmlahq_n_u16 > __arm_vqdmlahq_n_u16 > __arm_vqrdmlashq_n_u32 > __arm_vqrdmlahq_n_u32 > __arm_vqdmlahq_n_u32 > __arm_vmlaldavaxq_p_u32 > __arm_vmlaldavaxq_p_u16 So, is the doc wrong (and my patch at comment #3 missing the unsigned versions), or should I prepare a patch to remove these?
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 --- Comment #6 from Christophe Lyon --- Thanks for the confirmation, I've just sent a patch to remove them: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/71.html
[Bug target/97312] New: [11 regression] aarch64/pr90838.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97312 Bug ID: 97312 Summary: [11 regression] aarch64/pr90838.c fails Product: gcc Version: 11.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: --- I've noticed that FAIL: gcc.target/aarch64/pr90838.c scan-assembler-times and\t 2 This appeared between r11-3681 (g:29c650cd899496c4f9bc069d03d0d7ecfb632176) and r11-3685 (g:fcae5121154d1c3382b056bcc2c563cedac28e74) but r11-3684 broke the toolchain build so the wrong commit may be either of those.
[Bug rtl-optimization/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 Christophe Lyon changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |11.0 Target||arm
[Bug rtl-optimization/97322] New: [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 Bug ID: 97322 Summary: [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Created attachment 49322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49322&action=edit preprocessed strtof_l.i Since r11-3671 (g:bf510679bb3f9bfd6019666065016bb26a5b5466), I've noticed an ICE while building the toolchains for arm. GCC crashes either while building glibc or newlib. I'm attaching a glibc reproducer: strtof_l.i arm-none-linux-gnueabihf-gcc strtof_l.i -O2 during RTL pass: expand In file included from strtof_l.c:45: strtod_l.c: In function 'strtof_l_internal': strtod_l.c:506:1: internal compiler error: in int_mode_for_mode, at stor-layout.c:404 506 | STRTOF_INTERNAL (const STRING_TYPE *nptr, STRING_TYPE **endptr, int group, | ^ 0xcf0afb int_mode_for_mode(machine_mode) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/stor-layout.c:404 0x92e70e emit_move_via_integer /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:3425 0x93e4fc emit_move_insn_1(rtx_def*, rtx_def*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:3793 0x93e82b emit_move_insn(rtx_def*, rtx_def*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/expr.c:3935 0x7dc96f emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode, int, std::pair*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/calls.c:5601 0x10d2f34 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, rtx_def*, machine_mode, rtx_def*, machine_mode) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/rtl.h:4258 0x10d2f34 arm_expand_divmod_libfunc /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/config/arm/arm.c:33280 0xa54846 expand_DIVMOD /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/internal-fn.c:3084 0x800fa7 expand_call_stmt /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:2612 0x800fa7 expand_gimple_stmt_1 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:3686 0x800fa7 expand_gimple_stmt /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:3851 0x80771b expand_gimple_basic_block /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:5892 0x809e0b execute /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/cfgexpand.c:6576
[Bug target/97322] [11 regression] ICE in int_mode_for_mode, at stor-layout.c:404 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97322 --- Comment #2 from Christophe Lyon --- Thanks, this patch does fix both builds for me.
[Bug target/97327] New: -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 Bug ID: 97327 Summary: -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- When compiling with -mthumb -mcpu=cortex-m55 I get: cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main' switch unless I add -mfloat-abi=hard or -march=armv8.1-m.main which is a bit counter-intuitive.
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 Christophe Lyon changed: What|Removed |Added Target||arm Target Milestone|--- |11.0
[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97327 --- Comment #1 from Christophe Lyon --- Similarly: -mcpu=cortex-m55+nomve -march=armv8.1-m.main+mve -mfloat-abi=softfp cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main' switch -mcpu=cortex-m55+nomve -march=armv8.1-m.main -mfloat-abi=softfp cc1: warning: switch '-mcpu=cortex-m55' conflicts with '-march=armv8.1-m.main' switch
[Bug target/96914] missing MVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96914 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Christophe Lyon --- Fixed on trunk
