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

> 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.

- Raw text -