Re: GCC 10 using floating-point registers to pass some 64-bit arguments on ARM Cortex-M

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/05/2020 17:17, Freddie Chopin wrote:
> Hello!
> 
> I have some functions which accept a `std::chrono::duration` or
> `std::chrono::time_point` arguments, both based on an 64-bit integers
> `long long`. I'm compiling my code for ARM Cortex-M4 microcontroler,
> which has "fpv4-sp-d16" FPU. On all GCCs up to (and including) GCC 9
> such arguments were passed in core registers or via stack. In GCC 10
> sometimes they are passed via d7 VFP register, sometimes via stack,
> possibly sometimes via core registers (did not check that yet [; ).
> 

Only d7?  No, that couldn't be right.  d7 would only be used if d0-d6
had also been used.

> I suppose this change is related to this entry from 
> https://gcc.gnu.org/gcc-10/changes.html :
> 
> "The handling of 64-bit integer operations has been significantly
> reworked and improved leading to improved performance and reduced stack
> usage when using 64-bit integral data types. The option -mneon-for-
> 64bits is now deprecated and will be removed in a future release."

No, those changes are for handling of 64-bit integral values where we
no-longer use Neon to perform those options and have improved the way
code is generated to handle them using the GP registers.

> 
> If that's the case, then is there any way I could control this
> behaviour and disable it (obviously other than disabling FPU completely
> (; )? Maybe this change is related to something else instead (maybe
> "The ABI of passing and returning certain C++ classes by value changed
> on several targets in GCC 10, including AArch64, ARM, PowerPC ELFv2,
> S/390 and Itanium.")?
> 
> I have a very specific use case for that - for my bare-metal RTOS I
> have a test application that verifies correct behaviour of my code for
> context stacking and restoring in situation where threads use/don't-use 
> FPU, when threads that use/don't-use FPU are interrupted by chip
> interrupts using/not-using FPU and so on. My problem with the new
> behaviour in my very specific tests is that I can no longer control
> whether the thread uses the FPU or not, which severely limits possible
> combinations of test cases. To be more precse - I can no longer write a
> thread that doesn't use FPU, even if I never use any floating point
> operations explicitly. That's why I'm wondering whether there's a way
> to disable this only for my test application.
> 
> Thanks in advance!
> 
> Regards,
> FCh
> 

Testcase needed.

R.




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux