-
Notifications
You must be signed in to change notification settings - Fork 761
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove -fstrict-aliasing from the MinGW build to allow using MinGW 4.9.2 #1923
Conversation
We have a problem here. No reactions at all, and a release deadline approaching that I've been working towards. I need to make adjustments to the Readme once this get's committed, and I am likely to lose the opportunity if this becomes a last minute commit before the release. |
If it just affects the MinGW build then there should be few complaints. You've commented it well so we know what it is in the future. If nobody else can speak against it today then go ahead and merge this evening. |
hi Rainer, my DIY benchmarks show that these builds are a bit slower. 47 vs 44% and 0.80 vs 0.68 on the bbb before. but i didn’t do extensive testing.
#| |
Thanks for confirming, @redFrik! I was actually wondering whether this would help for ARM too. Currently my PR is restricted to Windows only with the MinGW brackets. Extending it to GCC in general would extend it to all Linux platforms, including the many that don't need it. If I am not mistaken, the ARM builds for the time being still require a lot of manual adjustments anyways. Would it be okay to rely on adding that specific flag manually for ARM, at least on the 3.7 branch? I have a feeling that we might be in for a positive surprise on latest master, and if not, we could still add something adjusted more precisely to the scope of this setting on master in a while? |
agree. don’t add it to master/3.7 linux. manual adjustment for arm is fine now (it’s anyway such a mess of flapping compiler flags).
#| |
To use MinGW 4.9.2 allows to use the same toolchain for sc that is used in the Qt build. The actual underlying issue is beyond my understanding, but Googling it a bit shows that it is not a trivial issue for anybody. In view of that it might simply be more careful to avoid this optimization.
It would be nice to have a quick decision on this, because I'll make a few simplifications to the Readme if this is committed.