https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #3 from Richard Earnshaw ---
The manual entry for this says "This attribute is supported mainly for the
purpose
of testing the compiler." which suggests a lack of long-term commitment to the
option. Perhaps it would be better to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #19 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #18)
> I should say that testcase happens at `-Os -mstrict-align`, at `-O2
> -mstrict-align` it works.
Because for -Os we don't forcibly align arrays - see
AARCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #3 from Richard Earnshaw ---
Given that the hard-float ABI essentially requires V4SF as a type, it might be
better to consider this mode supported unconditionally in this case, and
although that might make the compiler try some point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #2 from Richard Earnshaw ---
If the testcase is built with -march=armv8.1-m.main+mve.fp then the useless
stack adjustments go away. I think that's because V4SFmode is not a supported
vector mode for integer MVE - see arm_vector_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
Richard Earnshaw changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #13 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #10 from Richard Earnshaw ---
Almost certainly this is related to the need for a copyreloc and presumably the
linker has not created one for some reason. So I suspect this is most likely a
binutils issue rather than a compiler one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #14 from Richard Earnshaw ---
(In reply to Richard Biener from comment #13)
> (In reply to Andrew Pinski from comment #10)
> > Updated patch submitted:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589254.html
>
> I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
--- Comment #5 from Richard Earnshaw ---
Fixed on master. While this is not a regression, we should consider a
backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
--- Comment #3 from Richard Earnshaw ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587296.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108019
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621
--- Comment #1 from Richard Earnshaw ---
I don't see that when using Firefox, so perhaps it is a browser issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107208
--- Comment #4 from Richard Earnshaw ---
(In reply to vfdff from comment #3)
> it seems releted to targetm.calls.function_value called by assign_parms, who
> return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
> the foll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #10 from Richard Earnshaw ---
That sounds broadly sensible. One optimization might be to check if the
exception trapping is already enabled, then you can skip the read/set/restore
dance entirely in that case. That might be more effi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #8 from Richard Earnshaw ---
(In reply to Francois-Xavier Coudert from comment #7)
> @Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
> checking that the floating-point modes (rounding mode, underflow mode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #6 from Richard Earnshaw ---
Whilst the patch is probably fine and a better way of doing this, it won't fix
the test failure. I think your problem is that you're assuming that an
exception will cause a trap in hardware. That's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #8 from Richard Earnshaw ---
Perhaps something is changing the decision on the use of the frame pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-27
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #6 from Richard Earnshaw ---
Nobody has proposed any patches yet, but I imagine we'd end up treating
-mcpu=iwmmxt[2] in the same way as -mcpu=xscale. Similarly for
-march=iwmmxt[2].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #4 from Richard Earnshaw ---
I don't think we're talking about removing support for the CPU, just support
for the iwmmxt extension. That is, you can still use it as an Arm cpu, but
without the vector engine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
--- Comment #8 from Richard Earnshaw ---
That's C++ for you, it permits you to overload operators in completely
meaningless ways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106827
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #55 from Richard Earnshaw ---
(In reply to Mathieu Malaterre from comment #53)
>
> gcc-12 seems to be generating wrong-code for a different unit-test:
I've just pushed my patch to the gcc-12 branch, could you try that please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105463
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #18 from Richard Earnshaw ---
(In reply to George Pee from comment #17)
> Any idea on why the issue is intermittent?
For SMP not really, because I think that path doesn't use lazy context
switching; but perhaps the kernel is smart e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #16 from Richard Earnshaw ---
(In reply to George Pee from comment #15)
> Funny that you mention that...
> https://lore.kernel.org/linux-arm-kernel/20220901141307.2361752-1-
> george...@gmail.com/T/#u
:)
Don't forget that the arm64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #14 from Richard Earnshaw ---
Also beware that I don't think Russel King (Arm Linux kernel maintainer) would
accept this patch on its own. You'd likely need to add some boot time
detection of the additional feature and expose that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #13 from Richard Earnshaw ---
I don't think it would hurt. With this change, a float-16 instruction that was
encountered on older cores would enable the VFP unit if it wasn't previously
enabled and then fault again when the retried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106279
--- Comment #5 from Richard Earnshaw ---
Technical note: the compiler is missing pattern alternatives to move iwmmxt
register values to VFP registers. There's no way to do this directly, so we'd
need to allow copying via core registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106279
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #11 from Richard Earnshaw ---
(In reply to George Pee from comment #9)
> Using this works around the issue by treating it via a neon path and
> enabling the vfp bit and retrying the instruction.
>
> @@ -824,6 +824,9 @@ call_fpe:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #10 from Richard Earnshaw ---
If you don't have CONFIG_SMP enabled, it looks like the kernel will do lazy
context switching of the FP registers (it can save time if a process doesn't do
any FP). So another work around might be to en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #8 from Richard Earnshaw ---
I spoke to our kernel experts about this and they think my hypothesis is quite
likely to be correct. They also noted that kernel version 4.9.118 is about 200
releases out of date on the 4.9 LTS series.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #5 from Richard Earnshaw ---
My guess (and it's only a guess because I'm not a kernel expert) is that the OS
has disabled the FP/SIMD unit because of something like a context switch and
then is failing, somehow, to recognize that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #3 from Richard Earnshaw ---
Programs don't generally take SIGILL intermittently - if that really is the
case, then it's unlikely to be a bug in the compiler.
You haven't told us what OS you are running on, or anything else about yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106723
--- Comment #3 from Richard Earnshaw ---
I think we should error if the name matches some iteration values, but not
others. If is valid in the assembler output 'as-is' then it's bad form
to have an attribute that overloads this - and the fix i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to D Scott Phillips from comment #2)
> > th(In reply to Andrew Pinski from comment #1)
> > > Shouldn't the linker add the BTI inside the ___venee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #5 from Richard Earnshaw ---
(In reply to D Scott Phillips from comment #2)
> th(In reply to Andrew Pinski from comment #1)
> > Shouldn't the linker add the BTI inside the ___veneer instead?
>
> The bti instruction has to be placed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106635
--- Comment #11 from Richard Earnshaw ---
(In reply to Xiaoguang from comment #9)
> Yeah, I also find such description, my memory type is uncachable normal
> memory, but not device memory
> I use mmap to get the virtual address with an O_SYNC in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106642
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-08-16
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106635
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #30 from Richard Earnshaw ---
(In reply to rsand...@gcc.gnu.org from comment #29)
> (In reply to Segher Boessenkool from comment #28)
> > (In reply to rsand...@gcc.gnu.org from comment #25)
> > > - On big-endian targets, vector loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Richard Earnshaw changed:
What|Removed |Added
CC||andij.cr at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91674
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
--- Comment #2 from Richard Earnshaw ---
32-bit division by constant relies on a 32x32->64 bit multiply. So it seems
reasonable that a 64-bit division would need a 64x64->128 bit multiply. We
don't have an instruction for that on arm nor does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #48 from Richard Earnshaw ---
Improved version posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598993.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #47 from Richard Earnshaw ---
Created attachment 53361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53361&action=edit
Possible patch
A slightly more thorough attempt to avoid the problem by detecting when the
alias sets are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106442
--- Comment #8 from Richard Earnshaw ---
(In reply to sherry.zhang2 from comment #7)
> (In reply to Richard Earnshaw from comment #6)
> > possibly a dup of pr101723. Please try gcc-11.3
>
> The latest version I can get is 11.2
> https://develo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106442
--- Comment #6 from Richard Earnshaw ---
possibly a dup of pr101723. Please try gcc-11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #45 from Richard Earnshaw ---
The problem with changing rtx_equal_for_cselib_1 is that it is essentially
commutative in its operands - it doesn't disambiguate with x substituting for y
or vice-versa, so we cannot tell if an operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #42 from Richard Earnshaw ---
That would be unfortunate, it removes a lot of pointless loads in this case;
and even the store it removes ought to be safe, if it weren't for the corrupted
alias info that results (the values /are/ the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #40 from Richard Earnshaw ---
reload_cse_noop_set_p is the function that decides the store is redundant. For
this parallel case it's being called once for each set, but all the cases
return true, so the store insn gets removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #37 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #36)
> Note that the only thing we have to do is fix points-to info, the TBAA
> info should be correct and OK even when objects share location, so there's
> n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #35 from Richard Earnshaw ---
> There's no union involved here though but a memcpy used in BitCast.
Agreed, but by creating a shared stack slot, the compiler is effectively
creating a union of its own, and I think that needs to be ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #33 from Richard Earnshaw ---
I suspect there is still a question, though, as to whether it is safe in
general for two objects with non-conflicting alias sets to share a stack slot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed|2022-07-04 00:00:00 |2022-07-22
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #29 from Richard Earnshaw ---
Thanks for having a look, yes, I was at a loss to understand how that change
(which is before the problematic hunk would be the cause of the problem. It
looks like we can rule that change out as a real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #27 from Richard Earnshaw ---
BTW, compile flags for an arm-none-eabi compiler are:
cc1plus -march=armv7-a+fp -mfloat-abi=hard -O2 -quiet -mthumb -fno-short-enums
-fno-exceptions -fvisibility-inlines-hidden -fmath-errno -fmerge-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #25 from Richard Earnshaw ---
A quick status update.
I've managed to reduce the testcase to the latest attachment. The program is
heavily reduced (so some bits likely don't make much sense), but the test still
'passes' when compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Attachment #53276|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #22 from Richard Earnshaw ---
I notice that the sources seem to do floating-point negation by casting values
to integers, xor-ing the sign bit and then casting the result back to a float.
This is exactly the sort of operation that i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #21 from Richard Earnshaw ---
I've finally managed to reproduce the test failure (someone has turned off
emu128 in the sources I have).
Rebuilding the failing test with -fno-strict-aliasing causes the test to pass.
That strongly su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #19 from Richard Earnshaw ---
Hmm, I'm not sure that makes sense to me. AFAICT highway requires an Arm CPU
with Neon, but the default compiler flags that you posted (-mthumb
-march=armv7-a+fp) does not provide that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #17 from Richard Earnshaw ---
And what options are you passing to cmake?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #15 from Richard Earnshaw ---
What's the output of "gcc -v" for the failing compiler(s)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #11 from Richard Earnshaw ---
Object files are no use to us. We need preprocessed source along with analysis
of what you think has gone wrong (my program crashes or prints the wrong number
is rarely enough). Also, please make sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #12 from Richard Earnshaw ---
(In reply to Alex Coplan from comment #11)
> (In reply to Jakub Jelinek from comment #8)
> > The IMHO UB case is for a != b when one address is at the start of one
> > object and the other address is at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
--- Comment #10 from Richard Earnshaw ---
the testcase in the committed patch, that is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 106070, which changed state.
Bug 106070 Summary: [13 Regression] Wrong code with -O1 since
r13-469-g9a53101caadae1b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106004
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
||2022-06-17
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Earnshaw ---
Mine. Same underlying problem as PR105974.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Summary|[10/11/12/13 regression]|[10/11/12 regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > --- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
> > +++ gcc/match.pd2022-06-15 15:28:55.9162253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #5 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> --- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
> +++ gcc/match.pd 2022-06-15 15:28:55.916225336 +0200
> @@ -2379,14 +2379,14 @@ DEFINE_INT_AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|Wrong code g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-06-15
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105941
--- Comment #3 from Richard Earnshaw ---
If you really wanted this to be made to work, I think you'd need to use spec
files. Then you could provide a spec for each supported linker. It still
wouldn't be trivial, but it seems to me it's the onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105941
--- Comment #1 from Richard Earnshaw ---
The correct thing to do would be to implement the option in lld. If lld claims
to be a replacement for ld, then it really should support all the command-line
options that ld supports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105817
--- Comment #1 from Richard Earnshaw ---
The GCC manual says
register int *p1 asm ("r0") = …;
register int *p2 asm ("r1") = …;
register int *result asm ("r0");
asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
Warning: In the above example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105773
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P4
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105773
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-06-08
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105731
--- Comment #5 from Richard Earnshaw ---
The thumb1 rtx-costing function needs a complete rewrite along the lines and
style of the Thumb2 and Arm costing routines.
Another thing for my copious free time (TM).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105704
--- Comment #2 from Richard Earnshaw ---
Arm uses mapping symbols, which are special symbols in the object file that are
used by disassemblers to understand the content of code sections. But that's
not the primary reason we use such annotations
|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-05-13
Summary|[11/12/13 Regression] MVE: |[11/12 Regression] MVE:
|Wrong code, incorrect |Wrong
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
On arm constructors implicitly return 'this', but this is leading to a boottrap
failure.
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105463
--- Comment #4 from Richard Earnshaw ---
Vector loads on MVE need to be lane-sized aligned.
I think the movmisalign pattern for MVE needs to emit VLDRB.8 regardless of the
mode, rather than an inner-mode sized access. Fortunately, for little-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #7 from Richard Earnshaw ---
Options to reproduce on arm-none-eabi:
-O3 -mcpu=cortex-a9 -mfpu=neon-fp16 -mfloat-abi=hard -o - vect.c -S
-fdump-tree-all-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Richard Earn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Richard Earn
101 - 200 of 1300 matches
Mail list logo
