https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Christophe Lyon changed:
What|Removed |Added
Assignee|clyon at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #24 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:aa8b5ca0b540fde5890f3114f2d7076d5238fc2e
commit r11-1759-gaa8b5ca0b540fde5890f3114f2d7076d5238fc2e
Author: Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #23 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:2f3fd53220b74d834d300e0b7aa99eca039ffbea
commit r11-1752-g2f3fd53220b74d834d300e0b7aa99eca039ffbea
Author: Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #22 from Christophe Lyon ---
Not sure if we can close this PR: I have only implemented a part of what we
discussed here. GCC now emits a warning so the user can take action to make
sure his code is correct/correctly generated, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #21 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:3c3b4224875d7b8bfd4126b9dd1d9cb028997285
commit r11-1732-g3c3b4224875d7b8bfd4126b9dd1d9cb028997285
Author: Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #20 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:635408da1eb1d441ef4d59fe00a038c920e51085
commit r11-1062-g635408da1eb1d441ef4d59fe00a038c920e51085
Author: Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #19 from Christophe Lyon ---
(In reply to Christophe Lyon from comment #8)
> Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544872.html
>
> This is a simple improvement, hopefully simple enough for stage 4, yet
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #18 from Christophe Lyon ---
> I'm working on this, and just realized that this also means saving FPSR. It
> seems there's no support for that yet in arm.md (unlike aarch64.md), am I
> missing something?
>
Sorry, I see it's called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #17 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #16 from Christophe Lyon ---
Another potential issue just came to my mind: what if the IRQ handler is
compiled with -mfloat-abi=soft but calls a function compiled with
-mfloat-abi=softfp? We have no way to guess that the FP registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #15 from Christophe Lyon ---
> Well obviously that won't work. But if you build the interrupt routine with
> a d16 system and then call a function from it that requires d32 then that
> should still work if running on a d32 CPU.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #14 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #13)
> But, in general (non-interrupt) code, what is supposed to happen if you
> compile for a d32 VFP and run on d16 one ? (and the code uses the extra
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #13 from Christophe Lyon ---
> > Why do we need a library function for that? It would have to be special with
> > the stack: push FP registers, but do not restore SP, so that the dual
> > restore function can pop them and restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #12 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #11)
> (In reply to Richard Earnshaw from comment #10)
> > (In reply to Christophe Lyon from comment #9)
> > > > My initial thoughts are along the lines of...
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #11 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #10 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #9)
> > My initial thoughts are along the lines of...
> > Only try to save FP registers that this function directly clobbers.
> What's the point of saving these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #9 from Christophe Lyon ---
> My initial thoughts are along the lines of...
> Only try to save FP registers that this function directly clobbers.
What's the point of saving these if a callee clobbers other registers?
Shouldn't that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Christophe Lyon changed:
What|Removed |Added
Last reconfirmed||2020-04-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #7 from Richard Earnshaw ---
well, __aeabi_memcpy is required not to clobber the FP state. Sadly, GCC does
not know about it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #6 from Christophe Lyon ---
If we consider the initial testcase, it doesn't clobber any FP register
directly, but the compiler inserts a call to memcpy which does.
So IIUC your 1st suggestion, it would mean:
- save no FP register in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #5 from Richard Earnshaw ---
This is made more complex due to the fact that the existence of the top 16 D
registers depends on the hardware you have, so saving them might require a d32
variant of the ISA, but we can't (quickly) tell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Christophe Lyon changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #3 from Christophe Lyon ---
Maybe we could
- save the VFP registers as needed by default
- emit a warning "IRQ handler 'foo' saves VFP registers because it is not a
leaf function. If you know none of the callees will clobber the VFP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #2 from Christophe Lyon ---
I have a preliminary patch which generates:
vpush.64{d0, d1, d2, d3, d4, d5, d6, d7}
vpush.64{d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26,
d27, d28, d29, d30, d31}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #1 from Christophe Lyon ---
clang has implemented a warning for this case:
https://reviews.llvm.org/D28820
26 matches
Mail list logo
