Re: c/10339

Re: c/10339

[Eric Botcazou]

The following reply was made to PR optimization/10339; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/10339
Date: Tue, 8 Apr 2003 08:40:04 +0200

 > The x86 backend doesn't seem to use memcmp in this case (maybe it does for
 > different values of string lengths, etc, but I haven't checked that).
 
 Actually, it does the transformation strncmp->memcmp but the builtin memcmp 
 has the nice property to stop on the first NULL character ("repz cmpsb").
 
 Anyway, this is not a Sparc-specific problem.
 
 -- 
 Eric Botcazou

Re: c/10339

[Wolfgang Bangerth]

The following reply was made to PR optimization/10339; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/10339
Date: Mon, 7 Apr 2003 15:28:37 -0500 (CDT)

 > > PS: Again, my interest is just to know whether this is a regression also
 > > on 3.3 and mainline, but if you should want to fix it then...
 > 
 > Does the same problem (if there is a problem) not happen on x86 too?
 
 The x86 backend doesn't seem to use memcmp in this case (maybe it does for 
 different values of string lengths, etc, but I haven't checked that).
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/
 
 

Re: c/10339

[Eric Botcazou]

The following reply was made to PR optimization/10339; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Wolfgang Bangerth <bangerth@ices.utexas.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/10339
Date: Mon, 7 Apr 2003 21:17:51 +0200

 > You can see the problem by looking at the assembler output when using -O:
 > it calls memcmp with an argument 4 in %o2 (the "mov 4, %o2" happens _after_
 > the call, but I think the instruction after the call is something like a
 > delay slot, so %o2 will be set at the time we get into memcmp).
 
 Yep, the insn has been put in a delay slot.
 
 > PS: Again, my interest is just to know whether this is a regression also
 > on 3.3 and mainline, but if you should want to fix it then...
 
 Does the same problem (if there is a problem) not happen on x86 too?
 
 -- 
 Eric Botcazou

c/10339

[Wolfgang Bangerth]

The following reply was made to PR optimization/10339; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: ebotcazou@libertysurf.fr
Cc: gcc-gnats@gcc.gnu.org
Subject: c/10339
Date: Mon, 7 Apr 2003 13:52:25 -0500 (CDT)

 Hi Eric,
 as resident sparc optimization expert: would you mind taking a look at 
 10339, which is kind of a miscompilation on sparc? It would be nice if you 
 could confirm/reject whether this is a regression also in 3.3 and 
 mainline, since I don't have these branches on our sparc boxes. You can 
 see the problem by looking at the assembler output when using -O: it calls 
 memcmp with an argument 4 in %o2 (the "mov 4, %o2" happens _after_ the 
 call, but I think the instruction after the call is something like a delay 
 slot, so %o2 will be set at the time we get into memcmp).
 
 What exactly goes wrong should be understandable from the audit trail.
 
 Thanks
   Wolfgang
 
 PS: Again, my interest is just to know whether this is a regression also 
 on 3.3 and mainline, but if you should want to fix it then...
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                                www: http://www.ices.utexas.edu/~bangerth/