This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR3609
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: PR3609
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Fri, 10 Aug 2001 11:43:46 +0200
- Cc: Mark Mitchell <mark at codesourcery dot com>,Geoff Keating <geoffk at geoffk dot org>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- References: <20580000.997407843@warlock.codesourcery.com><jmr8uku24p.fsf@geoffk.org><20580000.997407843@warlock.codesourcery.com>
At 11:01 10.08.2001, Jakub Jelinek wrote:
>On Thu, Aug 09, 2001 at 06:44:03PM -0700, Mark Mitchell wrote:
> > But, since my original take was that this code was bogus, and since
> > most people seem to feel that this code really is invalid,
> > and even though nobody has yet seen fit to comment about whether or not
> > this optimization actually *matters*, or whether the conditional
> > version I proposed would get enough of the win if it does matter, I
> > guess we can just leave it in. I never write code like that...
> >
> > Franz, you're on your own; I'm going to close PR3609 as not-a-bug.
>
>Also note that the c_strlen code in question has been there at least in
>2.95.x too, perhaps even earlier.
But c_strlen is called here as a subroutine of the builtin_strcpy
optimization (and this one wasn't there in 2.95). I think you are
concentrating to much on the strlen example, the important thing here is
the use in the strcpy optimization. After all strcpy is fully prototyped
and it takes only pointers, how can I expect the compiler to use strlen on
one of them? That's why I suggested to enable this optimization depending
on who is the caller by passing a flag in. The compiler using strlen on an
object that can't be proven to be constant is highly surprising IMHO.
Franz.