Re: Compilation failure in wine-1.1.44

[wylda at volny.cz]

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.