https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88630
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |olegendo at gcc dot gnu.org
--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Zavadovsky Yan from comment #3)
> Created attachment 45301 [details]
> main820.s: assembler output from GCC-8.2.0
I have tried to reproduce the same problem here on trunk but with a non-linux
sh-elf toolchain.
Compiling attachment 45299 with
sh-elf-gcc -x c -m4 -ml -Os -save-temps -fexceptions sh_tmp.cpp
results in the same code as your GCC-8-2.0. There seems nothing wrong with the
code that is generated for function NegateFloatToInt.
Running it with sh-sim produces the expected result.
Yes, there have been some changes how fpscr is handled, but that shouldn't have
any effect. In both cases (GCC 4.9 and GCC 8) what it does is switching the
FPU mode from the default double-precision to single-precision before the
execution of the ftrc instruction. And then back to double-precision before
the function returns.
The difference is that in GCC 4.9, the fpscr switch is done before fneg and
later it's done after fneg. That is OK because fneg does not use and does not
modify any of the fpscr bits.
Are you testing this on real hardware or on some emulator/simulator?
BTW, your posted disassembly doesn't seem to match the actual source that you
have posted. The assert doesn't check for value -12 but instead for the value
123:
mov r8,r0
cmp/eq #123,r0
bt .L6
And the float constant in the code 3270901760 is -123.0f
I have tried to replace the 12 with the 123 but it doesn't trigger any problem
either of course.
