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