Ben Klein:
Any cases where -O0 and -O2 give different results for backtraces are
bugs in the gcc optimisation code, not in Wine.
And this was excatly one of the reasons, why use -O0. I do not want to report gcc bugs in wine's bugzilla.
Speed of code execution is an issue primarily with latency and race
condition issues and/or bugs.
Correct me, if i'm wrong, but these kind of wine bugs aren't "100%", because they can be influenced by other thing. Can singlecore vs multicore CPU has any impact for reproducibility??
Anyway, i'm only able to bisect bugs, which are always reproducible the same way, so i can easily suite that results into bisect good/bad. Anything beyond causes, that i leave such bug report (i'm mostly interested in looking for some other's reported regression and their retest).
So as other people are reporting problem (99% ?? with default -02) and i join such bug report with regression report from -O0, i shouldn't mess bugzilla with rubbish.
For regression testing, make distclean is generally a bad idea as it really does take a long time.
This is generally not true for example in between 1.1.30~.31 (if i remember correctly). I was not able to find any game regression this way. I had always "git bisect bad". Fixed by in between "make distclean".
Either way, ccache mitigates increases in time, and -O0 may theoretically produce false positives for bug testing where the issue is latency or race condition related.
As i wrote above, i would probably avoid such bug report retest. And also compare this (rare??) case with number of FP in bugzilla (all those marked as INVALID, etc.). Hopefully bugzilla state is not getting worse with my -O0 ;-)
I don't think Quake 3 counts as number-crunching. I imagine heavy number-crunching apps would suffer significantly more with -O0.
Agree.