On Wed, 4 Jan 2006, jerry gay via RT wrote:
> On 1/4/06, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > On Wed, 4 Jan 2006, Joshua Hoblitt via RT wrote:
> > > I'm wondering if it's worth disabling optimizations for
> > > those compilation units if nobody noticed a problem in the period
> > > between the tree reorganization and the breakage of --optimize.
> >
> > It's very hard to portably test for this sort of thing. Even in perl5's
> > Configure, I eventually gave up on it, and just made sure it was well
> > documented in the INSTALL file what to do. (The usual culprit there is
> > toke.c.)
> >
> > As to how widespread a problem this could be, I really don't know. It's
> > possible nobody noticed a problem because nobody tested it on anything
> > other than gcc.
> src/ops/core_ops_switch.c compiles on win32, and i have to say, i
> didn't notice it taking any more time. so, i'd like to have
> optimizations enabled for this file. since CFLAGS is a generated file,
> we can use #conditioned_line to specify when it should or should not
> be enabled.
And, just to be clear, that's building with
Configure.pl --optimize=???
(that is, exactly what optimization flags did you use?)
> i'd like reports from a third compiler/arch to know how it should
> behave... enabled by default, or disabled. so far, we have:
> gcc - disabled
I don't know about gcc. I haven't tested it.
> cl - enabled
> others - ???
The combination that failed for me is Sun/SPARC Workshop cc with
optimize=-fast. It may be that other less-aggressive optimizations are
fine; I haven't done a systematic search.
--
Andy Dougherty [EMAIL PROTECTED]
