[Buildroot] [PATCH 0/4] Revert wrong NEON/VFPV4 FPU strategy

[Buildroot] [PATCH 0/4] Revert wrong NEON/VFPV4 FPU strategy

[Giulio Benetti]

FPU strategy set to NEON+VFPV4 must be avoided by default.
Here[1] is a good explanation of the reason I report on
every commit log.

[1]: https://lists.buildroot.org/pipermail/buildroot/2022-January/634728.html

Giulio Benetti (4):
  Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"
  Revert "configs/olimex_a20_olinuxino_lime2: use NEON+VFPv4 as FPU
    strategy"
  Revert "configs/olimex_a20_olinuxino_lime: use NEON+VFPv4 as FPU
    strategy"
  Revert "configs/bananapi_m1: use NEON+VFPv4 as FPU strategy"

 configs/bananapi_m1_defconfig                | 1 -
 configs/olimex_a20_olinuxino_lime2_defconfig | 1 -
 configs/olimex_a20_olinuxino_lime_defconfig  | 1 -
 configs/olimex_a33_olinuxino_defconfig       | 1 -
 4 files changed, 4 deletions(-)

-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/4] Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"

[Giulio Benetti]

The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
    If the selected floating-point hardware includes the NEON extension
    (e.g. -mfpu=neon), note that floating-point operations are not
    generated by GCC's auto-vectorization pass unless
    -funsafe-math-optimizations is also specified. This is because NEON
    hardware does not fully implement the IEEE 754 standard for
    floating-point arithmetic (in particular denormal values are treated
    as zero), so the use of NEON instructions may lead to a loss of
    precision.
```

-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.

This reverts commit 23329364e206d5ca67a9eb9c733d3d556ccdbac4.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 configs/olimex_a33_olinuxino_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/olimex_a33_olinuxino_defconfig b/configs/olimex_a33_olinuxino_defconfig
index 27924b9e92..cdbc63efe1 100644
--- a/configs/olimex_a33_olinuxino_defconfig
+++ b/configs/olimex_a33_olinuxino_defconfig
@@ -1,7 +1,6 @@
 # Architecture
 BR2_arm=y
 BR2_cortex_a7=y
-BR2_ARM_FPU_NEON_VFPV4=y
 
 # Linux headers same as kernel, a 5.14 series
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_14=y
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/4] Revert "configs/olimex_a20_olinuxino_lime2: use NEON+VFPv4 as FPU strategy"

[Giulio Benetti]

The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
    If the selected floating-point hardware includes the NEON extension
    (e.g. -mfpu=neon), note that floating-point operations are not
    generated by GCC's auto-vectorization pass unless
    -funsafe-math-optimizations is also specified. This is because NEON
    hardware does not fully implement the IEEE 754 standard for
    floating-point arithmetic (in particular denormal values are treated
    as zero), so the use of NEON instructions may lead to a loss of
    precision.
```

-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.

This reverts commit f8528acdfda278ea9f2f9bc8a47eb77ace0c050f.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 configs/olimex_a20_olinuxino_lime2_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/olimex_a20_olinuxino_lime2_defconfig b/configs/olimex_a20_olinuxino_lime2_defconfig
index a032eb922f..e325184e9e 100644
--- a/configs/olimex_a20_olinuxino_lime2_defconfig
+++ b/configs/olimex_a20_olinuxino_lime2_defconfig
@@ -2,7 +2,6 @@
 BR2_arm=y
 BR2_cortex_a7=y
 BR2_ARM_EABIHF=y
-BR2_ARM_FPU_NEON_VFPV4=y
 
 # Linux headers same as kernel, a 5.15 LTS series
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_15=y
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/4] Revert "configs/olimex_a20_olinuxino_lime: use NEON+VFPv4 as FPU strategy"

[Giulio Benetti]

The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
    If the selected floating-point hardware includes the NEON extension
    (e.g. -mfpu=neon), note that floating-point operations are not
    generated by GCC's auto-vectorization pass unless
    -funsafe-math-optimizations is also specified. This is because NEON
    hardware does not fully implement the IEEE 754 standard for
    floating-point arithmetic (in particular denormal values are treated
    as zero), so the use of NEON instructions may lead to a loss of
    precision.
```

-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.

This reverts commit 115ee0521430d89db8be1a79457b0721ceafc484.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 configs/olimex_a20_olinuxino_lime_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/olimex_a20_olinuxino_lime_defconfig b/configs/olimex_a20_olinuxino_lime_defconfig
index b2364ca59a..ba814b98b8 100644
--- a/configs/olimex_a20_olinuxino_lime_defconfig
+++ b/configs/olimex_a20_olinuxino_lime_defconfig
@@ -2,7 +2,6 @@
 BR2_arm=y
 BR2_cortex_a7=y
 BR2_ARM_EABIHF=y
-BR2_ARM_FPU_NEON_VFPV4=y
 
 # Linux headers same as kernel, a 5.15 LTS series
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_15=y
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 4/4] Revert "configs/bananapi_m1: use NEON+VFPv4 as FPU strategy"

[Giulio Benetti]

The gcc man page states that specifying Neon as part of the fpu setting
has no effect, unless the -funsafe-math-optimizations is also specified,
because Neon is not compliant with IEEE 754:
```
    If the selected floating-point hardware includes the NEON extension
    (e.g. -mfpu=neon), note that floating-point operations are not
    generated by GCC's auto-vectorization pass unless
    -funsafe-math-optimizations is also specified. This is because NEON
    hardware does not fully implement the IEEE 754 standard for
    floating-point arithmetic (in particular denormal values are treated
    as zero), so the use of NEON instructions may lead to a loss of
    precision.
```

-funsafe-math-optimizations must be explictly specified per package to
really use NEON as FPU, but it's something that is left to the user as
well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
offending patch.

This reverts commit aaced92e8c69e3eb71c2cba4c5ae6a1770ae8972.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 configs/bananapi_m1_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/bananapi_m1_defconfig b/configs/bananapi_m1_defconfig
index 2d948ec223..23da363345 100644
--- a/configs/bananapi_m1_defconfig
+++ b/configs/bananapi_m1_defconfig
@@ -1,6 +1,5 @@
 BR2_arm=y
 BR2_cortex_a7=y
-BR2_ARM_FPU_NEON_VFPV4=y
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_18=y
 BR2_TARGET_GENERIC_ISSUE="Welcome to Bananapi M1"
 BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 0/4] Revert wrong NEON/VFPV4 FPU strategy

[Yann E. MORIN]

Giulio, All,

On 2022-08-15 17:48 +0200, Giulio Benetti spake thusly:
> FPU strategy set to NEON+VFPV4 must be avoided by default.
> Here[1] is a good explanation of the reason I report on
> every commit log.
> 
> [1]: https://lists.buildroot.org/pipermail/buildroot/2022-January/634728.html
> 
> Giulio Benetti (4):
>   Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"
>   Revert "configs/olimex_a20_olinuxino_lime2: use NEON+VFPv4 as FPU
>     strategy"
>   Revert "configs/olimex_a20_olinuxino_lime: use NEON+VFPv4 as FPU
>     strategy"
>   Revert "configs/bananapi_m1: use NEON+VFPv4 as FPU strategy"

All four patches applied to master, thanks.

Regards,
Yann E. MORIN.

>  configs/bananapi_m1_defconfig                | 1 -
>  configs/olimex_a20_olinuxino_lime2_defconfig | 1 -
>  configs/olimex_a20_olinuxino_lime_defconfig  | 1 -
>  configs/olimex_a33_olinuxino_defconfig       | 1 -
>  4 files changed, 4 deletions(-)
> 
> -- 
> 2.34.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"

[Arnout Vandecappelle]

On 15/08/2022 17:48, Giulio Benetti wrote:
> The gcc man page states that specifying Neon as part of the fpu setting
> has no effect, unless the -funsafe-math-optimizations is also specified,
> because Neon is not compliant with IEEE 754:
> ```
>      If the selected floating-point hardware includes the NEON extension
>      (e.g. -mfpu=neon), note that floating-point operations are not
>      generated by GCC's auto-vectorization pass unless
>      -funsafe-math-optimizations is also specified. This is because NEON
>      hardware does not fully implement the IEEE 754 standard for
>      floating-point arithmetic (in particular denormal values are treated
>      as zero), so the use of NEON instructions may lead to a loss of
>      precision.
> ```
> 
> -funsafe-math-optimizations must be explictly specified per package to
> really use NEON as FPU,

  That's not true. The statement above is just about auto-vectorization, but 
it's still possible to use intrinsics or inline assembly to use NEON in your 
code. I don't know what exactly happens with those if we specify 
-mfpu=vfpv4-d16, but I expect that it will not compile those. So packages will 
discover that neon is not supported on the target CPU, while actually it is.

  Note that that unsafe-math-optimizations thing was exactly the reason why we 
thought it was OK to allow -mfpu=neon-vfpv4 to begin with - GCC is not going to 
generate invalid code out of the box.

> but it's something that is left to the user as
> well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
> BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
> offending patch.

  I could be wrong, but doesn't the availability of SIMD imply that there are 32 
DP registers?

  Regards,
  Arnout

> 
> This reverts commit 23329364e206d5ca67a9eb9c733d3d556ccdbac4.
> 
> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> ---
>   configs/olimex_a33_olinuxino_defconfig | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/configs/olimex_a33_olinuxino_defconfig b/configs/olimex_a33_olinuxino_defconfig
> index 27924b9e92..cdbc63efe1 100644
> --- a/configs/olimex_a33_olinuxino_defconfig
> +++ b/configs/olimex_a33_olinuxino_defconfig
> @@ -1,7 +1,6 @@
>   # Architecture
>   BR2_arm=y
>   BR2_cortex_a7=y
> -BR2_ARM_FPU_NEON_VFPV4=y
>   
>   # Linux headers same as kernel, a 5.14 series
>   BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_14=y
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"

[Giulio Benetti]

Hi Arnout, Yann, Thomas, All,

On 16/08/22 22:46, Arnout Vandecappelle wrote:
> 
> 
> On 15/08/2022 17:48, Giulio Benetti wrote:
>> The gcc man page states that specifying Neon as part of the fpu setting
>> has no effect, unless the -funsafe-math-optimizations is also specified,
>> because Neon is not compliant with IEEE 754:
>> ```
>>      If the selected floating-point hardware includes the NEON extension
>>      (e.g. -mfpu=neon), note that floating-point operations are not
>>      generated by GCC's auto-vectorization pass unless
>>      -funsafe-math-optimizations is also specified. This is because NEON
>>      hardware does not fully implement the IEEE 754 standard for
>>      floating-point arithmetic (in particular denormal values are treated
>>      as zero), so the use of NEON instructions may lead to a loss of
>>      precision.
>> ```
>>
>> -funsafe-math-optimizations must be explictly specified per package to
>> really use NEON as FPU,
> 
>   That's not true. The statement above is just about auto-vectorization, 
> but it's still possible to use intrinsics or inline assembly to use NEON 
> in your code. I don't know what exactly happens with those if we specify 
> -mfpu=vfpv4-d16, but I expect that it will not compile those. So 
> packages will discover that neon is not supported on the target CPU, 
> while actually it is.
> 
>   Note that that unsafe-math-optimizations thing was exactly the reason 
> why we thought it was OK to allow -mfpu=neon-vfpv4 to begin with - GCC 
> is not going to generate invalid code out of the box.


My bad here. I've written a bad commit log and that phrase is not
correct, you're right. If BR2_ARM_FPU_NEON_VFPV4 is enabled then
processor will use NEON as FPU but with a loss of precision and
without auto-vectorization BUT only if -funsafe-math-optimizations is
passed(very hard to find a package with that flags passed).
So the idea *was* to *not* use VFPV4+NEON by default on defconfigs and
then enable per defconfig, depending on SoC FPU implementation,
the right VFPV4: D16 or D32.
Leaving as it is(with NEON enabled) floating point code generated
will miss some FPU acceleration since IEEE 754 is not met(*I thought*).

BUT then I've found what ARM recommends: [1]

I think we should follow what they recommend. And there is a good
table to follow, of course depending on per SoC FPU implementation if
something is optional according to the cortex-Ax model.
For example they suggest BR2_ARM_FPU_NEON_VFPV4(-mfpu=neon-vfpv4) for
Cortex-A7 if NEON(SIMD) is supported. So yes, these reverts then
don't make sense.

What I understand *now* then is that the loss of precision due to the
fact that *NEON* is not fully IEEE 754 is true only if 
-funsafe-math-optimizations flag is passed.

Otherwise I don't think official ARM website would suggest such table,
right?

Here[3] they clarify it and the table[1] has more sense.
They state:
```
However, the compiler might *not vectorize* the code when you expect it 
to. There are various reasons for this:

     Optimization level for the vectorizer

     *IEEE compliance.*
```

And here[4] a set of command line examples.

The point the yes, it seems to be only about auto-vectorization.

So here I ask myself(and you): do we have better performances with
NEON or without NEON if present even if we loose auto-vectorization?

NOTE: -Ofast has the same effect of -ffast-math that relaxes the rules
and enable vectorization. So that will break IEEE 754 standard anyway,
not only -funsafe-math-optimizations.
So this already happens.

So, do we really need to be so strictly compliant to IEEE 754?
NEON unit seems to "save power and maximize the performance" compared
to VFPV4 as pointed here[3].

>> but it's something that is left to the user as
>> well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
>> BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
>> offending patch.
> 
>   I could be wrong, but doesn't the availability of SIMD imply that 
> there are 32 DP registers?

Judging from the link above:
```
VFPv3 and VFPv4 implementations provide 32 double-precision registers. 
However, when NEON unit is not present, the top sixteen registers 
(D16-D31) become optional. This is shown by the -d16 in the option name, 
which means that the top sixteen D registers are not available
```
Yes, FP+SIMD implies 32 double precision registers. Indeed in the table,
on the column "FP + SIMD" there is no "-d16" passed. That only happens
in the column "FP only".

Then I would like to adjust any defconfig according to SoC's FPU
implementation according to that table. What about this?

The other chance would be directly testing on different SoCs
what happens with a program/package that uses floating point datas.
But that table talks pretty clear IMHO. And anyway I have planned
to bump all Olimex Allwinner boards as well as Asus Tinker and
Amarula Vyasa. So I'll have the chance to test it.
So:
cortex-A7
cortex-A8
cortex-A17(the table doesn't talk about that but here[2] we can
see that A12/A15/A17 have both VFPV4+NEON so I can follow the column
for A15)

Actually I don't have boards with A5 and A9. So maybe we can ask to
Microchip SAMA5 maintainers and NXP i.MX6 maintainers to give a try
the next time they bump u-boot/linux.

Which package could be the right one to see if everything works
smooth instead of hanging because of FPU illegal instruction?

Hope I'm on the right direction and at least providing some new
informations. It's pretty intricate this part.

I wait for your thoughts on this. Sorry if something is not that clear,
I'm trying to clarify myself!

Thank you!

[1]: 
https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Option-to-specify-the-FPU
[2]: https://en.wikipedia.org/wiki/Comparison_of_ARMv7-A_processors
[3]: 
https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Vectorizing-floating-point-operations
[4]: 
https://developer.arm.com/documentation/den0018/a/Compiling-NEON-Instructions/GCC-command-line-options/Example-GCC-command-line-usage-for-NEON-code-optimization

Best regards
-- 
Giulio Benetti
Benetti Engineering sas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] Revert "configs/olimex_a33_olinuxino: use NEON+VFPv4 as FPU strategy"

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:

 > The gcc man page states that specifying Neon as part of the fpu setting
 > has no effect, unless the -funsafe-math-optimizations is also specified,
 > because Neon is not compliant with IEEE 754:
 > ```
 >     If the selected floating-point hardware includes the NEON extension
 >     (e.g. -mfpu=neon), note that floating-point operations are not
 >     generated by GCC's auto-vectorization pass unless
 >     -funsafe-math-optimizations is also specified. This is because NEON
 >     hardware does not fully implement the IEEE 754 standard for
 >     floating-point arithmetic (in particular denormal values are treated
 >     as zero), so the use of NEON instructions may lead to a loss of
 >     precision.
 > ```

 > -funsafe-math-optimizations must be explictly specified per package to
 > really use NEON as FPU, but it's something that is left to the user as
 > well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
 > BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
 > offending patch.

 > This reverts commit 23329364e206d5ca67a9eb9c733d3d556ccdbac4.

 > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>

Committed to 2022.05.x and 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/4] Revert "configs/olimex_a20_olinuxino_lime2: use NEON+VFPv4 as FPU strategy"

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:

 > The gcc man page states that specifying Neon as part of the fpu setting
 > has no effect, unless the -funsafe-math-optimizations is also specified,
 > because Neon is not compliant with IEEE 754:
 > ```
 >     If the selected floating-point hardware includes the NEON extension
 >     (e.g. -mfpu=neon), note that floating-point operations are not
 >     generated by GCC's auto-vectorization pass unless
 >     -funsafe-math-optimizations is also specified. This is because NEON
 >     hardware does not fully implement the IEEE 754 standard for
 >     floating-point arithmetic (in particular denormal values are treated
 >     as zero), so the use of NEON instructions may lead to a loss of
 >     precision.
 > ```

 > -funsafe-math-optimizations must be explictly specified per package to
 > really use NEON as FPU, but it's something that is left to the user as
 > well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
 > BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
 > offending patch.

 > This reverts commit f8528acdfda278ea9f2f9bc8a47eb77ace0c050f.

 > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>

Committed to 2022.05.x and 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] Revert "configs/olimex_a20_olinuxino_lime: use NEON+VFPv4 as FPU strategy"

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:

 > The gcc man page states that specifying Neon as part of the fpu setting
 > has no effect, unless the -funsafe-math-optimizations is also specified,
 > because Neon is not compliant with IEEE 754:
 > ```
 >     If the selected floating-point hardware includes the NEON extension
 >     (e.g. -mfpu=neon), note that floating-point operations are not
 >     generated by GCC's auto-vectorization pass unless
 >     -funsafe-math-optimizations is also specified. This is because NEON
 >     hardware does not fully implement the IEEE 754 standard for
 >     floating-point arithmetic (in particular denormal values are treated
 >     as zero), so the use of NEON instructions may lead to a loss of
 >     precision.
 > ```

 > -funsafe-math-optimizations must be explictly specified per package to
 > really use NEON as FPU, but it's something that is left to the user as
 > well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
 > BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
 > offending patch.

 > This reverts commit 115ee0521430d89db8be1a79457b0721ceafc484.

 > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>

Committed to 2022.05.x and 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/4] Revert "configs/bananapi_m1: use NEON+VFPv4 as FPU strategy"

[Peter Korsgaard]

>>>>> "Giulio" == Giulio Benetti <giulio.benetti@benettiengineering.com> writes:

 > The gcc man page states that specifying Neon as part of the fpu setting
 > has no effect, unless the -funsafe-math-optimizations is also specified,
 > because Neon is not compliant with IEEE 754:
 > ```
 >     If the selected floating-point hardware includes the NEON extension
 >     (e.g. -mfpu=neon), note that floating-point operations are not
 >     generated by GCC's auto-vectorization pass unless
 >     -funsafe-math-optimizations is also specified. This is because NEON
 >     hardware does not fully implement the IEEE 754 standard for
 >     floating-point arithmetic (in particular denormal values are treated
 >     as zero), so the use of NEON instructions may lead to a loss of
 >     precision.
 > ```

 > -funsafe-math-optimizations must be explictly specified per package to
 > really use NEON as FPU, but it's something that is left to the user as
 > well as setting BR2_ARM_FPU_NEON_VFPV4. This way the default
 > BR2_ARM_FPU_VFPV4D16 is used as previously. So let's revert the
 > offending patch.

 > This reverts commit aaced92e8c69e3eb71c2cba4c5ae6a1770ae8972.

 > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>

Committed to 2022.05.x and 2022.02.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot