[Bug tree-optimization/102516] [12/13 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 --- Comment #9 from Christophe Lyon --- Indeed it works again on trunk, I bisected and it started with one of our commits: r12-3958-g4c7731081647c22cbd249dc0faa20c3df9ed6411 Author: Richard Biener Date: Wed Sep 29 11:18:23 2021 +0200 Fix peeling for alignment with negative step The following fixes a regression causing us to no longer peel negative step loops for alignment. With dr_misalignment now applying the bias for negative step we have to do the reverse when adjusting the misalignment for peeled DRs. 2021-09-29 Richard Biener * tree-vect-data-refs.c (vect_dr_misalign_for_aligned_access): New helper. (vect_update_misalignment_for_peel): Use it to update misaligned to the value necessary for an aligned access. (vect_get_peeling_costs_all_drs): Likewise. (vect_enhance_data_refs_alignment): Likewise. * gcc.target/i386/vect-alignment-peeling-1.c: New testcase. * gcc.target/i386/vect-alignment-peeling-2.c: Likewise. We still have FAIL: gcc.dg/vect/pr65947-13.c scan-tree-dump-times vect "condition expression based on integer induction." 2 but based on the original report, this was already present
[Bug bootstrap/107119] Bootstrap ICE on 32-bit ARM after r13-2871-g1b74b5cb4e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107119 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #3 from Christophe Lyon --- It seems bootstrap is working on my side.
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #7 from Christophe Lyon --- Indeed, but I am surprised it seems to compile for cortex-m4?
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #5 from Christophe Lyon --- Could you share the preprocessed source file in the M3 and M4 cases along with the full command line used to compile it?
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #3 from Christophe Lyon --- Interesting Did you use the same target triplet? arm*-*-uclinuxfdpiceabi is handled differently from arm-buildroot-uclinux-uclibcgnueabi
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
At quick glance, I think this is caused by the definition of CLEAR_INSN_CACHE
in gcc/config/arm/uclinux-eabi.h:
/* Clear the instruction cache from `beg' to `end'. This makes an
inline system call to SYS_cacheflush. */
#undef CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END) \
{ \
register unsigned long _beg __asm ("a1") = (unsigned long) (BEG); \
register unsigned long _end __asm ("a2") = (unsigned long) (END); \
register unsigned long _flg __asm ("a3") = 0; \
register unsigned long _scno __asm ("r7") = 0xf0002; \
__asm __volatile ("swi 0x0@ sys_cacheflush" \
: "=r" (_beg) \
: "0" (_beg), "r" (_end), "r" (_flg), "r" (_scno)); \
}
which makes explicit use of r7.
This code has been like that since it was committed in 2007
So I suspect nobody ever tried to build this configuration.
[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 --- Comment #17 from Christophe Lyon --- I think Torbjorn is right, at the fix seems as simple as handling "-T" the same as "-Xlinker" in gcc_adjust_linker_flags_list. However, looking at the GCC documentation, under "Linker Options", I noticed: -e entry -u symbol -z keyword where although it is unlikely that 'entry', 'symbol' or 'keyword' actually return true to [file isfile $opt], there's still a possibility that someone uses e.g. -e file.o :-(
[Bug lto/106177] LTO interoperability Linux/Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177 --- Comment #4 from Christophe Lyon --- (In reply to Richard Weickelt from comment #3) > @Christophe Lyon, > > my use-case is that vendor A provides a binary blob of a library to vendor > B. Both A and B ensure that they use the same toolchain version, but the > developers involved use different host operating systems. LTO is a valuable > feature for us because it shrinks our binaries by 25%. Space is precious on > small MCUs. Thanks for the clarification, sorry that it won't be fixed soon :-(
[Bug lto/106177] New: LTO interoperability Linux/Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106177
Bug ID: 106177
Summary: LTO interoperability Linux/Windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hello,
As reported in https://bugs.linaro.org/show_bug.cgi?id=5859, when compiling C
code with gcc and -flto on a Linux host and linking the final binary on a
Windows host with exactly the same toolchain version, all float constants are
0, whereas the rest of the code seems valid. Code compiled with g++ is not
affected by this, only gcc.
Example code:
float test_float()
{
return 47.0;
}
Compilation:
arm-none-eabi-gcc -Os -flto -c test.c -o test.o
Dumping GIMPLE code on the same Linux host shows:
arm-none-eabi-lto-dump -dump-body=test_float test.o
test_float ()
{
[local count: 1073741824]:
return 4.7e+1;
}
Dumping GIMPLE code on a Windows host with the same toolchain release:
arm-none-eabi-lto-dump.exe -dump-body=test_float test.o
test_float ()
{
[local count: 1073741824]:
return 0.0e+0;
}
The original use-case is not clear to me (compiling on a Linux host, linking on
a Windows one), however I'm wondering whether LTO objects are supposed to be
interoperable in the way?
Maybe it's just a matter of how floating-point objects are encoded/decoded?
[Bug libgcc/105669] New: DFP to HF (_Float16) conversions use incorrect rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105669 Bug ID: 105669 Summary: DFP to HF (_Float16) conversions use incorrect rounding Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Support for conversions between DFP and _Float16 have been introduced with r13-687-g308a0af4f91324. For simplicity it uses intermediate conversions with SFmode, leading to double rounding which probably produces incorrectly rounded results. See also PR97635
[Bug target/105549] aarch64: Wrong va_arg alignment handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 Christophe Lyon changed: What|Removed |Added Known to fail||8.5.0, 9.4.1 --- Comment #1 from Christophe Lyon --- It already failed with gcc-9. With gcc-8 only the 2nd check failed.
[Bug target/105549] aarch64: Wrong va_arg alignment handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 Christophe Lyon changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org Severity|major |normal Target||aarch64
[Bug target/105549] New: aarch64: Wrong va_arg alignment handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Bug ID: 105549
Summary: aarch64: Wrong va_arg alignment handling
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. I reduced the problem to:
/* This test is derived from a case generated by struct-layout-1.exp: */
enum E6 { e6_0, e6_1, e6_2, e6_3, e6_65533 = 65533, e6_65534, e6_65535 };
typedef enum E6 Tal16E6 __attribute__((aligned (16)));
typedef unsigned int Tuint;
int fails;
union S2844 {
Tuint a:10) - 1) & 31) + 1);
Tal16E6 __attribute__((aligned (2), packed)) b:31;
struct{}c[0];
} ;
union S2844 s2844;
union S2844 a2844[5];
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
void check2844va (int z, ...) {
union S2844 arg, *p;
va_list ap;
__builtin_va_start(ap,z);
if (__builtin_va_arg(ap,double) != 1.0)
printf ("fail %d.%d\n", 2844, 0), ++fails;
p =
arg = __builtin_va_arg(ap,union S2844); /* This would fail. */
if (p->a != arg.a)
printf ("fail %d.%d\n", 2844, 1), ++fails;
if (__builtin_va_arg(ap,long long) != 3LL)
printf ("fail %d.%d\n", 2844, 2), ++fails;
p = [2];
arg = __builtin_va_arg(ap,union S2844); /* This would fail. */
if (p->a != arg.a)
printf ("fail %d.%d\n", 2844, 3), ++fails;
arg = __builtin_va_arg(ap,union S2844); /* This would fail. */
if (p->a != arg.a)
printf ("fail %d.%d\n", 2844, 4), ++fails;
__builtin_va_end(ap);
}
int main (void) {
int i, j;
memset (, '\0', sizeof (s2844));
memset (a2844, '\0', sizeof (a2844));
s2844.a = 799U;
a2844[2].a = 586U;
check2844va (1, 1.0, s2844, 2LL, a2844[2], a2844[2]);
exit (fails != 0);
}
This is a tough case mixing bitfields and alignment, where
aarch64_gimplify_va_arg_expr did not follow the exact same rule as
aarch64_layout_arg. When the va_arg parameter uses only one general
register, we do not want to introduce double-word alignment.
[Bug target/104662] arm: ice in simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Christophe Lyon --- Fixed on trunk.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #5 from Christophe Lyon --- > Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since > the test involves floats. I was wrong and your proposal of arm_v8_1m_mve_ok looks fine (since actually there is no ICE with compiling for an FP-capable FPU)
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #4 from Christophe Lyon --- Other MVE tests are in gcc.target/arm/simd/ (eg mve-vcmp-f32.c), maybe it's best to keep them in the same place? Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since the test involves floats. Thanks for the prompt fix!
[Bug target/104662] arm: ice in simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662 Christophe Lyon changed: What|Removed |Added Last reconfirmed||2022-04-25 Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug tree-optimization/105312] [11/12 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux since r12-834-ga6eacbf1055520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312 --- Comment #5 from Christophe Lyon --- Sorry for the breakage, my patch shouldn't have modified the behavior for Neon. I just moved the vcond_mask expander from neon.md to vec-common.md. With Neon, I think we should have both v4sfv4si and v2sfv2si, unlike MVE where the v2 variant does not exist.
[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 --- Comment #12 from Christophe Lyon --- The test in arm/simd/neon-vcmp.c currently fails, and passes with your candidate patch, thanks. (I wrote that test before the regression, and noticed it had regressed while working on my MVE/VCMP patche
[Bug tree-optimization/102516] [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 --- Comment #5 from Christophe Lyon --- Indeed. I know that vectorization does not work on armeb as well as on arm (little-endian), I was just wondering whether this regression was "expected"
[Bug target/104882] [12 Regression] MVE: Wrong code at -O2 since r12-1434-g046a3beb1673bf4a61c131373b6a5e84158e92bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed on trunk.
[Bug target/104882] [12 Regression] MVE: Wrong code at -O2 since r12-1434-g046a3beb1673bf4a61c131373b6a5e84158e92bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882 --- Comment #3 from Christophe Lyon --- Revert patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592136.html
[Bug target/104882] [12 Regression] MVE: Wrong code at -O2 since r12-1434-g046a3beb1673bf4a61c131373b6a5e84158e92bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-03-16
--- Comment #2 from Christophe Lyon ---
My understanding is that MVE's vmovn instructions do not work like Neon's.
If q0 = { 0x, 0x, 0x, 0 } ( 4x32 bits)
q1 = { 0x, 0x, 0x, 0x }
With Neon:
vmovn.i32 d4, q0 gives:
d4 = { 0x, 0x, 0x, 0 } (4x16 bits)
vmovn.i32 d5, q1 gives:
d5 = { 0x, 0x, 0x, 0x }
thus q2 = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0 }
But with MVE:
vmovnb.i32 q2, q0 gives:
q2 = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0 } (8x16 bits,
only the bottom bits of each 32 bits element are updated)
vmovnt.i32 q2, q1 then gives:
q2 = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0 } (only the
top bits are updated)
This means that the input should be shuffled before using MVE's vmovn[bt] to
have
q0 = { 0x, 0x, 0x, 0 }
q1 = { 0x, 0x, 0x, 0x }
since MVE's vmovn do not seem to naturally map to GCC's vec_pack_trunc
[Bug target/104662] arm: ice in simd_valid_immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Hello,
Do you mean you are running 'make check' with a cross-gcc configure with
--target arm-linux-gnueabif and you see this failure? On my side, 'make check'
shows no error on this test.
Given the flags you show, it seems you are in fact compiling the testcase by
hand, effectively not including the mandatory -march=armv8.1-m.main+mve?
V*BI types require MVE, so the test is not supposed to run without this option.
However, this small change avoids the ICE:
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index c1103d9..5adc45b 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -12811,6 +12811,9 @@ simd_valid_immediate (rtx op, machine_mode mode, int
inverse,
|| n_elts * innersize != 16))
return -1;
+ if (!TARGET_HAVE_MVE && (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL))
+ return -1;
+
/* Vectors of float constants. */
if (GET_MODE_CLASS (mode) == MODE_VECTOR_FLOAT)
{
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Christophe Lyon --- Should be fixed, at last.
[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Christophe Lyon --- Should be fixed, at last.
[Bug target/104144] [12 Regression] --enable-version-specific-runtime-libs fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- For background, I reported this some time ago: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584556.html
[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-6513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010 --- Comment #2 from Christophe Lyon --- Ha right, git gcc-descr with no argument didn't what I expected (ie. git gcc-descr HEAD after a bisect...) So I meant r12-3362 g:a3fb781d4b341c0d50ef1b92cd3e8734e673ef18
[Bug tree-optimization/104010] New: [12 regression] short loop no longer vectorized with Neon after r12-6513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
Bug ID: 104010
Summary: [12 regression] short loop no longer vectorized with
Neon after r12-6513
Product: gcc
Version: 12.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: ---
This short loop:
void test_vcmpeq_s32x2 (int32_t * __restrict__ dest, int32_t *a, int32_t *b)
{
int i;
for (i=0; i<4; i++) {
dest[i] = a[i] == b[i];
}
}
used to be vectorized as:
test_vcmpeq_s32x2:
vld1.32 {d16}, [r1]
vmov.i32d17, #0x1 @ v2si
vld1.32 {d19}, [r2]
vmov.i32d18, #0 @ v2si
vceq.i32d16, d16, d19
vbsld16, d17, d18
vst1.32 {d16}, [r0]
bx lr
After r12-6513, we get:
test_vcmpeq_s32x2:
ldr ip, [r1]
ldr r3, [r1, #4]
str lr, [sp, #-4]!
ldr lr, [r2]
ldr r2, [r2, #4]
sub ip, ip, lr
clz ip, ip
sub r3, r3, r2
lsr ip, ip, #5
clz r3, r3
lsr r3, r3, #5
str ip, [r0]
str r3, [r0, #4]
ldr pc, [sp], #4
when compiling for arm-none-linux-gnueabihf with -mcpu=cortex-a9 -mfpu=neon
[Bug target/103729] New: ls64 tests fail on aarch64 with -mabi=ilp32 and aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103729 Bug ID: 103729 Summary: ls64 tests fail on aarch64 with -mabi=ilp32 and aarch64_be Product: gcc Version: 12.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: --- Hi Przemyslaw, I have noticed that your recent patch r12-5955 (Add LS64 extension and intrinsics) introduced a few failures in the tests you added. On aarch64-none-elf -mabi=ilp32: gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b-2.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b-2.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b-3.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b-3.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld_st_o0.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld_st_o0.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv-2.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv-2.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv-3.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv-3.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv0-2.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv0-2.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv0-3.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv0-3.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv0.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_st64bv0.c (test for excess errors) with eg: Excess errors: during RTL pass: expand /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/gcc/include/arm_acle.h:227:10: internal compiler error: in maybe_legitimize_operand, at optabs.c:7717 0xd24324 maybe_legitimize_operand /gcc/optabs.c:7716 0xd24324 maybe_legitimize_operands(insn_code, unsigned int, unsigned int, expand_operand*) /gcc/optabs.c:7853 0xd2435d maybe_gen_insn(insn_code, unsigned int, expand_operand*) /gcc/optabs.c:7872 0xd245a8 maybe_expand_insn(insn_code, unsigned int, expand_operand*) /gcc/optabs.c:7915 0xd23b48 expand_insn(insn_code, unsigned int, expand_operand*) /gcc/optabs.c:7946 0x132b5f0 aarch64_expand_builtin_ls64 /gcc/config/aarch64/aarch64-builtins.c:2220 0x132b5f0 aarch64_general_expand_builtin(unsigned int, tree_node*, rtx_def*, int) /gcc/config/aarch64/aarch64-builtins.c:2519 0x8a9534 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) /gcc/builtins.c:6885 0xa2b3e5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /gcc/expr.c:11533 0x8da30c expand_expr /gcc/expr.h:301 0x8da30c expand_call_stmt /gcc/cfgexpand.c:2831 0x8da30c expand_gimple_stmt_1 /gcc/cfgexpand.c:3864 0x8da30c expand_gimple_stmt /gcc/cfgexpand.c:4028 0x8db4cc expand_gimple_tailcall /gcc/cfgexpand.c:4074 0x8db4cc expand_gimple_basic_block /gcc/cfgexpand.c:6046 0x8dd871 execute /gcc/cfgexpand.c:6795 On aarch64_be-none-elf: gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_asm.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_asm.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b-3.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b-3.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b.c (internal compiler error) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle/ls64_ld64b.c (test for excess errors) gcc:gcc.target/aarch64/acle/acle.exp=gcc.target/aarch64/acle
[Bug fortran/103662] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- (In reply to seurer from comment #5) > r12-5960 causes an issue at least on powerpc64. same problem on arm & aarch64
[Bug debug/103619] New: armeb ICE since r12-5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 Bug ID: 103619 Summary: armeb ICE since r12-5833 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r12-5833, I've noticed an ICE on armeb which prevents building the toolchain: during RTL pass: dwarf2 /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libbacktrace/dwarf.c: In function 'dwarf_lookup_pc': /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libbacktrace/dwarf.c:3885:1: internal compiler error: in dwf_cfa_reg, at dwarf2cfi.c:1139 3885 | } | ^ make[3]: Entering directory '/tmp/5562867_5.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-armeb-none-linux-gnueabihf/gcc3/armeb-none-linux-gnueabihf/libatomic' 0x8c97ca dwf_cfa_reg /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:1139 0x8ca275 dwarf2out_frame_debug_expr /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2131 0x8c9c27 dwarf2out_frame_debug_expr /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:1774 0x8cb21c dwarf2out_frame_debug /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2341 0x8cb21c scan_insn_after /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2700 0x8cd34c scan_trace /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2867 0x8cdfee create_cfi_notes /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2907 0x8cdfee execute_dwarf2_frame /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:3285 0x8cdfee execute /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:3773 GCC is configured with --target=armeb-none-linux-gnueabihf --disable-nls -- disable-libgomp --disable-libmudflap --disable-libcilkrts --enable-checking --enable-languages=c,c++,fortran --with-float=hard --enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16 Little-endian arm targets (arm-*) are still OK.
[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090 --- Comment #15 from Christophe Lyon --- Indeed I don't see that anymore.
[Bug tree-optimization/103298] New: [12 regressions] regressions on arm after r12-5301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103298 Bug ID: 103298 Summary: [12 regressions] regressions on arm after r12-5301 Product: gcc Version: 12.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: --- r12-5301 is causing regressions on some arm targets: arm-none-linux-gnueabi -march=armv7-a -mthumb: FAIL: gcc.target/arm/pr42093.c scan-assembler-not tbb FAIL: gcc.target/arm/pr43920-2.c object-size text <= 54 arm-none-linux-gnueabi -march=armv5t -mthumb: FAIL: gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition chain with [^\n\r]* BBs transformed into a switch statement."
[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #10 from Christophe Lyon --- After r12-5301, on aarch64 I can see: FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread2 "Jumps threaded: 18"
[Bug target/103272] New: failure to use vld20/vld21 to vectorize for ARM MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103272
Bug ID: 103272
Summary: failure to use vld20/vld21 to vectorize for ARM MVE
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: ---
With current GCC trunk with -mcpu=cortex-m55 -mfpu=auto
#include
typedef struct {
int16_t v1;
int16_t v2;
} data;
void test (data* restrict d, data* restrict x,
data* restrict y, uint32_t L) {
for (uint32_t i = 0; i < L*16; i++) {
d[i].v1 = x[i].v1*y[i].v1;
d[i].v2 = x[i].v2*y[i].v2;
}
}
we generate:
test:
lslsr3, r3, #4
beq .L9
lslsr3, r3, #2
push{lr}
sub lr, r3, #16
lsr lr, lr, #4
add lr, lr, #1
dls lr, lr
.L3:
vldrh.16q3, [r2], #16
vldrh.16q2, [r1], #16
vmul.i16q3, q3, q2
vstrh.16q3, [r0], #16
le lr, .L3
ldr pc, [sp], #4
.L9:
bx lr
while LLVM generates:
test:
push{r7, lr}
mov r7, sp
mov.w r12, #0
cmp.w r12, r3, lsl #4
it eq
popeq {r7, pc}
mvn r12, #7
add.w r12, r12, r3, lsl #4
movsr3, #1
add.w lr, r3, r12, lsr #3
.LBB0_2:
vld20.16{q0, q1}, [r1]
vld20.16{q2, q3}, [r2]
vld21.16{q0, q1}, [r1]!
vld21.16{q2, q3}, [r2]!
vmul.i16q0, q2, q0
vmul.i16q1, q3, q1
vst20.16{q0, q1}, [r0]
vst21.16{q0, q1}, [r0]!
le lr, .LBB0_2
pop {r7, pc}
OTOH, GCC vectorizes better the samples included in the testsuite
(gcc.target/arm/simd/mve-vld2.c)
[Bug other/103244] New: [12 regression] c-c++-common/goacc/firstprivate-mappings-1.c fails on arm since g:b7e20480630e3eeb9eed8b3941da3b3f0c22c969
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103244 Bug ID: 103244 Summary: [12 regression] c-c++-common/goacc/firstprivate-mappings-1.c fails on arm since g:b7e20480630e3eeb9eed8b3941da3b3f0c22c969 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- I have noticed a failure on arm since g:b7e20480630e3eeb9eed8b3941da3b3f0c22c969 FAIL: c-c++-common/goacc/firstprivate-mappings-1.c scan-tree-dump omplower "(?n)#pragma omp target oacc_parallel firstprivate\\(array_li.[0-9]+\\) map\\(from:array_so \\[len: 4\\]\\) \\["
[Bug middle-end/103243] New: [12 regression] pr98499.C fails after r12-5203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103243 Bug ID: 103243 Summary: [12 regression] pr98499.C fails after r12-5203 Product: gcc Version: 12.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: --- I've noticed failures on g++.dg/pr98499.C on arm and aarch64, which started somewhere between r12-5186 and r12-5203 FAIL: g++.dg/pr98499.C -std=gnu++14 execution test FAIL: g++.dg/pr98499.C -std=gnu++17 execution test FAIL: g++.dg/pr98499.C -std=gnu++2a execution test FAIL: g++.dg/pr98499.C -std=gnu++98 execution test
[Bug libstdc++/103166] New: [12 regression] wrong dependency on getentropy on newlib-based targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166 Bug ID: 103166 Summary: [12 regression] wrong dependency on getentropy on newlib-based targets Product: gcc Version: 12.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 r12-5066, I've noticed numerous link failures on aarch64-none-elf like: FAIL: g++.dg/concepts/expression.C -std=gnu++17 (test for excess errors) Excess errors: /libstdc++-v3/src/c++11/random.cc:179: undefined reference to `getentropy' /libstdc++-v3/src/c++11/random.cc:179:(.text._ZNSt12_GLOBAL__N_117__libc_getentropyEPv+0x10): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `getentropy' /libstdc++-v3/src/c++11/random.cc:452: undefined reference to `getentropy' /libstdc++-v3/src/c++11/random.cc:452:(.text._ZNSt13random_device7_M_initERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x68): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `getentropy' /aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/arc4random.c:89: undefined reference to `getentropy' /aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/arc4random.c:89:(.text+0x558): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `getentropy' Maybe there's something wrong with the detection of HAVE_GETENTROPY in configure?
[Bug testsuite/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #9 from Christophe Lyon ---
(In reply to Aldy Hernandez from comment #7)
> > then size ivopts-4.o:
> >textdata bss dec hex filename
> > 38 0 0 38 26 ivopts-4.o
> > where the testcase expects text <= 36
>
> Oh, this is an object size regression? This test seems very fragile.
> Jump threading will alter code size, so any change in the threading rules
> will likely have an effect on code size. I suggest you add
> -fno-thread-jumps to the test and adjust the object-size test accordingly.
I tried that, it doesn't change the generated code.
> This is a testsuite regression that must be fixed by the target maintainers,
> not a middle-end or tree-optimization regression. I've marked it as so.
>
Before your changes, we generated (with -mthumb
-march=armv7-a+mp+sec+neon-fp16)
tr2:
push{r4, r5, r6, lr}
cmp r1, #0
mov r4, r0
ble .L4
add r5, r0, r1, lsl #2
movsr6, #0
.L3:
mov r0, r4
addsr4, r4, #4
bl foo
cmp r4, r5
add r6, r6, r0
bne .L3
.L1:
mov r0, r6
pop {r4, r5, r6, pc}
.L4:
movsr6, #0
b .L1
After the jump-threading change (r12-4526):
tr2:
push{r4, r5, r6, lr}
cmp r1, #0
mov r4, r0
ble .L5
add r5, r0, r1, lsl #2
movsr6, #0
.L3:
cmp r4, r5
bne .L4
.L1:
mov r0, r6
pop {r4, r5, r6, pc}
.L4:
mov r0, r4
addsr4, r4, #4
bl foo
add r6, r6, r0
b .L3
.L5:
movsr6, #0
b .L1
[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 --- Comment #6 from Christophe Lyon --- (In reply to Aldy Hernandez from comment #5) > (In reply to Christophe Lyon from comment #4) > > If I'm not mistaken, if you click on "REGRESSED" for that specific line, > > you'll see that only ssa-dom-thread-7.c actually regressed with the > > corresponding flags. > > > > For ivopts-4.c, if seems you need -mthumb and one of these values for > > -march: > > armv7-a+mp+sec+neon-fp16 > > armv7ve+simd > > armv7-a+mp+sec+vfpv3-d16-fp16 > > armv8-a+crc+simd+crypto > > (possibly with -mfpu=auto) > > or -march=armv8-a -mfpu=crypto-neon-fp-armv8 > > Works for: > -Os -fdump-tree-ivopts -save-temps -S -march=armv8-a > -mfpu=crypto-neon-fp-armv8 > -Os -fdump-tree-ivopts -save-temps -S -mthumb -march=armv8-a > -mfpu=crypto-neon-fp-armv8 > -Os -fdump-tree-ivopts -save-temps -S -mthumb -march=armv7ve+simd -mfpu=auto > > Similarly for ssa-dom-thread-7.c. > > Perhaps someone else can reproduce. It fails for me with: cc1 -fpreprocessed ivopts-4.i -quiet -dumpbase ivopts-4.c -dumpbase-ext .c -mthumb -mfloat-abi=hard -mfpu=neon -mtls-dialect=gnu -mlibarch=armv7-a+mp+sec+neon-fp16 -march=armv7-a+mp+sec+neon-fp16 -Os -version -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-urls=never -fdiagnostics-path-format=separate-events -fdump-tree-ivopts -o ivopts-4.s the main compilation line is: arm-none-linux-gnueabihf-gcc -mthumb -march=armv7-a+mp+sec+neon-fp16 -fdiagnostics-plain-output -Os -fdump-tree-ivopts -save-temps -c -o ivopts-4.o /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/fixes/gcc/testsuite/gcc.target/arm/ivopts-4.c then size ivopts-4.o: textdata bss dec hex filename 38 0 0 38 26 ivopts-4.o where the testcase expects text <= 36 My GCC is configured with --with-float=hard --with-cpu=cortex-a9 --with-fpu=neon --with-mode=arm > > And just to be clear, it would be easier if someone could reproduce with a > cc1 / gcc command line, and not by pointing us to some table in a web page. Sorry, these automated validations builds are deleted after the reports are generated, so it's not really easier for me to manually reproduce than for anyone else.
[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 --- Comment #4 from Christophe Lyon --- If I'm not mistaken, if you click on "REGRESSED" for that specific line, you'll see that only ssa-dom-thread-7.c actually regressed with the corresponding flags. For ivopts-4.c, if seems you need -mthumb and one of these values for -march: armv7-a+mp+sec+neon-fp16 armv7ve+simd armv7-a+mp+sec+vfpv3-d16-fp16 armv8-a+crc+simd+crypto (possibly with -mfpu=auto) or -march=armv8-a -mfpu=crypto-neon-fp-armv8
[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 --- Comment #2 from Christophe Lyon --- Yes, I can still see failures with r12-4820
[Bug target/102907] New: aarch64/shrn-combine-[123].c fail with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102907 Bug ID: 102907 Summary: aarch64/shrn-combine-[123].c fail with SVE Product: gcc Version: 12.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: --- Hi Tamar, I have noticed that the new tests shrn-combine-[123].c fail when running the tests with -march=armv8.3-a+sve: PASS: gcc.target/aarch64/shrn-combine-1.c (test for excess errors) gcc.target/aarch64/shrn-combine-1.c: \\tshrn\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-1.c scan-assembler-times \\tshrn\\t 1 gcc.target/aarch64/shrn-combine-1.c: \\tshrn2\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-1.c scan-assembler-times \\tshrn2\\t 1 PASS: gcc.target/aarch64/shrn-combine-2.c (test for excess errors) gcc.target/aarch64/shrn-combine-2.c: \\tshrn\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-2.c scan-assembler-times \\tshrn\\t 1 gcc.target/aarch64/shrn-combine-2.c: \\tshrn2\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-2.c scan-assembler-times \\tshrn2\\t 1 PASS: gcc.target/aarch64/shrn-combine-3.c (test for excess errors) gcc.target/aarch64/shrn-combine-3.c: \\tshrn\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-3.c scan-assembler-times \\tshrn\\t 1 gcc.target/aarch64/shrn-combine-3.c: \\tshrn2\\t found 0 times FAIL: gcc.target/aarch64/shrn-combine-3.c scan-assembler-times \\tshrn2\\t 1 (and similarly with -march=armv8.5-a+sve2) I haven't checked the actual generated code.
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #5 from Christophe Lyon --- Sure, I just filed PR 102906 for the ivopts-4.c issue on arm.
[Bug middle-end/102906] New: [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906 Bug ID: 102906 Summary: [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526 Product: gcc Version: 12.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: --- Since r12-4526 (g:d8edfadfc7a9795b65177a50ce44fd348858e844) I have noticed regressions on some arm targets for gcc.target/arm/ivopts-4.c For instance on arm-none-linux-gnueabihf --with-arch armv7-a+mp+sec+neon-fp16 FAIL: gcc.target/arm/ivopts-4.c object-size text <= 36 But this depends on the actual target & runtestflags, see: https://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844/report-build-info.html
[Bug fortran/102815] gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Christophe Lyon --- I confirm it is now fixed, thanks!
[Bug middle-end/102857] New: [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 Bug ID: 102857 Summary: [12 regression] r12-4526 caused regressions on vect/bb-slp-16.c and ssa-dom-thread-7.c Product: gcc Version: 12.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: --- r12-4526 (g:d8edfadfc7a9795b65177a50ce44fd348858e844) caused regressions. On aarch64 and arm-none-linux-gnueabihf with-arch armv7-a+mp+sec+neon-fp16 FAIL: gcc.dg/vect/bb-slp-16.c execution test On both aarch64/arm FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 12" On arm-none-linux-gnueabihf --with-arch armv7-a+mp+sec+neon-fp16 FAIL: gcc.target/arm/ivopts-4.c object-size text <= 36 The last one is very fragile and depends on the actual target/flags.
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #15 from Christophe Lyon --- Hi, yes this is close to completion. The patch series was approved last week by Richard Sandiford: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581778.html but I have found a bug with more validations, I'm discussing the fix with him, should be ready shortly.
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 --- Comment #6 from Christophe Lyon --- I think it's better too, so this essentially means removing gcc.target/aarch64/pr89093.c, but since Jakub's patch was specifically about leading spaces, I was wondering whether I was missing something.
[Bug target/102375] [aarch64] Should allow space in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- Hi, it seems you forgot to update gcc.target/aarch64/pr89093.c, which now fails: FAIL: gcc.target/aarch64/pr89093.c (test for errors, line 4) FAIL: gcc.target/aarch64/pr89093.c (test for errors, line 5) FAIL: gcc.target/aarch64/pr89093.c (test for errors, line 6) However there was a long discussion in PR89093, among which a small patch "Don't skip whitespace at the start of target attribute string"
[Bug fortran/102815] New: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Bug ID: 102815 Summary: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The new test gfortran.dg/bind-c-contiguous-5.f90 fails on armeb (arm big-endian), such as armeb-linux-gnueabihf: The output contains: At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_f' abcghinop defghijlm At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_in_f' abcghinop defghijlm At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_f' abcghinop defghijlm At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_in_f' abcghinop defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_in_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop defghijlm abcghinop defghijlm At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_shape_cont_f' abcghinop defghijlm At line 1131 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created
[Bug middle-end/102808] New: [12 regression] sve/mask_gather_load_1.c fails since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102808 Bug ID: 102808 Summary: [12 regression] sve/mask_gather_load_1.c fails since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217 Product: gcc Version: 12.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: --- Hi, Since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217, I have noticed a few regressions in the aarch64 tests: FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_1.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_2.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_3.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_4.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_7.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 36 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_scatter_store_1.c scan-assembler-times \\tst1d\\tz[0-9]+\\.d, p[0-7], \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_scatter_store_2.c scan-assembler-times \\tst1d\\tz[0-9]+\\.d, p[0-7], \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- (In reply to H.J. Lu from comment #3) > On Linux/x86, it also caused: > > FAIL: 27_io/ios_base/failure/dual_abi.cc execution test Same on arm and aarch64
[Bug tree-optimization/102720] [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720 --- Comment #6 from Christophe Lyon --- On aarch64, this also causes gcc.dg/loop-unswitch-4.c to fail
[Bug tree-optimization/102720] [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org Target|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu, |powerpc64le-linux-gnu, |x86_64-linux-gnu|x86_64-linux-gnu, arm, ||aarch64 --- Comment #5 from Christophe Lyon --- Seen on arm and aarch64 too
[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 --- Comment #13 from Christophe Lyon --- Sure, here is what I have in libstdc++.log: In file included from /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/net:42, from /libstdc++-v3/testsuite/experimental/net/headers.cc:20: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1575: error: 'sockaddr_in' does not name a type /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1576: error: 'sockaddr_in6' does not name a type /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet: In member function 'constexpr std::size_t std::experimental::net::v1::ip::basic_endpoint<_InternetProtocol>::size() const': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1561: error: 'sockaddr_in6' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1561: error: 'sockaddr_in' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet: In member function 'constexpr bool std::experimental::net::v1::ip::basic_endpoint<_InternetProtocol>::_M_is_v6() const': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1580: error: 'AF_INET6' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet: At global scope: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1710: error: 'AI_PASSIVE' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1711: error: 'AI_CANONNAME' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1712: error: 'AI_NUMERICHOST' was not declared in this scope compiler exited with status 1 FAIL: experimental/net/headers.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1575: error: 'sockaddr_in' does not name a type /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1576: error: 'sockaddr_in6' does not name a type /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1561: error: 'sockaddr_in6' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1561: error: 'sockaddr_in' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1580: error: 'AF_INET6' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1710: error: 'AI_PASSIVE' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1711: error: 'AI_CANONNAME' was not declared in this scope /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/experimental/internet:1712: error: 'AI_NUMERICHOST' was not declared in this
[Bug target/102604] arm v7m_extra_costs for SFmode inaccurate?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102604 --- Comment #2 from Christophe Lyon --- Right, using -Os makes these tests pass (but vsqrt.f32 and vsqrt.f64 would fail), but I'm still wondering about the purpose of vmla? Rather than benchmarking, the costs may come from the Architecture documentation? But then, if vmla is so costly, when is it supposed to be used? Only when optimizing for size? Note that the DP/f64 version does not have this problem.
[Bug target/102604] New: arm v7m_extra_costs for SFmode inaccurate?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102604 Bug ID: 102604 Summary: arm v7m_extra_costs for SFmode inaccurate? Product: gcc Version: 12.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 have noticed that gcc.target/arm/vfp-1.c fails when targeting cortex-m7 (-mthumb -mfloat-abi=hard -march=armv7e-m+fp.dp): FAIL: gcc.target/arm/vfp-1.c scan-assembler vmla.f32 FAIL: gcc.target/arm/vfp-1.c scan-assembler vmls.f32 FAIL: gcc.target/arm/vfp-1.c scan-assembler vnmla.f32 FAIL: gcc.target/arm/vfp-1.c scan-assembler vnmls.f32 The DP (f64) versions PASS. This is because v7m_extra_costs for SP contains: COSTS_N_INSNS (2),/* mult. */ COSTS_N_INSNS (5),/* mult_addsub. */ COSTS_N_INSNS (1),/* addsub. */ So when combine tries to replace mutl + addsub into a single mult_addsub, the cost of the latter is still higher than two separate instructions. I suppose these values are the result of benchmarking, but it seems to mean that vmla is never going to be selected by the compiler.
[Bug tree-optimization/102516] [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 --- Comment #3 from Christophe Lyon --- The target name is armeb-linux-gnueabi or armeb-linux-gnueabihf
[Bug middle-end/102517] New: [12 regression] regressions on aarch64 since r12-3899
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102517 Bug ID: 102517 Summary: [12 regression] regressions on aarch64 since r12-3899 Product: gcc Version: 12.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: --- Since r12-3899 (g:d06dc8a2c73735e9496f434787ba4c93ceee5eea), I have noticed regressions on aarch64: FAIL: gcc:gcc.dg/dg.exp=gcc.dg/out-of-bounds-1.c (test for warnings, line 12) gcc.dg/pr78408-1.c: pattern found 15 times FAIL: gcc:gcc.dg/dg.exp=gcc.dg/pr78408-1.c scan-tree-dump-times fab1 "after previous" 17 FAIL: gcc:gcc.target/aarch64/aarch64.exp=gcc.target/aarch64/cpymem-q-reg_1.c scan-assembler ldp\\tq[0-9]* FAIL: gcc:gcc.target/aarch64/aarch64.exp=gcc.target/aarch64/cpymem-q-reg_1.c scan-assembler stp\\tq[0-9]*
[Bug middle-end/102516] New: [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 Bug ID: 102516 Summary: [12 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893 Product: gcc Version: 12.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: --- Since r12-3893 (g:6390c5047adb75960f86d56582e6322aaa4d9281), I've noticed regressions on armeb targets: gcc.dg/vect/pr65947-13.c: pattern found 1 times FAIL: gcc.dg/vect/pr65947-13.c scan-tree-dump-times vect "LOOP VECTORIZED" 2 gcc.dg/vect/pr65947-13.c -flto -ffat-lto-objects : pattern found 1 times FAIL: gcc.dg/vect/pr65947-13.c -flto -ffat-lto-objects scan-tree-dump-times vect "LOOP VECTORIZED" 2 FAIL: gcc:gcc.dg/vect/vect.exp=gcc.dg/vect/vect-alias-check-18.c -flto -ffat-lto-objects scan-tree-dump vect "using an index-based WAR/WAW test" FAIL: gcc:gcc.dg/vect/vect.exp=gcc.dg/vect/vect-alias-check-18.c scan-tree-dump vect "using an index-based WAR/WAW test"
[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017 --- Comment #3 from Christophe Lyon --- I made a typo in my description of the bug, it should read: fenv support is NOW enabled.
[Bug target/102411] New: arm/vfp18.c fails with -march=armv7e-m+fp for cortex-m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102411
Bug ID: 102411
Summary: arm/vfp18.c fails with -march=armv7e-m+fp for
cortex-m4
Product: gcc
Version: 12.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: ---
When running the testsuite with -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp and
simulating for cortex-m4, I noticed that gcc.target/arm/vfp18.c fails at
execution.
The testcase contains:
void myfunc(__fp16, float, double, float, __fp16, int) ;
int main()
{
myfunc(1.0f, 2.0f, 4.0, 2.0f, 1.0f, 3);
}
The testcase is compiled with:
-mthumb -mfloat-abi=hard -march=armv7e-m+fp -mfpu=vfpv4 -mfp16-format=ieee
For main we generate:
push{r7, lr}@ 27[c=8 l=2] *push_multi
add r7, sp, #0 @ 28[c=4 l=4] *arm_addsi3/4
movsr0, #3 @ 5 [c=4 l=2] *thumb2_movsi_shortim
movwr3, #15360 @ 23[c=4 l=8] *movhf_vfp/6
vmovs5, r3 @ 6 [c=4 l=4] *movhf_vfp/4
vmov.f32s4, #2.0e+0 @ 7 [c=4 l=4] *thumb2_movsf_vfp/2
vmov.f64d1, #4.0e+0 @ 8 [c=4 l=4] *thumb2_movdf_vfp/2
vmov.f32s1, #2.0e+0 @ 9 [c=4 l=4] *thumb2_movsf_vfp/2
vmovs0, r3 @ 10[c=4 l=4] *movhf_vfp/4
bl myfunc @ 11[c=8 l=4] *call_symbol
movsr3, #0 @ 12[c=4 l=2] *thumb2_movsi_shortim
mov r0, r3 @ 19[c=4 l=2] *thumb2_movsi_vfp/0
pop {r7, pc}@ 31[c=8 l=2]
*pop_multiple_with_writeback_and_return
The problem is the vmov.f64 instruction which is not supported by cortex-m4
since it has a single-precision-only FPU.
Running under QEMU with -cpu cortex-m7 passes, as expected.
The problem comes from -mfpu=vfpv4, which is added by arm_fp16_hw (indirectly
from check_effective_target_arm_fp16_ok_nocache)
Indeed arm-cpus.in says:
begin fpu vfpv4
isa VFPv4 FP_D32
end fpu vfpv4
so it enables double-precision support.
Looks like a testism, since we effectively override -march=armv7e-m+fp with
-mfpu=vfpv4, but maybe a warning would be helpful?
And something to disable the test or make it pass.
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 Christophe Lyon changed: What|Removed |Added CC||akhilesh.k at samsung dot com --- Comment #7 from Christophe Lyon --- *** Bug 90721 has been marked as a duplicate of this bug. ***
[Bug target/90721] [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Christophe Lyon --- I think this is a dup of PR69538 *** This bug has been marked as a duplicate of bug 69538 ***
[Bug target/102309] New: thumb2-replicated-constant2.c fails on cortex-m7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102309 Bug ID: 102309 Summary: thumb2-replicated-constant2.c fails on cortex-m7 Product: gcc Version: 12.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 gcc.target/arm/thumb2-replicated-constant2.c fails when targeting cortex-m7. For instance for the first fonction, for cortex-m4 we generate: foo1: add r0, r0, #-33489408 addsr0, r0, #1 bx lr for cortex-m7, we generate: foo1: mov r3, r0 ldr r0, .L3 add r0, r0, r3 bx lr .L4: .align 2 .L3: .word -33489407 This is because arm_cortex_m7_tune has 0 in constant_limit, while the generic arm_v7m_tune has 1. This setting has been in place since r5-4680 in 2014, see https://gcc.gnu.org/pipermail/gcc-patches/2014-November/403718.html Since it was the result of benchmarking, I guess this is a feature, not a bug? Is this really faster?
[Bug target/102173] [12 Regression] ICEs gcc.target/aarch64/sve/acle/general-c/type_redef_1.c after recent error recovery patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102173 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- Appeared after r12-3278 g:823685221de986afb729910a6f2237f07a377f17
[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #16 from Christophe Lyon --- (In reply to Richard Earnshaw from comment #15) > (In reply to Christophe Lyon from comment #14) > > I think you forgot to backport > > r12-2790-ga22b3e022c2b45047a28d901042888eb77620499 to gcc-9 ? > > I don't think so. I think that patch collapsed away due to the way I ended > up resolving a merge conflict in an earlier patch. > > Are you seeing any test errors due to this? Ha, right, there's no check-function-bodies in gcc-9. I'm seeing: FAIL: gcc.target/arm/attr-neon3.c scan-assembler-times vld1 1 on armeb, but that was already the case before your backport to gcc-9, so it's not related.
[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- I think you forgot to backport r12-2790-ga22b3e022c2b45047a28d901042888eb77620499 to gcc-9 ?
[Bug tree-optimization/102072] New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 --- Comment #3 from Christophe Lyon --- Indeed, so I don't think this is a dup
[Bug target/102072] New: New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072 Bug ID: 102072 Summary: New test case gcc.dg/vect/pr101145_3.c in r12-3136 fails on armeb Product: gcc Version: 12.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 newly introduced test causes an ICE on armeb (arm big-endian, little-endian is fine). For instance --target armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16: FAIL: gcc.dg/vect/pr101145.c (internal compiler error) FAIL: gcc.dg/vect/pr101145.c (test for excess errors) Excess errors: during GIMPLE pass: aprefetch /gcc/testsuite/gcc.dg/vect/pr101145.c:6:1: internal compiler error: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 0xf343cd determine_exit_conditions /gcc/tree-ssa-loop-manip.c:1049 0xf343cd tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*, tree_niter_desc*, void (*)(loop*, void*), void*) /gcc/tree-ssa-loop-manip.c:1255 0xf4a51b loop_prefetch_arrays /gcc/tree-ssa-loop-prefetch.c:1966 0xf4a51b tree_ssa_prefetch_arrays() /gcc/tree-ssa-loop-prefetch.c:2032
[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 --- Comment #8 from Christophe Lyon --- Sorry I am still seeing errors on trunk and gcc-11: FAIL: experimental/net/socket/socket_base.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v8-m.main/nofp/libstdc++-v3/include/experimental/socket:717: error: 'linger' is not a member of 'std::experimental::net::v1::socket_base' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v8-m.main/nofp/libstdc++-v3/include/experimental/socket:898: error: 'shutdown_type' has not been declared [...] FAIL: experimental/net/headers.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v8-m.main/nofp/libstdc++-v3/include/experimental/socket:717: error: 'linger' is not a member of 'std::experimental::net::v1::socket_base' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v8-m.main/nofp/libstdc++-v3/include/experimental/socket:898: error: 'shutdown_type' has not been declared [...] FAIL: experimental/net/socket/basic_socket.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v8-m.main/nofp/libstdc++-v3/include/experimental/socket:717: error: 'linger' is not a member of 'std::experimental::net::v1::socket_base' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v8-m.main/nofp/libstdc++-v3/include/experimental/socket:898: error: 'shutdown_type' has not been declared On some configs (low end CPU), I get in addition: FAIL: experimental/net/timer/waitable/cons.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/bin/ld: /cc6v7KWK.o: in function `_ZNSt13__atomic_baseIjEmmEv': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include/bits/atomic_base.h:386: undefined reference to `__atomic_fetch_sub_4' collect2: error: ld returned 1 exit status FAIL: experimental/net/timer/waitable/dest.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/bin/ld: /ccKgSt10.o: in function `_ZNSt13__atomic_baseIjEppEv': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include/bits/atomic_base.h:378: undefined reference to `__atomic_fetch_add_4' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/bin/ld: /ccKgSt10.o: in function `_ZNSt13__atomic_baseIjEmmEv': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include/bits/atomic_base.h:386: undefined reference to `__atomic_fetch_sub_4' collect2: error: ld returned 1 exit status FAIL: experimental/net/timer/waitable/ops.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/bin/ld: /cc5uZ7RA.o: in function `_ZNSt13__atomic_baseIjEppEv': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include/bits/atomic_base.h:378: undefined reference to `__atomic_fetch_add_4' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/bin/ld: /cc5uZ7RA.o: in function `_ZNSt13__atomic_baseIjEmmEv': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include/bits/atomic_base.h:386: undefined reference to `__atomic_fetch_sub_4' collect2: error: ld returned 1 exit status but that's a different problem
[Bug target/102018] gcc.dg/torture/pr82692.c execution fails on arm cortex-m7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018 --- Comment #2 from Christophe Lyon --- Yes probably. I noticed it when upgrading newlib from 3.3.0 to 4.1.0, which enabled new GCC tests.
[Bug libstdc++/90787] filesystem tests fail if file permissions are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90787 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #5 from Christophe Lyon --- After r12-3045, I see regressions on bare-metal, newlib based targets (arm-eabi, aarch64-elf): FAIL: 27_io/filesystem/path/append/path.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-eabi/bin/ld: /ccrhrvyi.o: in function `_ZN10__gnu_test24permissions_are_testableEb': /libstdc++-v3/testsuite/util/testsuite_fs.h:168: undefined reference to `geteuid' collect2: error: ld returned 1 exit status UNRESOLVED: 27_io/filesystem/path/append/path.cc compilation failed to produce executable 48 tests have a similar error: libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/append/path.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/append/source.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/assign/assign.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/assign/copy.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/compare/compare.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/compare/lwg2936.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/compare/path.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/compare/strings.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/concat/92853.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/concat/path.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/concat/strings.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/construct/copy.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/construct/range.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/construct/string_view.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/extension.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/filename.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/parent_path.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/relative_path.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/root_directory.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/root_name.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/root_path.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/decompose/stem.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/generation/normal.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/generation/proximate.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/generation/relative.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/generic/generic_string.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/itr/components.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/itr/traversal.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/modifiers/clear.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/modifiers/make_preferred.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/modifiers/remove_filename.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/modifiers/replace_extension.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/modifiers/replace_filename.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/modifiers/swap.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/nonmember/append.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/nonmember/cmp.cc (test for excess errors) libstdc++:libstdc++-dg/conformance.exp=27_io/filesystem/path/nonmember/cmp_c++20.cc (test for excess errors
[Bug analyzer/102020] New: [12 regression] analyzer/malloc-callbacks.c fails since r12-3052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102020 Bug ID: 102020 Summary: [12 regression] analyzer/malloc-callbacks.c fails since r12-3052 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r12-3052 (g:e92d0ff6b5e6d4b95c04fc3e326d40efeb136086), there is a new failure: FAIL: gcc.dg/analyzer/malloc-callbacks.c (test for excess errors) Excess errors: /gcc/testsuite/gcc.dg/analyzer/malloc-callbacks.c:72:3: warning: double-'free' of 'ptr' [CWE-415] [-Wanalyzer-double-free] Seen on arm and aarch64
[Bug target/102018] New: gcc.dg/torture/pr82692.c execution fails on arm cortex-m7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102018 Bug ID: 102018 Summary: gcc.dg/torture/pr82692.c execution fails on arm cortex-m7 Product: gcc Version: 12.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: --- gcc.dg/torture/pr82692.c fails at execution time when targeting cortex-m7 at -O1, -O2, -O3 and LTO configs, but passes at -O0 and -Os: FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/pr82692.c -O1 execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/pr82692.c -O2 execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/pr82692.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/pr82692.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/pr82692.c -O3 -g execution test
[Bug libgcc/102017] New: libgcc ieee754-df.S for arm does not support exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017
Bug ID: 102017
Summary: libgcc ieee754-df.S for arm does not support
exceptions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As stated in libgcc/config/arm/ieee754-df.S:
* Exceptions aren't supported yet, but that can be added quite easily
* if necessary without impacting performances.
Since I upgraded the newlib version I use in validation (moved from 3.3.0 to
4.1.0), fenv support is not enabled, thus enabling new tests in the GCC
testsuite.
Some of them fail at execution time on some targets because the code in libgcc
does not raise exception as those tests expect:
gcc.dg/torture/float32x-nan.c
gcc.dg/torture/float64-nan.c
gcc.dg/torture/inf-compare-1.c
gcc.dg/torture/inf-compare-2.c
gcc.dg/torture/inf-compare-3.c
gcc.dg/torture/inf-compare-4.c
gcc.dg/torture/pr52451.c
This happens when targeting cortex-m4 or cortex-m33/-march=armv8-m.main+fp+dsp.
These tests pass when targeting cortex-m7, because it has a DP FPU, and does
not use the libgcc emulation code.
Some of these tests already have xfail { powerpc*-*-* } or dg-skip-if "fenv" {
powerpc-ibm-aix* }, but I am not sure whether and how we want to do this on arm
(maybe using a dg-skip-if checking for -mcpu/march, but that could be painful).
Or do we want to update libgcc to raise exceptions properly?
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 --- Comment #13 from Christophe Lyon --- This is also related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
[Bug libstdc++/101056] std::compare_partial_order_fallback missing the constraint of "F < E is well-formed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101056 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- On gcc-11, since r11-8848, I've noticed an ICE on arm-none-linux-gnueabi (arm-none-linux-gnueabihf is OK): FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors) Excess errors: /gcc/testsuite/g++.dg/modules/xtreme-header-5_b.C:4:30: internal compiler error: in add_mergeable_specialization, at cp/pt.c:30084 0x8b245f add_mergeable_specialization(bool, bool, spec_entry*, tree_node*, unsigned int) /gcc/cp/pt.c:30084 0x81099a trees_in::decl_value() /gcc/cp/module.cc:8075 0x8123c7 trees_in::tree_node(bool) /gcc/cp/module.cc:9155 0x81aaeb module_state::read_cluster(unsigned int) /gcc/cp/module.cc:14813 0x81ae84 module_state::load_section(unsigned int, binding_slot*) /gcc/cp/module.cc:18084 0x81bde7 module_state::read_language(bool) /gcc/cp/module.cc:18013 0x81c0ba direct_import /gcc/cp/module.cc:18879 0x890a64 cp_parser_translation_unit /gcc/cp/parser.c:4907 0x890a64 c_parse_file() /gcc/cp/parser.c:45324 0xa101dc c_common_parse_file() /gcc/c-family/c-opts.c:1218 trunk and gcc-10 seem OK.
[Bug tree-optimization/101890] [12 regression] ICEs on aarch64 after r12-2836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101890 Christophe Lyon changed: What|Removed |Added Target Milestone|--- |12.0 Target||aarch64
[Bug tree-optimization/101890] New: [12 regression] ICEs on aarch64 after r12-2836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101890 Bug ID: 101890 Summary: [12 regression] ICEs on aarch64 after r12-2836 Product: gcc Version: 12.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: --- r12-2836 introduced regressions on aarch64: gcc:gcc.dg/dg.exp=gcc.dg/pr94269.c (internal compiler error) gcc:gcc.target/aarch64/aarch64.exp=gcc.target/aarch64/pr94398.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_struct_load_6.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/pr95199.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/reduc_strict_7.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_1.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_2.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_3.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_4.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_5.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_6.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_7.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/strided_load_8.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_1.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_2.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_3.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_4.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_5.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_6.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_7.c (internal compiler error) gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/var_stride_8.c (internal compiler error) Actually I bisected only for the first one.
[Bug testsuite/101857] gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101857 --- Comment #2 from Christophe Lyon --- Yes I still see that with r12-2842. There were link errors before r12-2839, but now only this test fails, at execution time. There might be something about raising exception in soft floating-point mode?
[Bug testsuite/101857] New: gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101857 Bug ID: 101857 Summary: gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi Product: gcc Version: 12.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: --- The new test gfortran.dg/ieee/large_3.F90 fails on arm-linux-gnueabi (but passes on arm-linux-gnueabihf, so I think this is a testism, but I'm not sure - I am not fluent in fortran) Flags at line 56: STOP 1 FAIL: gfortran.dg/ieee/large_3.F90 -O0 execution test
[Bug tree-optimization/101755] [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 Christophe Lyon changed: What|Removed |Added Target||arm Target Milestone|--- |12.0 CC||amacleod at redhat dot com
[Bug tree-optimization/101755] New: [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 Bug ID: 101755 Summary: [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637 Product: gcc Version: 12.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 r12-2637, I've noticed a regression on arm: FAIL: gcc.target/arm/reg_equal_test.c scan-rtl-dump expand "expr_list:REG_EQUAL \\(const_int -942519458"
[Bug tree-optimization/101750] [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 Christophe Lyon changed: What|Removed |Added Target Milestone|--- |12.0 Target||aarch64
[Bug tree-optimization/101750] New: [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750 Bug ID: 101750 Summary: [12 regression] g++.dg/vect/pr99149.cc fails on aarch64 since r12-2523 Product: gcc Version: 12.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 r12-2523, I've noticed these failures on aarch64: g++.dg/vect/pr99149.cc -std=c++14 scan-tree-dump-times slp2 "stmt.*COMPLEX_FMA" 1 g++.dg/vect/pr99149.cc -std=c++14 scan-tree-dump-times slp2 "stmt.*COMPLEX_MUL" 1 g++.dg/vect/pr99149.cc -std=c++17 scan-tree-dump-times slp2 "stmt.*COMPLEX_FMA" 1 g++.dg/vect/pr99149.cc -std=c++17 scan-tree-dump-times slp2 "stmt.*COMPLEX_MUL" 1 g++.dg/vect/pr99149.cc -std=c++2a scan-tree-dump-times slp2 "stmt.*COMPLEX_FMA" 1 g++.dg/vect/pr99149.cc -std=c++2a scan-tree-dump-times slp2 "stmt.*COMPLEX_MUL" 1 g++.dg/vect/pr99149.cc -std=c++98 scan-tree-dump-times slp2 "stmt.*COMPLEX_FMA" 1 g++.dg/vect/pr99149.cc -std=c++98 scan-tree-dump-times slp2 "stmt.*COMPLEX_MUL" 1
[Bug middle-end/101690] failure to shrink wrap simple loop with more aggressive jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101690 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- Note that the test passes on arm when using -mthumb. (actually XPASS after g:2730aa7809b47dce47ca0b5e51a6af2164335cf1)
[Bug tree-optimization/101746] [12 regression] gcc.dg/tree-prof/20050826-2.c and gcc.dg/uninit-pred-9_b.c fail since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746 --- Comment #4 from Christophe Lyon --- OK, sorry for the duplicates, I tried to find reports about 20050826-2.c, found none, and forgot to check about the other two.
[Bug tree-optimization/101746] [12 regression] gcc.dg/tree-prof/20050826-2.c and gcc.dg/uninit-pred-9_b.c fail since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746 --- Comment #1 from Christophe Lyon --- In addition on arm: FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++98 (test for excess errors) Excess errors: /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:148:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 2 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++14 (test for excess errors) Excess errors: /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:148:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 2 bytes into a region of size 0 [-Wstringop-overflow=] /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:149:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 3 bytes into a region of size 2 [-Wstringop-overflow=] FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++17 (test for excess errors) Excess errors: /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:148:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 2 bytes into a region of size 0 [-Wstringop-overflow=] /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:149:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 3 bytes into a region of size 2 [-Wstringop-overflow=] FAIL: g++.dg/warn/Wstringop-overflow-4.C -std=gnu++2a (test for excess errors) Excess errors: /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:148:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 2 bytes into a region of size 0 [-Wstringop-overflow=] /gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:149:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 3 bytes into a region of size 2 [-Wstringop-overflow=]
[Bug tree-optimization/101746] New: [12 regression] gcc.dg/tree-prof/20050826-2.c and gcc.dg/uninit-pred-9_b.c fail since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101746 Bug ID: 101746 Summary: [12 regression] gcc.dg/tree-prof/20050826-2.c and gcc.dg/uninit-pred-9_b.c fail since r12-2591 Product: gcc Version: 12.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 r12-2591, I've noticed this regression: FAIL: gcc.dg/tree-prof/20050826-2.c scan-tree-dump-not dom2 "Invalid sum" on arm and aarch64 In addition: FAIL: gcc.dg/uninit-pred-9_b.c bogus warning (test for bogus messages, line 25) occurs on arm-none-eabi when testing with: -mthumb -mfloat-abi=hard -march=armv7e-m+fp.dp -mthumb -mfloat-abi=hard -march=armv7e-m+fp -mthumb -mfloat-abi=soft -march=armv6s-m -mthumb -mfloat-abi=soft -march=armv7-m -mthumb -mfloat-abi=soft -march=armv8.1-m.main or arm-none-linux-gnueabihf when configured --with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16
[Bug sanitizer/101745] New: [12 regression] hwasan new failures since r12-2424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101745 Bug ID: 101745 Summary: [12 regression] hwasan new failures since r12-2424 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Since r12-2424, I've noticed new failures in hwasan tests on aarch64 (I'm testing a cross-compiler using QEMU, but it seems the same failures are reported by native testers on gcc-testresults) The patch seems to have enabled many new tests, some of which fail: c-c++-common/hwasan/alloca-gets-different-tag.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test c-c++-common/hwasan/alloca-outside-caught.c -O0 output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O1 output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O2 output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O3 -g output pattern test c-c++-common/hwasan/alloca-outside-caught.c -Os output pattern test c-c++-common/hwasan/asan-pr70541.c -O0 output pattern test c-c++-common/hwasan/bitfield-2.c -O0 output pattern test c-c++-common/hwasan/bitfield-2.c -O1 output pattern test c-c++-common/hwasan/bitfield-2.c -O2 output pattern test c-c++-common/hwasan/bitfield-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/bitfield-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/bitfield-2.c -O3 -g output pattern test c-c++-common/hwasan/bitfield-2.c -Os output pattern test c-c++-common/hwasan/halt_on_error-1.c -O0 output pattern test c-c++-common/hwasan/halt_on_error-1.c -O1 output pattern test c-c++-common/hwasan/halt_on_error-1.c -O2 output pattern test c-c++-common/hwasan/halt_on_error-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/halt_on_error-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/halt_on_error-1.c -O3 -g output pattern test c-c++-common/hwasan/halt_on_error-1.c -Os output pattern test c-c++-common/hwasan/heap-overflow.c -O0 output pattern test c-c++-common/hwasan/heap-overflow.c -O1 output pattern test c-c++-common/hwasan/heap-overflow.c -O2 output pattern test c-c++-common/hwasan/heap-overflow.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/heap-overflow.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/heap-overflow.c -O3 -g output pattern test c-c++-common/hwasan/heap-overflow.c -Os output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O0 output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O1 output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O2 output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O3 -g output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -Os output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O0 output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O1 output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O2 output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O3 -g output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -Os output pattern test c-c++-common/hwasan/hwasan-thread-clears-stack.c -O0 output pattern test c-c++-common/hwasan/hwasan-thread-clears-stack.c -O1 output pattern test c-c++-common/hwasan/hwasan-thread-clears-stack.c -O2 output pattern test c-c++-common/hwasan/hwasan-thread-clears
[Bug sanitizer/101744] New: [12 regression] hwasan new failures since r12-2424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744 Bug ID: 101744 Summary: [12 regression] hwasan new failures since r12-2424 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Since r12-2424, I've noticed new failures in hwasan tests on aarch64 (I'm testing a cross-compiler using QEMU, but it seems the same failures are reported by native testers on gcc-testresults) The patch seems to have enabled many new tests, some of which fail: c-c++-common/hwasan/alloca-gets-different-tag.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test c-c++-common/hwasan/alloca-outside-caught.c -O0 output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O1 output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O2 output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/alloca-outside-caught.c -O3 -g output pattern test c-c++-common/hwasan/alloca-outside-caught.c -Os output pattern test c-c++-common/hwasan/asan-pr70541.c -O0 output pattern test c-c++-common/hwasan/bitfield-2.c -O0 output pattern test c-c++-common/hwasan/bitfield-2.c -O1 output pattern test c-c++-common/hwasan/bitfield-2.c -O2 output pattern test c-c++-common/hwasan/bitfield-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/bitfield-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/bitfield-2.c -O3 -g output pattern test c-c++-common/hwasan/bitfield-2.c -Os output pattern test c-c++-common/hwasan/halt_on_error-1.c -O0 output pattern test c-c++-common/hwasan/halt_on_error-1.c -O1 output pattern test c-c++-common/hwasan/halt_on_error-1.c -O2 output pattern test c-c++-common/hwasan/halt_on_error-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/halt_on_error-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/halt_on_error-1.c -O3 -g output pattern test c-c++-common/hwasan/halt_on_error-1.c -Os output pattern test c-c++-common/hwasan/heap-overflow.c -O0 output pattern test c-c++-common/hwasan/heap-overflow.c -O1 output pattern test c-c++-common/hwasan/heap-overflow.c -O2 output pattern test c-c++-common/hwasan/heap-overflow.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/heap-overflow.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/heap-overflow.c -O3 -g output pattern test c-c++-common/hwasan/heap-overflow.c -Os output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O0 output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O1 output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O2 output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -O3 -g output pattern test c-c++-common/hwasan/hwasan-thread-access-parent.c -Os output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O0 output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O1 output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O2 output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O2 -flto -fno-use-linker-plugin -flto-partition=none output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -O3 -g output pattern test c-c++-common/hwasan/hwasan-thread-basic-failure.c -Os output pattern test c-c++-common/hwasan/hwasan-thread-clears-stack.c -O0 output pattern test c-c++-common/hwasan/hwasan-thread-clears-stack.c -O1 output pattern test c-c++-common/hwasan/hwasan-thread-clears-stack.c -O2 output pattern test c-c++-common/hwasan/hwasan-thread-clears
[Bug middle-end/101468] New: [r12 regression] new Wstringop-overflow tests failures since r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101468
Bug ID: 101468
Summary: [r12 regression] new Wstringop-overflow tests failures
since r12-2338
Product: gcc
Version: 12.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: ---
Since r12-2338, I've noticed that some of the new tests fail on arm/aarch64.
On aarch64:
FAIL:
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 103)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 104)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 32)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 43)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 66)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 77)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 90)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 91)
gcc.dg/Wstringop-overflow-71.c (test for excess errors)
UNRESOLVED:
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "abort \\("
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "strlen \\("
on aarch64_be, we have two XPASS in addition to the FAIL above:
gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77)
gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68)
on arm-eabi, with default configuration flags, we have:
XPASS:
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 61)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 62)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 63)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 64)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 65)
FAIL:
gcc.dg/Wstringop-overflow-70.c (test for warnings, line 19)
gcc.dg/Wstringop-overflow-70.c (test for excess errors)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 103)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 104)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 32)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 43)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 66)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 77)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 90)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 91)
gcc.dg/Wstringop-overflow-71.c (test for excess errors)
UNRESOLVED:
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "abort \\("
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "strlen \\("
When forcing RUNTESTFLAGS to
-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd, in addition to the above
we have:
XPASS:
gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77)
gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68)
and gcc.dg/Wstringop-overflow-70.c no longer fails
[Bug tree-optimization/101467] New: [r12 regression] ICE on aarch64 after r12-2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467 Bug ID: 101467 Summary: [r12 regression] ICE on aarch64 after r12-2324 Product: gcc Version: 12.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: --- I have noticed ICEs on aarch64 between r12-2322 and r12-2329, likely caused by r12-2324 FAIL: gcc.target/aarch64/sve/peel_ind_1.c (internal compiler error) FAIL: gcc.target/aarch64/sve/peel_ind_1.c (test for excess errors) Excess errors: during GIMPLE pass: vect /gcc/testsuite/gcc.target/aarch64/sve/peel_ind_1.c:13:1: internal compiler error: Segmentation fault 0xe060ff crash_signal /gcc/toplev.c:328 0xdffae8 get_identifier(char const*) /gcc/stringpool.c:97 0x10ddcc9 make_temp_ssa_name /gcc/tree-ssanames.h:148 0x10ddcc9 vect_gen_while(gimple**, tree_node*, tree_node*, tree_node*, char const*) /gcc/tree-vect-stmts.c:12002 0x10ddda3 vect_gen_while_not(gimple**, tree_node*, tree_node*, tree_node*) /gcc/tree-vect-stmts.c:12015 0x112d138 vect_set_loop_controls_directly /gcc/tree-vect-loop-manip.c:632 0x112d138 vect_set_loop_condition_partial_vectors /gcc/tree-vect-loop-manip.c:749 0x112d138 vect_set_loop_condition(loop*, _loop_vec_info*, tree_node*, tree_node*, tree_node*, bool) /gcc/tree-vect-loop-manip.c:950 0x1120225 vect_transform_loop(_loop_vec_info*, gimple*) /gcc/tree-vect-loop.c:9800 0x115c4d9 try_vectorize_loop_1 /gcc/tree-vectorizer.c:1104 0x115cf41 vectorize_loops() /gcc/tree-vectorizer.c:1243 The full list of ICEs: gcc.target/aarch64/sve/peel_ind_1.c (internal compiler error) gcc.target/aarch64/sve/peel_ind_2.c (internal compiler error) gcc.target/aarch64/sve/peel_ind_3.c (internal compiler error) gcc.target/aarch64/sve/peel_ind_4.c (internal compiler error) gcc.target/aarch64/sve/pr98119.c (internal compiler error) When using -mabi=ilp32, there is only one ICE: FAIL: gcc.dg/vect/pr95570.c (internal compiler error)
[Bug tree-optimization/101462] New: [12 regression] ICE on aarch64 after r12-2292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101462
Bug ID: 101462
Summary: [12 regression] ICE on aarch64 after r12-2292
Product: gcc
Version: 9.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 r12-2292 we have an ICE on aarch64:
FAIL: gcc.dg/vect/pr92324-4.c (test for excess errors)
Excess errors:
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c:7:1:
error: incompatible types in 'PHI' argument 1
vector(2) unsigned int
vector(2) int
_91 = PHI <_90(17), _83(11)>
during GIMPLE pass: vect
dump file: ./pr92324-4.c.167t.vect
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c:7:1:
internal compiler error: verify_gimple failed
0x142fe6f verify_gimple_in_cfg(function*, bool)
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/tree-cfg.c:5536
0x12701fa execute_function_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:2042
0x126f132 do_per_function
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:1687
0x12703ee execute_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:2096
gcc is configured --target=aarch64-none-linux-gnu
cc1 is invoked with:
cc1 -fpreprocessed ./pr92324-4.i -quiet -dumpdir ./ -dumpbase pr92324-4.c
-dumpbase-ext .c -mlittle-endian -mabi=lp64 -O2 -version
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -flto -ffat-lto-objects
-ftree-vectorize -fno-tree-loop-distribute-patterns -fvect-cost-model=unlimited
-fno-common -fdump-tree-vect-details -o ./pr92324-4.s
There is another regression which does not ICE:
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fminnmv
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fmaxnmv
Before the patch:
maxv_f32:
.LFB0:
.cfi_startproc
ldr q1, [x0, 4]
ld1r{v3.4s}, [x0]
ldr d0, [x0, 20]
ldr s2, [x0, 28]
fmaxnm v1.4s, v1.4s, v3.4s
fmaxnmv s1, v1.4s
dup v1.2s, v1.s[0]
fmaxnm v0.2s, v0.2s, v1.2s
fmaxnmp s0, v0.2s
fmaxnm s0, s2, s0
ret
After the patch:
maxv_f32:
.LFB0:
.cfi_startproc
ldr q1, [x0, 4]
ld1r{v3.4s}, [x0]
ldr d2, [x0, 20]
ldr s0, [x0, 28]
fmaxnm v1.4s, v1.4s, v3.4s
dup d3, v1.d[1]
fmaxnm v1.2s, v1.2s, v3.2s
fmaxnm v1.2s, v1.2s, v2.2s
fmaxnmp s1, v1.2s
fmaxnm s0, s0, s1
ret
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- Note that we still have failures on arm similar to what you mention on aarch64. FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 34) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 37) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 42)
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 --- Comment #7 from Christophe Lyon --- The patch in comment #6 lets the build complete, thanks!
[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #12 from Christophe Lyon ---
As I am going on holidays until August (back only 2 days until then), I thought
I should share my WIP here. No sure that's the right direction, anyway that's
not working yet.
a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index fa0fb0b..cf2c9b8 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -1633,6 +1633,10 @@ arm_init_simd_builtin_types (void)
arm_simd_types[Bfloat16x4_t].eltype = arm_bf16_type_node;
arm_simd_types[Bfloat16x8_t].eltype = arm_bf16_type_node;
+ arm_simd_types[Pred1x16_t].eltype = unsigned_intHI_type_node;
+ arm_simd_types[Pred2x8_t].eltype = unsigned_intHI_type_node;
+ arm_simd_types[Pred4x4_t].eltype = unsigned_intHI_type_node;
+
for (i = 0; i < nelts; i++)
{
tree eltype = arm_simd_types[i].eltype;
diff --git a/gcc/config/arm/arm-modes.def b/gcc/config/arm/arm-modes.def
index a5e74ba..098831c 100644
--- a/gcc/config/arm/arm-modes.def
+++ b/gcc/config/arm/arm-modes.def
@@ -84,6 +84,15 @@ VECTOR_MODE (FLOAT, BF, 2); /* V2BF. */
VECTOR_MODE (FLOAT, BF, 4); /*V4BF. */
VECTOR_MODE (FLOAT, BF, 8); /*V8BF. */
+/* Predicates for MVE. */
+VECTOR_BOOL_MODE (VNx16BI, 16, 2);
+VECTOR_BOOL_MODE (VNx8BI, 8, 2);
+VECTOR_BOOL_MODE (VNx4BI, 4, 2);
+
+ADJUST_NUNITS (VNx16BI, arm_vg * 8);
+ADJUST_NUNITS (VNx8BI, arm_vg * 4);
+ADJUST_NUNITS (VNx4BI, arm_vg * 2);
+
/* Fraction and accumulator vector modes. */
VECTOR_MODES (FRACT, 4); /* V4QQ V2HQ */
VECTOR_MODES (UFRACT, 4); /* V4UQQ V2UHQ */
diff --git a/gcc/config/arm/arm-simd-builtin-types.def
b/gcc/config/arm/arm-simd-builtin-types.def
index c19a1b6..6a5053f 100644
--- a/gcc/config/arm/arm-simd-builtin-types.def
+++ b/gcc/config/arm/arm-simd-builtin-types.def
@@ -51,3 +51,7 @@
ENTRY (Bfloat16x2_t, V2BF, none, 32, bfloat16, 20)
ENTRY (Bfloat16x4_t, V4BF, none, 64, bfloat16, 20)
ENTRY (Bfloat16x8_t, V8BF, none, 128, bfloat16, 20)
+
+ ENTRY (Pred1x16_t, VNx16BI, unsigned, 16, uint16, 21)
+ ENTRY (Pred2x8_t, VNx8BI, unsigned, 8, uint16, 21)
+ ENTRY (Pred4x4_t, VNx4BI, unsigned, 4, uint16, 21)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f967239..98ff238 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3446,6 +3446,8 @@ arm_configure_build_target (struct arm_build_target
*target,
arm_option_reconfigure_globals ();
}
+poly_uint16 arm_vg;
+
/* Fix up any incompatible options that the user has specified. */
static void
arm_option_override (void)
@@ -3458,6 +3460,7 @@ arm_option_override (void)
static const enum isa_feature quirk_bitlist[] = { ISA_ALL_QUIRKS,
isa_nobit};
cl_target_option opts;
+ arm_vg = 2;
isa_quirkbits = sbitmap_alloc (isa_num_bits);
arm_initialize_isa (isa_quirkbits, quirk_bitlist);
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 8e5bd57..df9bbb2 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2493,4 +2493,7 @@ const char *arm_be8_option (int argc, const char **argv);
representation for SHF_ARM_PURECODE in GCC. */
#define SECTION_ARM_PURECODE SECTION_MACH_DEP
+#ifndef USED_FOR_TARGET
+extern poly_uint16 arm_vg;
+#endif
#endif /* ! GCC_ARM_H */
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 83f1003..765ec5a 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -3524,7 +3524,7 @@ __arm_vaddlvq_u32 (uint32x4_t __a)
return __builtin_mve_vaddlvq_uv4si (__a);
}
-__extension__ extern __inline int64_t
+__extension__ extern __inline mve_pred16_t/*int64_t*/
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
__arm_vctp16q (uint32_t __a)
{
diff --git a/gcc/config/arm/arm_mve_types.h b/gcc/config/arm/arm_mve_types.h
index 8958f4e..536e816 100644
--- a/gcc/config/arm/arm_mve_types.h
+++ b/gcc/config/arm/arm_mve_types.h
@@ -34,7 +34,8 @@ typedef struct { float32x4_t val[2]; } float32x4x2_t;
typedef struct { float32x4_t val[4]; } float32x4x4_t;
#endif
-typedef uint16_t mve_pred16_t;
+//typedef uint16_t mve_pred16_t;
+typedef __simd16_uint16_t mve_pred16_t;
typedef __simd128_uint8_t uint8x16_t;
typedef __simd128_uint16_t uint16x8_t;
typedef __simd128_uint32_t uint32x4_t;
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index 5c4fe89..2656f6b 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -948,6 +948,8 @@ (define_mode_attr V_extr_elem [(V16QI "u8") (V8HI "u16")
(V4SI "32")
(V8HF "u16") (V4SF "32")])
(define_mode_attr earlyclobber_32 [(V16QI "=w") (V8HI "=w") (V4SI "=")
(V8HF "=w") (V4SF "=")])
+;;(define_mode_attr MVE_VPRED [(V16QI "VNx16BI") (V8HI "VNx8BI") (V4SI
"VNx4BI")])
+(define_mode_attr MVE_VPRED [(V16QI "VNx16BI") (V8HI "VNx16BI") (V4SI
"VNx16BI") (V8HF "VNx16BI") (V4SF "VNx16BI")])
