Re: Compilation failure in wine-1.1.44
On Sat, 8 May 2010, wy...@volny.cz wrote: [...] > > * Not testing the code under Release conditions. > > I guess, that running Word2007 under linux/wine also does not meet release > conditions by Microsoft ;-) Anyway, i hope that if i run Win program > calculating PI on 4 decimal place, both -O0 and -02 will give me 3.1415 It would be better if both gave 3.1416... -- Francois Gouget http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Re: Compilation failure in wine-1.1.44
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.
Re: Compilation failure in wine-1.1.44
On 9 May 2010 06:21, wrote: > Hi Marcus, > >> > * better backtraces for bug reports >> >> -O2 works like a charm there too, at least for me. > > I think i read that somewhere and if i understood that correctly, my > conclusion at that time was, that -02 optimizes the code, so it can > "omit some" part of code and replace them by faster alternative. But > the debuging symbols then don't correspond such optimized code... And > even if i usually don't understand those backtraces, i want to provide > them as much readable for developer as possible. The debugging symbols do match to the optimised code, and refer you back to the unoptimised line of source. Any cases where -O0 and -O2 give different results for backtraces are bugs in the gcc optimisation code, not in Wine. >> * Not testing the code under Release conditions. > > I guess, that running Word2007 under linux/wine also does not meet release > conditions by Microsoft ;-) Anyway, i hope that if i run Win program > calculating PI on 4 decimal place, both -O0 and -02 will give me 3.1415 The point is that Wine's code for releases is not compiled with -O0. We don't want Word2007 bugs on bugs.winehq.org. GCC's optimisation has nothing to do with accuracy; it's all to do with speed. Speed of code execution is an issue primarily with latency and race condition issues and/or bugs. >> * Slow code. > > This line caused all this replay :) Because it does not says "How much". > So i did some benchmarking which maybe some others find useful. > > Compilation of 1.1.43 -O0: > * real 1m 58sec > > Compilation of 1.1.43 -O2: > * real 3m 29sec > > i.e. -02 is 77% slower. So 10 round of regression test (with in-between > make distclean) is slower in case of -02 cca about 15m 10sec. That's > a lot especially if i want to take bug testing seriously. "Slow code" and "slow compilation" are very different concerns. For regression testing, make distclean is generally a bad idea as it really does take a long time. 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. > Quake 3 1600x1200: > -O0: 215.0 FPS > -O2: 220.1 FPS (2% faster) > > Quake 3 640x480: > -O0: 548.3 FPS > -O2: 581.0 FPS (6% faster) > > As i'm not pro-gamer anymore and the -O2 results aren't convincing i'll > stay at -O0. Of course everyone has different needs and can find -O2 > useful. I don't think Quake 3 counts as number-crunching. I imagine heavy number-crunching apps would suffer significantly more with -O0.
Re: Compilation failure in wine-1.1.44
Le 08/05/2010 22:37, Nikolay Sivov a écrit : On 5/9/2010 00:21, wy...@volny.cz wrote: Hi Marcus, * better backtraces for bug reports -O2 works like a charm there too, at least for me. I think i read that somewhere and if i understood that correctly, my conclusion at that time was, that -02 optimizes the code, so it can "omit some" part of code and replace them by faster alternative. But the debuging symbols then don't correspond such optimized code... And even if i usually don't understand those backtraces, i want to provide them as much readable for developer as possible. It's mostly about a parameters printed in backtraces, with -O2 you'll see sometimes missed register values replaced with for example. Don't know about inline things, probably it could be inlined anyway with -O0 too, but I'm not sure. this behavior is fixed with current git (except if gcc really optimizes things out, but wine now behaves as gcc, so you should be way less hindered by debugging with -O2 as you were) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Compilation failure in wine-1.1.44
On 5/9/2010 00:21, wy...@volny.cz wrote: Hi Marcus, * better backtraces for bug reports -O2 works like a charm there too, at least for me. I think i read that somewhere and if i understood that correctly, my conclusion at that time was, that -02 optimizes the code, so it can "omit some" part of code and replace them by faster alternative. But the debuging symbols then don't correspond such optimized code... And even if i usually don't understand those backtraces, i want to provide them as much readable for developer as possible. It's mostly about a parameters printed in backtraces, with -O2 you'll see sometimes missed register values replaced with for example. Don't know about inline things, probably it could be inlined anyway with -O0 too, but I'm not sure.
Re: Compilation failure in wine-1.1.44
Hi Marcus, > > * better backtraces for bug reports > > -O2 works like a charm there too, at least for me. I think i read that somewhere and if i understood that correctly, my conclusion at that time was, that -02 optimizes the code, so it can "omit some" part of code and replace them by faster alternative. But the debuging symbols then don't correspond such optimized code... And even if i usually don't understand those backtraces, i want to provide them as much readable for developer as possible. > * Not testing the code under Release conditions. I guess, that running Word2007 under linux/wine also does not meet release conditions by Microsoft ;-) Anyway, i hope that if i run Win program calculating PI on 4 decimal place, both -O0 and -02 will give me 3.1415 > * Slow code. This line caused all this replay :) Because it does not says "How much". So i did some benchmarking which maybe some others find useful. Compilation of 1.1.43 -O0: * real 1m 58sec Compilation of 1.1.43 -O2: * real 3m 29sec i.e. -02 is 77% slower. So 10 round of regression test (with in-between make distclean) is slower in case of -02 cca about 15m 10sec. That's a lot especially if i want to take bug testing seriously. Quake 3 1600x1200: -O0: 215.0 FPS -O2: 220.1 FPS (2% faster) Quake 3 640x480: -O0: 548.3 FPS -O2: 581.0 FPS (6% faster) As i'm not pro-gamer anymore and the -O2 results aren't convincing i'll stay at -O0. Of course everyone has different needs and can find -O2 useful. BTW: In case of game tests, i did at least five tests for each scenario.
Re: Compilation failure in wine-1.1.44
On Sat, May 08, 2010 at 03:02:48PM +0200, wy...@volny.cz wrote:
>
> > Roderick:
> > Yeah the -O0 bug was reported on #winehackers yesterday
> > and will likely be fixed soon.
>
> Ah, ok :) I know you already test nearly everythink, but what about adding
> another test -O{0,1,2,s,...}
> a] before official release or
> b] evening wine git update
>
> > Compiling using -O2 (which is what you should use by default anyway
> > > unless you have very good reasons not to) should work fine.
>
> I quickly thing of these reasons why -O0
> * better backtraces for bug reports
-O2 works like a charm there too, at least for me.
> * faster compilation during bisection
> * recommended for Valgrind
-O2 works like a charm there too.
> * my brain makes best optimalization, no need for buggy gcc :-D
Also:
* Not testing the code under Release conditions.
* Slow code.
Ciao, Marcus
Re: Compilation failure in wine-1.1.44
> Roderick:
> Yeah the -O0 bug was reported on #winehackers yesterday
> and will likely be fixed soon.
Ah, ok :) I know you already test nearly everythink, but what about adding
another test -O{0,1,2,s,...}
a] before official release or
b] evening wine git update
> Compiling using -O2 (which is what you should use by default anyway
> > unless you have very good reasons not to) should work fine.
I quickly thing of these reasons why -O0
* better backtraces for bug reports
* faster compilation during bisection
* recommended for Valgrind
* my brain makes best optimalization, no need for buggy gcc :-D
Re: Compilation failure in wine-1.1.44
Yeah the -O0 bug was reported on #winehackers yesterday and will
likely be fixed soon. Compiling using -O2 (which is what you should
use by default anyway unless you have very good reasons not to) should
work fine.
Roderick
On Sat, May 8, 2010 at 2:33 PM, wrote:
>
> Hi guys, i can't compile wine-1.1.44 (1.1.43 is OK here like all the
> ones before)... As i guess you would not release a wine, which can't
> be compiled, than i suspect there could be a trouble in my system (Debian
> Lenny 32bit). For this reason, i did not bother to fill a bug ;) as
> it would be marked invalid...
>
> Any suggestion? I wanted to give some bugs a retest, but i'm stuck ;)
>
> ...
> make[2]: Leaving directory `/home/pavel/install/wine/src/wine-1.1.44/tools'
>
> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
> -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
> -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g
> -O0 -o config.o ./config.c -DBINDIR='"/usr/local/bin"'
> -DDLLDIR='"/usr/local/lib/wine"'
> -DLIB_TO_BINDIR=\"`../../tools/relpath /usr/local/lib /usr/local/bin`\"
> -DLIB_TO_DLLDIR=\"`../../tools/relpath /usr/local/lib /usr/local/lib/wine`\"
> -DBIN_TO_DLLDIR=\"`../../tools/relpath /usr/local/bin /usr/local/lib/wine`\"
> -DBIN_TO_DATADIR=\"`../../tools/relpath /usr/local/bin
> /usr/local/share/wine`\"
>
> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
> -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
> -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g
> -O0 -o cptable.o cptable.c
>
> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
> -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
> -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g
> -O0 -o debug.o debug.c
>
> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
> -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
> -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g
> -O0 -o fold.o fold.c
>
> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
> -DWINE_UNICODE_API=""
> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
> -Wdeclaration-after-statement
> -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g
> -O0 -o ldt.o ldt.c
> {standard input}: Assembler messages:
> {standard input}:1472: Error: symbol `wine_get_fs' is already defined
> {standard input}:1502: Error: symbol `wine_set_fs' is already defined
> make[1]: *** [ldt.o] Error 1
> make[1]: Leaving directory
> `/home/pavel/install/wine/src/wine-1.1.44/libs/wine'
> make: *** [libs/wine] Error 2
>
>
>
>
>
