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
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
|P2
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
Severity|major |normal
Target||aarch64
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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
|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
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
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
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"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104662
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
: 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090
--- Comment #15 from Christophe Lyon ---
Indeed I don't see that anymore.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102880
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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
: 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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #2 from Christophe Lyon ---
Yes, I can still see failures with r12-4820
: 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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
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,
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
: 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
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
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
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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538
Christophe Lyon changed:
What|Removed |Added
CC||akhilesh.k at samsung dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102173
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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 ?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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
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:
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90787
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101056
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101890
Christophe Lyon changed:
What|Removed |Added
Target Milestone|--- |12.0
Target|
: 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
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?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755
Christophe Lyon changed:
What|Removed |Added
Target||arm
Target Milestone|---
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Christophe Lyon changed:
What|Removed |Added
Target Milestone|--- |12.0
Target|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101690
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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.
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*
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
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
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
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
: 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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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!
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
--- Comment #5 from Christophe Lyon ---
The patch does not work, I'm now getting this error:
In file included from
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/arm/host-config.h:4,
from
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After r12-2132, I've noticed a build failure in libatomic for arm. It can be
reproduced with --target arm-linux-gnueabi (not with arm-eabi):
In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101375
--- Comment #1 from Christophe Lyon ---
The same is true when targeting more "natural" options for arm-eabi:
-mthumb/-mfloat-abi=hard/-march=armv7e-m+fp/-mfpu=auto
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
While looking at updating my validation configs to use -mfpu=auto, I noticed
that adding this options makes many tests unsupported. Given that most of them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
--- Comment #8 from Christophe Lyon ---
Here are the options I see in gcc.log:
-O0 -march=armv8.2-a+bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101363
--- Comment #4 from Christophe Lyon ---
(In reply to Martin Sebor from comment #2)
> I don't see the ICE with my cross-compiler and the stack trace doesn't
> correspond to the latest sources (there's no call to error() at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321
--- Comment #7 from Christophe Lyon ---
> PS: I let -fno-short-enums remain in the testcase for now. If the patch
> fixes the issue while removing -fno-short-enums, the testcase can be updated
> to not have -fno-short-enums anymore.
I just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #10 from Christophe Lyon ---
This was introduced by my change at r12-671 in mve.md:
-;; [vcmpneq_])
+;; [vcmpneq_, vcmpcsq_, vcmpeqq_, vcmpgeq_, vcmpgtq_, vcmphiq_, vcmpleq_,
vcmpltq_])
;;
-(define_insn "mve_vcmpneq_"
+(define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #8 from Christophe Lyon ---
Indeed, it's what happens in try_combine():
i2src = subst (i2src, pc_rtx, pc_rtx, 0, 0, 0);
converts i2src
(zero_extend:SI (reg:HI 117))
into:
(and:SI (subreg:SI (reg:HI 117) 0)
(const_int 1 [0x1]))
101 - 200 of 1123 matches
Mail list logo
