Re: [fpc-devel] Possible bug in fpc_round_real for softfloat?

Raspberry Pi, what OS, because you write armsf and the default on Raspbian (and other major distro's) is armhf. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

J. Gareth Moreton schrieb am Mi., 19. Feb. 2020, 01:40: > Ah, I understand, thank you. > > I chose those two tests in particular because the design with multiple > typecasts opens it up to a lot of peephole optimisations. > The nightly testsuite is run multiple times with different settings, so

Re: [fpc-devel] Possible bug in fpc_round_real for softfloat?

Hi, Am 19.02.20 um 09:08 schrieb thaddy: > Raspberry Pi, what OS, because you write armsf and the default on > Raspbian (and other major distro's) is armhf. Raspbian, which is armhf, yes. The application is based on the hard-float ABI (just checked with readelf -h). Still it is using the soft-fl

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

Fair enough.  The tests were in a separate patch file anyway so they're easily excluded.  It was more for my benefit anyway because my computer is not the most high-end and frequently runs out of space (one reason why I proposed using SLEB128 and ULEB128 for some of the fields in compiled PPU f

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

Am 19.02.20 um 11:23 schrieb Sven Barth via fpc-devel: J. Gareth Moreton > schrieb am Mi., 19. Feb. 2020, 01:40: Ah, I understand, thank you. I chose those two tests in particular because the design with multiple typecasts opens it up to a lot of pe

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

Am 19.02.2020 um 20:37 schrieb Florian Klämpfl: Am 19.02.20 um 11:23 schrieb Sven Barth via fpc-devel: J. Gareth Moreton > schrieb am Mi., 19. Feb. 2020, 01:40:     Ah, I understand, thank you.     I chose those two tests in particular because the design with

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

True, the test was not about the optimisation, but proved to be the most useful because it turned out that all the typecasting and constant propagation (or lack of) was perfect for seeing how the peephole optimizer handled mov/movzx and mov/movsx pairs.  There was an existing test named tcnvint

Re: [fpc-devel] Possible bug in fpc_round_real for softfloat?

It is a bit more complex than that: using the softfloat ABI does not necessarily mean softfloat is used. The ABI can still use hardware fp. And that is the case here, I suspect. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.fre