[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. Herald added a subscriber: kristof.beyls. In D28820#945118 , @kc.austin2017 wrote: > In D28820#944865 , @jroelofs wrote: > > > https://bugs.llvm.org/show_bug.cgi?id=35527 > > > > https://bugs

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

kc.austin2017 added a comment. In https://reviews.llvm.org/D28820#944865, @jroelofs wrote: > In https://reviews.llvm.org/D28820#944365, @efriedma wrote: > > > > What is the best way to modify the code for this compiler change ? > > > > Currently, the "interrupt" attribute only has an effect on fu

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. In https://reviews.llvm.org/D28820#944365, @efriedma wrote: > > What is the best way to modify the code for this compiler change ? > > Currently, the "interrupt" attribute only has an effect on functions, not > function pointers, so your code won't work the way you want

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

kc.austin2017 added a comment. In https://reviews.llvm.org/D28820#944365, @efriedma wrote: > > What is the best way to modify the code for this compiler change ? > > Currently, the "interrupt" attribute only has an effect on functions, not > function pointers, so your code won't work the way you

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

efriedma added a comment. > What is the best way to modify the code for this compiler change ? Currently, the "interrupt" attribute only has an effect on functions, not function pointers, so your code won't work the way you want. It's a bug that we don't emit a warning for this. Currently, th

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

kc.austin2017 added a comment. Hi , I am looking for some helps on the issue i have in my project after this change for the compiler. typedef void (*callback_t)(uint32_t icciar, void * context); callback_t callee1; void _ _attribute__((interrupt("IRQ"))) __cs3_isr_irq() { callee1(icciar , co

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. In https://reviews.llvm.org/D28820#695356, @tyomitch wrote: > When compiling for softfp targets, this new warning doesn't make sense: there > are no VFP registers to save. > Jonathan, would you please conditionalize it to only affect hardfp targets? Sure, I can do th

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

tyomitch added a comment. When compiling for softfp targets, this new warning doesn't make sense: there are no VFP registers to save. Jonathan, would you please conditionalize it to only affect hardfp targets? https://reviews.llvm.org/D28820 ___ cf

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. In https://reviews.llvm.org/D28820#649770, @efriedma wrote: > > There would be a big performance penalty for ISRs with callees that don't > > use VFP regs. > > Sacrificing correctness for the sake of performance seems like a bad idea... I don't quite see it that way,

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

efriedma added a comment. > There would be a big performance penalty for ISRs with callees that don't use > VFP regs. Sacrificing correctness for the sake of performance seems like a bad idea... especially given that the optimizer can insert calls to memcpy where they didn't originally exist i

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. In https://reviews.llvm.org/D28820#649738, @jroelofs wrote: > In https://reviews.llvm.org/D28820#649726, @efriedma wrote: > > > Why can't the compiler handle this case itself transparently? According to > > your description, the interrupt calling convention is differen

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. In https://reviews.llvm.org/D28820#649726, @efriedma wrote: > Why can't the compiler handle this case itself transparently? According to > your description, the interrupt calling convention is different from the > normal hard-float AAPCS calling convention: the VFP re

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

efriedma added a comment. Why can't the compiler handle this case itself transparently? According to your description, the interrupt calling convention is different from the normal hard-float AAPCS calling convention: the VFP registers are all callee-save. The compiler knows this; it should b

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs closed this revision. jroelofs added a comment. r292375 https://reviews.llvm.org/D28820 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs added a comment. In https://reviews.llvm.org/D28820#649384, @rengolin wrote: > Seems like a very specific corner case on ARM, but is that attribute > guaranteed to be ARM-only? > > If so, LGTM as is. If not, avoid mentioning "VFP" on the error message. Yeah, the attribute is parsed in

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

rengolin accepted this revision. rengolin added a comment. This revision is now accepted and ready to land. Seems like a very specific corner case on ARM, but is that attribute guaranteed to be ARM-only? If so, LGTM as is. If not, avoid mentioning "VFP" on the error message. https://reviews.ll

[PATCH] D28820: Warn when calling a non interrupt function from an interrupt on ARM

jroelofs created this revision. Herald added a subscriber: aemerson. The idea for this originated from a really tricky bug: ISRs on ARM don't automatically save off the VFP regs, so if say, memcpy gets interrupted and the ISR itself calls memcpy, the regs are left clobbered when the ISR is done.