From: Christoph <chr_news@...>
Date: 2002-09-04T03:51:20+09:00
Subject: RE: Mswin32 build flags



> -----Original Message-----
> From: U.Nakamura [mailto:usa@osb.att.ne.jp]
> Sent: Friday, August 16, 2002 9:13 AM
> To: ruby-core@ruby-lang.org
> Subject: Re: Mswin32 build flags
> 
> Hello,
> 
> In message "Mswin32 build flags"
>     on Aug.16,2002 15:52:41, <chr_news@gmx.net> wrote:
> | Unfortunately these builds also miserably fail the basic
> | ``nmake test'', however by only turning off the /Og
> | flag turning the compilation of the file ``sprint.c''
> | one seems to get an executable which seem to enjoy
> | the speed gain of a full /Og optimization which
> | passes the basic  "nmake test" (true at least for
> | VC 7) - so I am wondering if there are known issues
> | against such a compilation strategy?
> 
> Because there are more problems with /Og flag
> (GC, Regexp, etc).
> So, I cannot say that /Og is reliable.

Thanks  (and sorry for the late reply) 


I played around with this yesterday and essentially found 
four methods which not should be compiled with the /Og flag 
(turned on/off with the optimize pragma)


rb_big2dbl(x) ( bignum.c  811 )
rb_f_sprintf  ( sprintf.c 105 )
rb_obj_as_string(obj) ( string.c  280)
pack_pack     ( pack.c 332 ) 

Compiled like this ruby (1.7.3 (2002-08-29) [i386-mswin32])
fails no additional rubicon test, in fact it passes one 
additional, hence all, thread tests (on my machine at least).
An additional advantage is that the notoriously low recursion
limit (on mswin32) is also improved by a factor of two.  

It is really a pity that the /Og flag is not totally reliable,
but why not make it a configure option or at least mention it 
the ``README''  + put on/off optimize macros around known ``iffy''
methods? The speed increase is sooo substantial that it should not
be ignored imho - (I'm particularly thinking about Andy's binary 
distribution here).

   

/Christoph