This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: slow V3 configures (was Re: ICE during bootstrap.)
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: slow V3 configures (was Re: ICE during bootstrap.)
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Tue, 5 Dec 2000 15:44:06 -0500
- Cc: Robert Lipe <robertlipe at usa dot net>, Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>, gcc at gcc dot gnu dot org, libstdc++ at sources dot redhat dot com
- References: <20001205143319.A6206@disaster.jaj.com> <Pine.SOL.3.91.1001205114206.7926B-100000@taarna.cygnus.com>
On Tue, Dec 05, 2000 at 11:53:57AM -0800, Benjamin Kosnik wrote:
>
> Following phil's advice and changing to
>
> test-for-cached-answer-oh-it's-there-never-mind
> else
> push-current-language-on-stack
> set-current-language-to-C++
> test and cache
> pop-language-from-stack
> end
>
> seems like the best approach.
The odd thing is... this is what should be happening now. All the
push-set-test-cache-pop stuff is done inside the list of commands "to be
run if the value isn't cached". We still get serious pauses.
Anyhow, I patched all the math tests to explictly do the same test that
AC_CACHE_VAL does before calling AC_CACHE_VAL itself. The speedup is
/considerable/. The config.cache and bits/c++config.h results are identical.
One downside: it's AC_CACHE_VAL that does the printing of "(cached)".
My change means that a cached value still shows on the screen as
checking for _expf declaration... no
checking for _fabsf declaration... no
checking for _floorf declaration... no
checking for _fmodf declaration... no
checking for _frexpf declaration... no
checking for _ldexpf declaration... no
etc, like regular tests. Just a /lot/ faster. :-) This may not be
acceptable; what do y'all think? I'm hesitant to try and use the $ac_*
variables controlling echo(1)'s no-newline behavior, for some reason.
Phil
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.