This is the mail archive of the
mailing list for the GCC project.
Re: Results for 3.2.1 20020816 (prerelease) testsuite on i686-pc-linux-gnu
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Greg Schafer <gschafer at zip dot com dot au>
- Cc: gcc at gcc dot gnu dot org, law at redhat dot com
- Date: Sun, 18 Aug 2002 00:09:21 -0700
- Subject: Re: Results for 3.2.1 20020816 (prerelease) testsuite on i686-pc-linux-gnu
- References: <20020818093401.A15946@tigers-lfs.nsw.bigpond.net.au> <20020817184800.A2198@lucon.org> <20020818152009.A29717@tigers-lfs.nsw.bigpond.net.au>
On Sun, Aug 18, 2002 at 03:20:09PM +1000, Greg Schafer wrote:
> On Sat, Aug 17, 2002 at 06:48:00PM -0700, H. J. Lu wrote:
> > On Sun, Aug 18, 2002 at 09:34:01AM +1000, Greg Schafer wrote:
> > > Hello there
> > >
> > > I notice that your gcc test results do not fail the test
> > > gcc.c-torture/execute/20020307-2.c
> > > but just about everyone else in the world on i686-pc-linux-gnu
> > > seems to fail that test.
> > >
> > > Do you know the reason for this? Do you use a local patch or something?
> > >
> > http://gcc.gnu.org/ml/gcc-patches/2002-07/msg01561.html
> Ahhh, thanks. Not only did it fix that test but it also made
> "gcc.dg/sequence-pt-1.c" pass for me which was failing otherwise.
> Unfortunately, It doesn't fix the testcase in Gnats PR 7591 which you
> pointed out seems to be caused by -maccumulate-outgoing-args in
> combination with -mcpu=i686
I think it is unrelated. Jeff, I think your patch
may be the cause for that bug. The problem is you mark the stack
slots being used before they are used by the memcpy libcall:
1. expand_call calls store_one_arg.
2. store_one_arg marks the stack slots used by arg are being used.
3. store_one_arg calls emit_push_insn to push arg.
4. emit_push_insn calls emit_library_call to copy arg onto stack.
5. emit_library_call calls emit_library_call_value_1 to emit memcpy.
6. emit_library_call_value_1 finds the stack slots it is supposed
to fill are used.
7. emit_library_call_value_1 does save/restore around memcpy.
It doesn't work on x86.
> One last thing, if your patch is a correct fix, would it make sense
> to do a similar thing in expr.c which has the same hunk of code you
> wrapped in a #ifndef in calls.c ?
I think so.