This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: slow V3 configures (was Re: ICE during bootstrap.)

Phil Edwards <> writes:
> 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.

Well, not exactly.  What's happening is

  if have cached_answer; then :;
    execute test to check for declaration and update cached_answer
  if test $cached_answer = yes; then

AC_CHECK_FUNCS uses a for loop, which executes even if the cached
answer is returned.  That's probably where all that time is lost.

One option is to use AC_CHECK_FUNC, but you lose the automatic
definition of HAVE_FOO and corressponding updates of
Another is to have parallel tests. 

  # check these unconditionally
  AC_CHECK_FUNCS(sinf isnanf hypotf ...)

This may increase the 'configure' time somewhat for the first time,
but is likely to zoom through on re-runs.
> 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

Looks like you are skipping the 

  if test x$glibcpp_cv_func_$1_use = x"yes"; then

part, so it's probably not a valid comparison :-)

- Hari
Raja R Harinath ------------------------------
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]