[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239 --- Comment #6 from Maciej Andrzejewski maciej.andrzejewski at data dot pl --- Libm and other libs have been mixed. Properly compiled toolchain with libs solved the problem. Thank you all for assistance!
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239 Maciej Andrzejewski maciej.andrzejewski at data dot pl changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Maciej Andrzejewski maciej.andrzejewski at data dot pl --- Libm and other libs have been mixed. Properly compiled toolchain with libs solved the problem. Thank you all for assistance!
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239
--- Comment #1 from Maciej Andrzejewski maciej.andrzejewski at data dot pl ---
It is getting even more interesting.
I have disassabled 4 binaries compiled with options:
1) -mfloat-abi=softfp
2) -mfloat-abi=softfp -O
3) -mfloat-abi=hard
4) -mfloat-abi=hard -O
and from what I understand if we turn ON the optimization the FPU is turned
OFF!
I dont see in assembler that FPU s** registers are used in those two cases
where optimization is turned on:
-- DISASSAMBLE OPTION 1 --
00010570 main:
10570: e92d4800push{fp, lr}
10574: e28db004add fp, sp, #4
10578: e24dd040sub sp, sp, #64 ; 0x40
1057c: e3032333movwr2, #13107 ; 0x
10580: e3432333movtr2, #13107 ; 0x
10584: e303movwr3, #13107 ; 0x
10588: e3443022movtr3, #16418 ; 0x4022
1058c: e14b20fcstrdr2, [fp, #-12]
10590: ed5b0b03vldrd16, [fp, #-12]
10594: eef77be0vcvt.f32.f64s15, d16
10598: ee170a90vmovr0, s15
1059c: eba1bl 10428 sqrtf@plt
105a0: ee070a90vmovs15, r0
105a4: eef70ae7vcvt.f64.f32d16, s15
105a8: ed4b0b05vstrd16, [fp, #-20] ; 0xffec
105ac: e30006ccmovwr0, #1740 ; 0x6cc
105b0: e341movtr0, #1
105b4: e14b21d4ldrdr2, [fp, #-20] ; 0xffec
105b8: eba0bl 10440 printf@plt
105bc: e309399amovwr3, #39322 ; 0x999a
105c0: e3443111movtr3, #16657 ; 0x4111
105c4: e50b3018str r3, [fp, #-24] ; 0xffe8
105c8: e51b0018ldr r0, [fp, #-24] ; 0xffe8
105cc: eb95bl 10428 sqrtf@plt
105d0: ee070a90vmovs15, r0
105d4: eef70ae7vcvt.f64.f32d16, s15
105d8: ed4b0b09vstrd16, [fp, #-36] ; 0xffdc
105dc: e30006ccmovwr0, #1740 ; 0x6cc
105e0: e341movtr0, #1
105e4: e14b22d4ldrdr2, [fp, #-36] ; 0xffdc
105e8: eb94bl 10440 printf@plt
105ec: e3032333movwr2, #13107 ; 0x
105f0: e3432333movtr2, #13107 ; 0x
105f4: e303movwr3, #13107 ; 0x
105f8: e3443022movtr3, #16418 ; 0x4022
105fc: e14b22fcstrdr2, [fp, #-44] ; 0xffd4
10600: e14b02dcldrdr0, [fp, #-44] ; 0xffd4
10604: eb8abl 10434 sqrt@plt
10608: e14b03f4strdr0, [fp, #-52] ; 0xffcc
1060c: e30006ccmovwr0, #1740 ; 0x6cc
10610: e341movtr0, #1
10614: e14b23d4ldrdr2, [fp, #-52] ; 0xffcc
10618: eb88bl 10440 printf@plt
1061c: e309399amovwr3, #39322 ; 0x999a
10620: e3443111movtr3, #16657 ; 0x4111
10624: e50b3038str r3, [fp, #-56] ; 0xffc8
10628: ed5b7a0evldrs15, [fp, #-56] ; 0xffc8
1062c: eef70ae7vcvt.f64.f32d16, s15
10630: ec510b30vmovr0, r1, d16
10634: eb7ebl 10434 sqrt@plt
10638: e14b04f4strdr0, [fp, #-68] ; 0xffbc
1063c: e30006ccmovwr0, #1740 ; 0x6cc
10640: e341movtr0, #1
10644: e14b24d4ldrdr2, [fp, #-68] ; 0xffbc
10648: eb7cbl 10440 printf@plt
1064c: e3a03000mov r3, #0
10650: e1a3mov r0, r3
10654: e24bd004sub sp, fp, #4
10658: e8bd8800pop {fp, pc}
-- DISASSAMBLE OPTION 1 --
-- DISASSAMBLE OPTION 2 --
000104f4 main:
104f4: e92d40d0push{r4, r6, r7, lr}
104f8: e30045d4movwr4, #1492 ; 0x5d4
104fc: e3404001movtr4, #1
10500: e3a06000mov r6, #0
10504: e302720amovwr7, #8714 ; 0x220a
10508: e3447008movtr7, #16392 ; 0x4008
1050c: e1a4mov r0, r4
10510: e1a02006mov r2, r6
10514: e1a03007mov r3, r7
10518: eba9bl 103c4 printf@plt
1051c: e1a4mov r0, r4
10520: e1a02006mov r2, r6
10524: e1a03007mov r3, r7
10528: eba5bl 103c4 printf@plt
1052c: e1a4mov r0, r4
10530: e30f2d38movwr2, #64824 ;
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to Maciej Andrzejewski from comment #1)
It is getting even more interesting.
I have disassabled 4 binaries compiled with options:
1) -mfloat-abi=softfp
2) -mfloat-abi=softfp -O
3) -mfloat-abi=hard
4) -mfloat-abi=hard -O
and from what I understand if we turn ON the optimization the FPU is turned
OFF!
I dont see in assembler that FPU s** registers are used in those two cases
where optimization is turned on:
Yeah it's called constant folding in the compiler. Why make the cpu do more
work at run time when the compiler can statically tell you the value for sqrt
of a floating point value. The cycles spent in compiling with -O have to give
you some value surely ... :)
I have no idea why your -O0 case fails though, offhand.
Ramana
-- DISASSAMBLE OPTION 1 --
00010570 main:
10570: e92d4800push{fp, lr}
10574: e28db004add fp, sp, #4
10578: e24dd040sub sp, sp, #64 ; 0x40
1057c: e3032333movwr2, #13107 ; 0x
10580: e3432333movtr2, #13107 ; 0x
10584: e303movwr3, #13107 ; 0x
10588: e3443022movtr3, #16418 ; 0x4022
1058c: e14b20fcstrdr2, [fp, #-12]
10590: ed5b0b03vldrd16, [fp, #-12]
10594: eef77be0vcvt.f32.f64s15, d16
10598: ee170a90vmovr0, s15
1059c: eba1bl 10428 sqrtf@plt
105a0: ee070a90vmovs15, r0
105a4: eef70ae7vcvt.f64.f32d16, s15
105a8: ed4b0b05vstrd16, [fp, #-20] ; 0xffec
105ac: e30006ccmovwr0, #1740 ; 0x6cc
105b0: e341movtr0, #1
105b4: e14b21d4ldrdr2, [fp, #-20] ; 0xffec
105b8: eba0bl 10440 printf@plt
105bc: e309399amovwr3, #39322 ; 0x999a
105c0: e3443111movtr3, #16657 ; 0x4111
105c4: e50b3018str r3, [fp, #-24] ; 0xffe8
105c8: e51b0018ldr r0, [fp, #-24] ; 0xffe8
105cc: eb95bl 10428 sqrtf@plt
105d0: ee070a90vmovs15, r0
105d4: eef70ae7vcvt.f64.f32d16, s15
105d8: ed4b0b09vstrd16, [fp, #-36] ; 0xffdc
105dc: e30006ccmovwr0, #1740 ; 0x6cc
105e0: e341movtr0, #1
105e4: e14b22d4ldrdr2, [fp, #-36] ; 0xffdc
105e8: eb94bl 10440 printf@plt
105ec: e3032333movwr2, #13107 ; 0x
105f0: e3432333movtr2, #13107 ; 0x
105f4: e303movwr3, #13107 ; 0x
105f8: e3443022movtr3, #16418 ; 0x4022
105fc: e14b22fcstrdr2, [fp, #-44] ; 0xffd4
10600: e14b02dcldrdr0, [fp, #-44] ; 0xffd4
10604: eb8abl 10434 sqrt@plt
10608: e14b03f4strdr0, [fp, #-52] ; 0xffcc
1060c: e30006ccmovwr0, #1740 ; 0x6cc
10610: e341movtr0, #1
10614: e14b23d4ldrdr2, [fp, #-52] ; 0xffcc
10618: eb88bl 10440 printf@plt
1061c: e309399amovwr3, #39322 ; 0x999a
10620: e3443111movtr3, #16657 ; 0x4111
10624: e50b3038str r3, [fp, #-56] ; 0xffc8
10628: ed5b7a0evldrs15, [fp, #-56] ; 0xffc8
1062c: eef70ae7vcvt.f64.f32d16, s15
10630: ec510b30vmovr0, r1, d16
10634: eb7ebl 10434 sqrt@plt
10638: e14b04f4strdr0, [fp, #-68] ; 0xffbc
1063c: e30006ccmovwr0, #1740 ; 0x6cc
10640: e341movtr0, #1
10644: e14b24d4ldrdr2, [fp, #-68] ; 0xffbc
10648: eb7cbl 10440 printf@plt
1064c: e3a03000mov r3, #0
10650: e1a3mov r0, r3
10654: e24bd004sub sp, fp, #4
10658: e8bd8800pop {fp, pc}
-- DISASSAMBLE OPTION 1 --
-- DISASSAMBLE OPTION 2 --
000104f4 main:
104f4: e92d40d0push{r4, r6, r7, lr}
104f8: e30045d4movwr4, #1492 ; 0x5d4
104fc: e3404001movtr4, #1
10500: e3a06000mov r6, #0
10504: e302720amovw
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- FWIW I can't reproduce on a bare-metal arm-none-eabi trunk (i.e. future GCC 6) With: -mcpu=cortex-a8 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mthumb-interwork -mfpu=neon -Wall -Wextra -mfloat-abi=soft prsqrt.c -specs=rdimon.specs -lm I get: 3.016621 3.016621 3.016621 3.016621 Note that I also had to add -lm to link the sqrt and sqrtf functions in. Considering that the -O0 version is the only one that ends up calling the library functions, perhaps there's something wrong with your math library? I'm using newlib for arm-none-eabi
[Bug c++/66239] Unoptimized sqrt(float or double) returns wrong values for ARM Cortex-A8 -mfloat-abi=[soft,softfp]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66239 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-05-21 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to ktkachov from comment #3) Considering that the -O0 version is the only one that ends up calling the library functions, perhaps there's something wrong with your math library? I'm using newlib for arm-none-eabi Or maybe the libm that is not using the correct ABI. Since you did not place how you built gcc, it is hard to tell right away.
