Hey folks,
My colleague Nicolas Savoire created a compiler reproducer[0] for the
effect -- you can see a side-by-side comparison of code compiled with GCC
8.x and 9.x where 8.x emits fmov instructions and 9.x does not. He further
used this example as a git bisect criteria and eventually found the
On Mon, Feb 24, 2025 at 10:46:42AM +0100, Attila Szegedi wrote:
> Hi folks,
Hi,
I've been pointed at this thread due to the reference to my Linux patch
series fixing some KVM FPSIMD/SVE/SME issues.
> I'm looking for a bit of a historic context for a fun GCC behavior we
> stumbled across. For...
On Mon, Feb 24, 2025 at 1:21 PM Florian Weimer wrote:
> * Attila Szegedi:
>
> >> That seems … quite unlikely. GCC 8 has seen extensive use on
> >> AArch64, on a variety of implementations, and I don't recall
> >> problems in this area. I don't follow AArch64 *that* closely,
> >> admittedly, but
* Attila Szegedi:
>> That seems … quite unlikely. GCC 8 has seen extensive use on
>> AArch64, on a variety of implementations, and I don't recall
>> problems in this area. I don't follow AArch64 *that* closely,
>> admittedly, but I expect it would have caused quite a ruckus.
>>
>
> Yeah. The lac
On Mon, Feb 24, 2025 at 12:41 PM Florian Weimer wrote:
>
> Surely not preserving floating point bit patterns in registers would
> be a silicon bug?
Indeed it would be.
> That seems … quite unlikely. GCC 8 has seen
> extensive use on AArch64, on a variety of implementations, and I don't
> rec
* Attila Szegedi via Gcc:
> We noticed that this version of GCC compiling on aarch64 will happily use
> FP registers to temporarily store/load pointers, so there'd be "fmov d9,
> x1" to store a pointer, and then later when it's used as a parameter to a
> function call we'll see "fmov x1, d9" etc.
Hi Attila,
> On 24 Feb 2025, at 10:46, Attila Szegedi via Gcc wrote:
>
> Hi folks,
>
> I'm looking for a bit of a historic context for a fun GCC behavior we
> stumbled across. For... reasons we build some of our binaries using an
> older version of GCC (8.3.1, yes, we'll be upgrading soon, and
Hi folks,
I'm looking for a bit of a historic context for a fun GCC behavior we
stumbled across. For... reasons we build some of our binaries using an
older version of GCC (8.3.1, yes, we'll be upgrading soon, and no, this
message is not about helping with an ancient version :-) )
We noticed that