fix bugzilla Issue 24819 - Optimizer changes result of float calculat…

[WalterBright]

…ions on 32-bit

Thanks to @dkorpel for zeroing in on the problem.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	24819	major	Optimizer changes result of float calculations on 32-bit

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#17023"

[thewilsonator]

Shouldn't the test case have -O as an argument?

Also this is a "major" issue, did you want to target stable for it?

[WalterBright]

Shouldn't the test case have -O as an argument?

I thought it was good to test every combination.

Also this is a "major" issue, did you want to target stable for it?

@dkorpel is working with a customer on this, so I'll let him make that call. (It's been there a very long time.)

[thewilsonator]

I thought it was good to test every combination.

Isn't that what permute args is for?

so I'll let him make that call.

Fair

[dkorpel]

Isn't that what permute args is for?

The default permute set is (-inline -release -g -O), so -O doesn't need to be added manually.

[dkorpel]

Thanks! Did you find out why the sqrt instruction disappears with the x ^ signbit optimization? I hope there's no other latent bugs with integer optimizations on floating point math.

[thewilsonator]

The default permute set is (-inline -release -g -O), so -O doesn't need to be added manually.

Yes but there is no //PERMUTE_ARGS directive(or however it is spelled) in the test file.

[veelo]

Many thanks for working on this, guys! I know we are probably the last bunch that need x87 to work correctly.

[dkorpel]

Yes but there is no //PERMUTE_ARGS directive(or however it is spelled) in the test file.

With default I mean that even without any PERMUTE_ARGS directive, it's testing both -O and unoptimized amongst other things.

[WalterBright]

did you find out ...

No, I just went with the elem tree was malformed.

[WalterBright]

That optimization was a relic of the old no-x87 CPUs.

[veelo]

This fix is important to us. Does it help if I make a PR to the stable branch with a cherry pick of this commit, or does that only add to your workload, @ibuclaw? Is master going to be merged into stable before the next beta release? (Edit: there is another change in master that will benefit us as well: #16780).

It would be good to have an approximate ETA of the next release. If that is months from now, we would have to decide between two unpopular options: 1. to use the nightly build, putting us on master, or 2. build our own compiler, possibly missing out on PGO. In both cases we mess up our system for reproducible builds (which relies on official version tags and the release archive).

[thewilsonator]

Is master going to be merged into stable before the next beta release?

No. If you want them in the next release, please cherrypick this and #16780 onto stable
I don't think exact duplicate commits cause merge conflicts, but if you want to, you could always rebase master on top of stable after you are done.