This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Builtin strcpy/strncpy/memcpy/strcmp/fputs fixes and optimizations
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: [PATCH] Builtin strcpy/strncpy/memcpy/strcmp/fputs fixes and optimizations
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 30 Nov 2000 09:30:45 -0500
- Cc: rth at redhat dot com, gcc-patches at gcc dot gnu dot org
- References: <200011301359.IAA05991@caip.rutgers.edu>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Thu, Nov 30, 2000 at 08:59:35AM -0500, Kaveh R. Ghazi wrote:
> > From: Jakub Jelinek <jakub@redhat.com>
> >
> > fputs ("foobar" + (i++ & 3), f) and miscompile
> >
> > To sum up, c_getstr guarantees the argument is constant string with constant
> > length without side effects if returning non-NULL, while c_strlen does not
> > (I think it just guarantees that if it returns an INTEGER_CST that it does
> > not have side effects).
>
> I want to make sure I understand this. The c_strlen() function won't
> return an INTEGER_CST for the fputs() case above but *will* return a
> non-NULL tree expr which corresponds to "6 - (i++ & 3)", right?
Exactly.
> That's why you have to check whether its an INTEGER_CST or prefer
> c_getstr?
c_getstr will return NULL in that case, because the string is not computable
at compile time.
Jakub