On 02/10/2023 18:12, Wilco Dijkstra wrote:
Hi Ramana,
I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf
--build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the
default armhf settings are incorrect. I shouldn't need the --with-float=hard
since
that is obviously implied by armhf, and they should also imply armv7-a with
vfpv3
according to documentation. It seems to get confused and skip some tests. I
tried
using --with-fpu=auto, but that doesn't work at all, so in the end I forced it
like:
--with-arch=armv8-a --with-fpu=neon-fp-armv8. With this it runs a few more
tests.
Yeah that's a wart that I don't like.
armhf just implies the hard float ABI and came into being to help
distinguish from the Base PCS for some of the distros at the time
(2010s). However we didn't want to set a baseline arch at that time
given the imminent arrival of v8-a and thus the specification of
--with-arch , --with-fpu and --with-float became second nature to many
of us working on it at that time.
Looking at it, the default is indeed incorrect, you get:
'-mcpu=arm10e' '-mfloat-abi=hard' '-marm' '-march=armv5te+fp'
That's not incorrect. It's the first version of the architecture that
can support the hard-float ABI.
That's like 25 years out of date!
It's not a matter of being out of date (and it's only 22 years since
arm1020e was announced ;) it's a matter of being as compatible as we can
be with existing hardware out-of-the-box. Distros are free, of course,
to set a higher bar and do so.
However all the armhf distros have Armv7-a as the baseline and use Thumb-2:
'-mfloat-abi=hard' '-mthumb' '-march=armv7-a+fp'
Wrong. Rawhide uses Arm state (or it did last I checked). As I
mentioned above, distros are free to set a higher bar.
So the issue is that dg-require-effective-target arm_arch_v7a_ok doesn't work on
armhf. It seems that if you specify an architecture even with hard-float
configured,
it turns off FP and then complains because hard-float implies you must have
FP...
OK, I think I see the problem there, it's in the data for
proc add_options_for_arm_arch_FUNC
in lib/target-supports.exp. In order to work correctly with -mfpu=auto,
the -march flags in the table need "+fp" adding in most cases (pretty
much everything from armv5e onwards) - that's harmless whenever the
float-abi is soft, but should do the right thing when softfp or hard are
used.
So in most configurations Iincluding the one used by distro compilers) we
basically
skip lots of tests for no apparent reason...
Ok, thanks for promising to do so - I trust you to get it done. Please
try out various combinations of -march v7ve, v7-a , v8-a with the tool
as each of them have slightly different rules. For instance v7ve
allows LDREXD and STREXD to be single copy atomic for 64 bit loads
whereas v7-a did not .
You mean LDRD may be generated on CPUs with LPAE. We use LDREXD by
default since that is always atomic on v7-a.
Ok if no regressions but as you might get nagged by the post commit CI ...
Thanks, I've committed it. Those links don't show anything concrete, however I
do note
the CI didn't pick up v2.
Btw you're happy with backports if there are no issues reported for a few days?
Cheers,
Wilco
R.
