https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
mponent: d
Assignee: ibuclaw at gdcproject dot org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
In our CI with highly parallel builds, we have noticed random failures in the
'd' front-end, with errors like:
mv: cannot stat 'd/.deps/package.TPo': No such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118446
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118332
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
#include
uint32x4_t first(uint32x4x4_t a) { return a.val[0]; }
compiled with -mcpu=cortex-m55 -mfloat-abi=hard -mfpu=auto fails w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118176
Christophe Lyon changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
--- Comment #3 from Christophe Lyon ---
> It might be helpful to see the dissassembled code of
> sync/atomic_test.TestNilDeref..func30.
Sorry for the naive question: where can I find it?
In my build tree, I have:
armv8l-unknown-linux-gnueab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152
--- Comment #1 from Christophe Lyon ---
libgo.log says:
unexpected fault address 0x1e08e
fatal error: fault
[signal SIGBUS: bus error code=0x1 addr=0x1e08e pc=0x0]
goroutine 215 [running]:
runtime.dopanic__m
/home/christophe.lyon/src/Li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #9 from Christophe Lyon ---
I have opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118152 about the
sync/atomic failure.
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
libgo's sync/atomic has been reported to fail for a long time on arm, and I
have bisected this to com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118131
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118131
--- Comment #1 from Christophe Lyon ---
This is because arm.cc:arm_attr_length_move_neon() does not handle the new MVE
struct modes, which correspond to OImode and XImode.
Adding them leads to a crash later because in neon.md we have
(define_sp
://linaro.atlassian.net/browse/GNU-1467
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
As reported
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: arm
After
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
--- Comment #8 from Christophe Lyon ---
Sorry for the delay: it took me a while to reproduce the problem manually,
while it does show up in CI.
The problem does not happen when I rebuild a full toolchain (trunk binutils +
trunk glibc + trunk gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #5 from Christophe Lyon ---
Note that the test passed before commit r15-5997-g75e7d1600f4785 , which was
bisected by the CI.
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: vmakarov at redhat dot com
Target Milestone: ---
Target: arm
After commit g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
/browse/GNU-1445
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: clyon at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com
Target Milestone: ---
Target
://linaro.atlassian.net/browse/GNU-1444
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: jakub at redhat dot com
Target Milestone
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: azoff at gcc dot gnu.org
Target Milestone: ---
Since commit
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117958
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Component: target
Assignee: clyon at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm
After commit r15-4734-g63b6967b06b538
we have noticed several regressions on arm:
on arm-none-eabi and arm-none-linux-gnueabihf:
Running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117814
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
As described in https://bugs.linaro.org/show_bug.cgi?id=6058, this short code
fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117600
--- Comment #1 from Christophe Lyon ---
Forcing -Werror was a request/decision:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664797.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117537
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #39 from Christophe Lyon ---
A bit more context:
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
The section about predicates uses the word 'lanes' and says 'When calling a
predica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117406
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117407
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #12 from Christophe Lyon ---
Just noticed this in config.log:
configure:16789: checking for C locale to use
configure:16793: result: generic
so yeah, there's "some info" that --enable-clocale=gnu did not have the
expected effect :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #7 from Christophe Lyon ---
Looking at my build dir, I can see that libstdc++ build system makes symlinks
to time_members.cc in the build dir.
And in my case, all these links point to
libstdc++-v3/config/locale/generic/time_members.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #5 from Christophe Lyon ---
Looking at newlib's nl_langinfo_l
(https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/locale/nl_langinfo.c;h=4477d833bec18572265df8e9b8914af695fab8bb;hb=HEAD)
at quick glance it seems it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135
--- Comment #2 from Christophe Lyon ---
The additional debug output with your patch is:
Wide D_T_FMT for C locale:
eofbit: 0 failbit: 0 badbit: 0
22_locale/time_get/get/wchar_t/5.cc:29: int main(): Assertion 'err ==
std::ios::eofbit' failed.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: jwakely.gcc at gmail dot com
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: arm-eabi
Created attachment 59342
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #18 from Christophe Lyon ---
Sorry, no, this is not the cause of the problem (actually musttail7.c also
fails in gcc.log).
I looked into this, and it's a bit tricky
in arm_function_ok_for_sibcall() (from arm.cc), we have:
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #15 from Christophe Lyon ---
(In reply to andi from comment #14)
> The test relies on the
>
> gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
Are you sure?
musttail7.c has:
/* { dg-do compile { target { mustta
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since r15-3794-g2c04f175de4f39, we noticed this
|---
CC||clyon at gcc dot gnu.org
--- Comment #13 from Christophe Lyon ---
As of r15-3812-g4700ad1c78ccd7, musttail7.c still fails on arm-eabi with
default configuration / test flags:
FAIL: c-c++-common/musttail7.c -std=c++11 (test
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Since commit gcc-15-3735-g664e0ce580a8, we have noticed failures in
gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116260
--- Comment #3 from Christophe Lyon ---
Thanks for the additional information, indeed in our CI we do not run
validations for several "variations", so it's not surprising this case is not
handled very well.
So you suggest having one manifest pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
||clyon at gcc dot gnu.org
Status|ASSIGNED|RESOLVED
--- Comment #23 from Christophe Lyon ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115635
Bug 115635 depends on bug 115661, which changed state.
Bug 115661 Summary: [15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu
since r15-1599-g63512c72df09b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115661
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #16 from Christophe Lyon ---
(In reply to Richard Biener from comment #15)
> OK, looking the fix was only half complete. Can you try
It works with this, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #14 from Christophe Lyon ---
Created attachment 58522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58522&action=edit
Wrong code after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #13 from Christophe Lyon ---
Yes it breaks at the same point, again we are returning an uninitialized value.
Adding annotate asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #11 from Christophe Lyon ---
Created attachment 58520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58520&action=edit
vect dump broken after r15-1392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #5 from Christophe Lyon ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*). (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #2 from Christophe Lyon ---
Created attachment 58431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58431&action=edit
vect dump OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #3 from Christophe Lyon ---
Created attachment 58432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58432&action=edit
vect dump broken
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Created attachment 58428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58428&action=edit
Code generated bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #1 from Christophe Lyon ---
Created attachment 58429
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58429&action=edit
Wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522
Christophe Lyon changed:
What|Removed |Added
Target|arm |arm aarch64
--- Comment #2 from Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #32 from Christophe Lyon ---
Created attachment 58110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58110&action=edit
patch v2
Here is another patch proposal along the lines of what you suggest in #c24
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.
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 C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #26 from Christophe Lyon ---
Thanks for testing, my build is still in progress.
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
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-
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #14 from Christophe Lyon ---
Created attachment 58050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58050&action=edit
patch proposal
Here is the patch I propose.
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))
>
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 bui
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
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 g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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 sho
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 ?
> Ar
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 slightl
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.
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 ad
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #5 from Christophe Lyon ---
Exactly. I have a (one-line) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2024-03-14
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
Also seen on arm targets.
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
1 - 100 of 1176 matches
Mail list logo
