On 5/6/24 23:35, Toon Moene wrote:
On 5/6/24 23:32, Andrew Pinski wrote:
Did you test x86_64 with -march=native (or with -mfma) or just -O3?
The reason why I am asking is aarch64 includes FMA by default while
x86_64 does not.
Most recent x86_64 includes an FMA instruction but since the base IS
On 5/6/24 23:32, Andrew Pinski wrote:
Did you test x86_64 with -march=native (or with -mfma) or just -O3?
The reason why I am asking is aarch64 includes FMA by default while
x86_64 does not.
Most recent x86_64 includes an FMA instruction but since the base ISA
does not include it, it is not enab
On Mon, May 6, 2024 at 2:27 PM Toon Moene wrote:
>
> I have now, for some time, ran LAPACK's test programs on my gcc/gfortran
> builds on both on the x86_64-linux-gnu architecture, as well as the
> aarch64-linux-gnu one (see, e.g.,
> http://moene.org/~toon/lapack-amd64-gfortran13-O3).
>
> The resu
I have now, for some time, ran LAPACK's test programs on my gcc/gfortran
builds on both on the x86_64-linux-gnu architecture, as well as the
aarch64-linux-gnu one (see, e.g.,
http://moene.org/~toon/lapack-amd64-gfortran13-O3).
The results are rather alarming - this is r15-202 for aarch64 vs r1
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and also
fixes an accepts-invalid (see testcase), plus maybe some more,
related due to incomplete checking of symbol attribute conflicts.
The fix does not fully address th
> libgfortran/ChangeLog:
> * config/t-aix (all-local, libcaf_single): Explicitly reference
> caf/.libs/single.o
OK, and sorry for the breakage.
FX
aix: Fix building fat library for AIX
With the change in subdirectories, the code for libgfortran fat
libraries
needs to be adjusted to explicitly reference the subdirectory. AIX
creates fat library archives and the compiler itself can be built as
either 32 bit or 64 bit appli
Hi FX,
>> This patch fixes this by allowing for the new structure.
>> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
>>
>> Ok for trunk?
>
> OK to push, given it’s localised inside LIBGFOR_USE_SYMVER_SUN.
>
> I find it weird though that .libs is harcoded there. If we look at all the
> l