Date: Sat, 11 Jan 2003 17:52:30 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Leonid Pauzner" <uue AT pauzner DOT dnttm DOT ru>
Message-Id: <2561-Sat11Jan2003175230+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: gcc AT gcc DOT gnu DOT org, djgpp-workers AT delorie DOT com
In-reply-to: <2.7.9.181SX.H8JVM1@pauzner.dnttm.ru> (uue@pauzner.dnttm.ru)
Subject: Re: gcc 3.2.1 optimizer degradation (strlen, -O2)
References:  <2 DOT 7 DOT 9 DOT 181SX DOT H8JVM1 AT pauzner DOT dnttm DOT ru>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Leonid Pauzner" <uue AT pauzner DOT dnttm DOT ru>
> Date: Sat, 11 Jan 2003 15:49:13 +0300 (MSK)
> 
> It turns out that the libc strlen() function (compiled with -O2)
> became nearly 2 times slower when I switched from gcc 2.95.3 to gcc 3.2.1
> on a Pentium machine.

Are you sure you get the library strlen?  IIRC, GCC provides its own
inline versions of some functions, and I think strlen is one of them.

Examining the code (use the -S switch to GCC to produce it) should
show you whether my guess was true.

You could use the -fno-builtin switch to force GCC to call the
(non-inline) library version of strlen.