[perl #38141] [PATCH] CFLAGS missed two files in src/ reorganization
Andy Dougherty
# Please include the string: [perl #38141]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38141 >
This patch fixes a couple of simple oversights falling out of the src/
reorganization.
--- parrot-current/config/gen/makefiles/CFLAGS.in 2005-12-12 19:15:10.000000000 -0500
+++ parrot-andy/config/gen/makefiles/CFLAGS.in 2006-01-03 14:07:18.169998000 -0500
@@ -8,8 +8,8 @@
src/platform.c -{-Wcast-qual} # noisy
src/spf_render.c -{-Wformat-nonliteral} # noisy
src/tsq.c -{${optimize}} # never optimize tsq.c!
-ops/core_ops_cg.c -{${optimize}} # takes too long
-ops/core_ops_switch.c -{${optimize}} # Overwhelms some compilers.
+src/ops/core_ops_cg.c -{${optimize}} # takes too long
+src/ops/core_ops_switch.c -{${optimize}} # Overwhelms some compilers.
src/py_func.c +{-Iclasses} # include pmc_default.h
# io should be -Wunsed clean
--
Andy Dougherty doug...@lafayette.edu
Jerry Gay via RT
~jerry
Joshua Hoblitt
Were you caught by either "takes too long" or "Overwhelms some
compilers."? 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.
Cheers,
-J
--
Jerry Gay
> 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.
>
> 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.
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
cl - enabled
others - ???
any other reports would be appreciated.
~jerry
Andy Dougherty
> Andy,
>
> Were you caught by either "takes too long" or "Overwhelms some
> compilers."?
Well, it hadn't quite overwhelmed the compiler yet -- it was swapping like
mad for at least 20 minutes and still growing, and several other processes
(including spamassassin, alas) had died due to out-of-memory-errors, but
the compiler hadn't quite given up yet. I suspect it would have, had I
let it continue.
> 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.
--
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
> On 1/4/06, Andy Dougherty <doug...@lafayette.edu> wrote:
> 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 doug...@lafayette.edu
Jerry Gay
> And, just to be clear, that's building with
> Configure.pl --optimize=???
> (that is, exactly what optimization flags did you use?)
>
(which means i used perl's optimize flags: -MD -Zi -DNDEBUG -O1)
~jerry
Leopold Toetsch
> 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
It's not that easy and depends on a lot of factors (available mem is a
major issue). Then there are some brpken gcc versions around. Anyway,
all compiles fine optimized here with gcc 3.3.5 20050117 (prerelease)
(SUSE Linux).
Maybe some --disable-optimize=pattern config switch is in order, also
settable by config hints.
> ~jerry
leo