https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-01-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
david.welch at netronome dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #13 from david.welch at netronome dot com ---
Very sorry it has been years since I did this research, a simple nop wont fix
it but a branch to self will.
bad
TEST:
push {r4,lr}
pop {r4,pc}
bx r0 /*.hword 0x470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #12 from david.welch at netronome dot com ---
I my case this was found with a hang, but the problem exists as a read, which
means it can cause a read to a read sensitive peripheral causing adverse
affects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #11 from david.welch at netronome dot com ---
I wish I had know this when I filed this ticket, there is an ARM Errata for
this issue that was issued before or in 2009.
720247: Speculative Instruction fetches can be made anywhere in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
david.welch at netronome dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #9 from david.welch at netronome dot com ---
Basically gcc is generating a sequence where data starts to execute in the
pipe. I cant imagine that is a good idea to let the processor execute data
when you can avoid it
instead of a pop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #8 from david.welch at netronome dot com ---
gcc is treating these instructions as unconditional branches, but the core does
NOT treat these instructions as unconditional branches. The disconnect is
quite clear between the code produc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #7 from david.welch at netronome dot com ---
This is an armv6 not an armv7.
So far I have not seen that the mmu or cache or branch prediction is required
for proper operation of the core. I have so far not see this on other cores,
bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #5 from david.welch at netronome dot com ---
it is definitely doing prefetching by not realizing those instructions are
unconditional branches. most likely going with strongly ordered rather than
the XN bit but noted as a workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
mgretton at gcc dot gnu.org changed:
What|Removed |Added
CC||mgretton at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #3 from david.welch at netronome dot com ---
The problem exists as well with ldr pc,[something]. I have not dug through gcc
but did some compilation experiments, not nearly enough to be 100% sure, but
for switch statements the code ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #2 from david.welch at netronome dot com ---
ARM does not have an errata on this for this core from what I was given. Dont
know why they would, at best it would fall into the "unpredictable results"
category. Errata or not was hoping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
--- Comment #1 from Andrew Pinski ---
This sounds like an errata in the core you are using. There seems like the
best way to fix this is via an option which worksaround this errata if there is
not one already.
17 matches
Mail list logo
