public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Results for 3.2.1 20020816 (prerelease) testsuite on i686-pc-linux-gnu
       [not found]   ` <20020818152009.A29717@tigers-lfs.nsw.bigpond.net.au>
@ 2002-08-18  0:09     ` H. J. Lu
  2002-08-18  8:06       ` optimization/7591: function-related struct copy bug H. J. Lu
  0 siblings, 1 reply; 7+ messages in thread
From: H. J. Lu @ 2002-08-18  0:09 UTC (permalink / raw)
  To: Greg Schafer; +Cc: gcc, law

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

http://gcc.gnu.org/ml/gcc-patches/1999-02n/msg00379.html

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.


H.J.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: optimization/7591: function-related struct copy bug
  2002-08-18  0:09     ` Results for 3.2.1 20020816 (prerelease) testsuite on i686-pc-linux-gnu H. J. Lu
@ 2002-08-18  8:06       ` H. J. Lu
  2002-08-18  8:14         ` H. J. Lu
  0 siblings, 1 reply; 7+ messages in thread
From: H. J. Lu @ 2002-08-18  8:06 UTC (permalink / raw)
  To: Greg Schafer, kelledin; +Cc: gcc, law, gcc-patches, gcc-bugs

On Sun, Aug 18, 2002 at 12:09:21AM -0700, H. J. Lu wrote:
> 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
> 
> http://gcc.gnu.org/ml/gcc-patches/1999-02n/msg00379.html
> 
> 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.
> 

I am testing this patch now. I partially reverted Jeff's patch and
move setting stack_usage_map just before expand_expr, which is needed
according to Jeff's orignal message.


H.J.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: optimization/7591: function-related struct copy bug
  2002-08-18  8:06       ` optimization/7591: function-related struct copy bug H. J. Lu
@ 2002-08-18  8:14         ` H. J. Lu
  2002-08-18  8:36           ` H. J. Lu
  0 siblings, 1 reply; 7+ messages in thread
From: H. J. Lu @ 2002-08-18  8:14 UTC (permalink / raw)
  To: Greg Schafer, kelledin; +Cc: gcc, law, gcc-patches, gcc-bugs

On Sun, Aug 18, 2002 at 08:06:17AM -0700, H. J. Lu wrote:
> On Sun, Aug 18, 2002 at 12:09:21AM -0700, H. J. Lu wrote:
> > 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
> > 
> > http://gcc.gnu.org/ml/gcc-patches/1999-02n/msg00379.html
> > 
> > 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.
> > 
> 
> I am testing this patch now. I partially reverted Jeff's patch and
> move setting stack_usage_map just before expand_expr, which is needed
> according to Jeff's orignal message.
> 

Never mind. It doesn't work. I guess we need to find a way only to do
it when it is necessary, like for mn102/mn103.


H.J.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: optimization/7591: function-related struct copy bug
  2002-08-18  8:14         ` H. J. Lu
@ 2002-08-18  8:36           ` H. J. Lu
  2002-08-18 13:28             ` H. J. Lu
  2002-08-19  2:50             ` Greg Schafer
  0 siblings, 2 replies; 7+ messages in thread
From: H. J. Lu @ 2002-08-18  8:36 UTC (permalink / raw)
  To: Greg Schafer, kelledin; +Cc: gcc, law, gcc-patches, gcc-bugs

On Sun, Aug 18, 2002 at 08:14:43AM -0700, H. J. Lu wrote:
> On Sun, Aug 18, 2002 at 08:06:17AM -0700, H. J. Lu wrote:
> > On Sun, Aug 18, 2002 at 12:09:21AM -0700, H. J. Lu wrote:
> > > 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
> > > 
> > > http://gcc.gnu.org/ml/gcc-patches/1999-02n/msg00379.html
> > > 
> > > 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.
> > > 
> > 
> > I am testing this patch now. I partially reverted Jeff's patch and
> > move setting stack_usage_map just before expand_expr, which is needed
> > according to Jeff's orignal message.
> > 
> 
> Never mind. It doesn't work. I guess we need to find a way only to do
> it when it is necessary, like for mn102/mn103.
> 

I am testing this now.


H.J.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: optimization/7591: function-related struct copy bug
  2002-08-18  8:36           ` H. J. Lu
@ 2002-08-18 13:28             ` H. J. Lu
  2002-08-19  2:50             ` Greg Schafer
  1 sibling, 0 replies; 7+ messages in thread
From: H. J. Lu @ 2002-08-18 13:28 UTC (permalink / raw)
  To: Greg Schafer, kelledin; +Cc: gcc, law, gcc-patches, gcc-bugs

On Sun, Aug 18, 2002 at 08:36:04AM -0700, H. J. Lu wrote:
> On Sun, Aug 18, 2002 at 08:14:43AM -0700, H. J. Lu wrote:
> > On Sun, Aug 18, 2002 at 08:06:17AM -0700, H. J. Lu wrote:
> > > On Sun, Aug 18, 2002 at 12:09:21AM -0700, H. J. Lu wrote:
> > > > 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
> > > > 
> > > > http://gcc.gnu.org/ml/gcc-patches/1999-02n/msg00379.html
> > > > 
> > > > 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.
> > > > 
> > > 
> > > I am testing this patch now. I partially reverted Jeff's patch and
> > > move setting stack_usage_map just before expand_expr, which is needed
> > > according to Jeff's orignal message.
> > > 
> > 
> > Never mind. It doesn't work. I guess we need to find a way only to do
> > it when it is necessary, like for mn102/mn103.
> > 
> 
> I am testing this now.
> 

Here is the test results:

http://gcc.gnu.org/ml/gcc-testresults/2002-08/msg00587.html

No regressions.

H.J.
> 2002-08-18  H.J. Lu <hjl@gnu.org>
> 
> 	* calls.c (store_one_arg): Remove ATTRIBUTE_UNUSED on
> 	variable_size. Mark any slots used for the argument as in-use
> 	only if we can't pass all arguments to a library call in
> 	registers.
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: optimization/7591: function-related struct copy bug
  2002-08-18  8:36           ` H. J. Lu
  2002-08-18 13:28             ` H. J. Lu
@ 2002-08-19  2:50             ` Greg Schafer
  2002-08-19  7:09               ` H. J. Lu
  1 sibling, 1 reply; 7+ messages in thread
From: Greg Schafer @ 2002-08-19  2:50 UTC (permalink / raw)
  To: H. J. Lu; +Cc: kelledin, gcc, law, gcc-patches, gcc-bugs

On Sun, Aug 18, 2002 at 08:36:04AM -0700, H. J. Lu wrote:
> I am testing this now.
> 
> 
> H.J.

> 2002-08-18  H.J. Lu <hjl@gnu.org>
> 
> 	* calls.c (store_one_arg): Remove ATTRIBUTE_UNUSED on
> 	variable_size. Mark any slots used for the argument as in-use
> 	only if we can't pass all arguments to a library call in
> 	registers.
> 
> --- gcc/calls.c.copy	Sun Aug 18 07:35:11 2002
> +++ gcc/calls.c	Sun Aug 18 08:27:29 2002

Fabulous. This fixed it for me. And I didn't see any regressions on
i686-pc-linux-gnu (with the default arch in i386.c hacked to be i686)

Thanks
Greg

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: optimization/7591: function-related struct copy bug
  2002-08-19  2:50             ` Greg Schafer
@ 2002-08-19  7:09               ` H. J. Lu
  0 siblings, 0 replies; 7+ messages in thread
From: H. J. Lu @ 2002-08-19  7:09 UTC (permalink / raw)
  To: Greg Schafer; +Cc: kelledin, gcc, law, gcc-patches, gcc-bugs

On Mon, Aug 19, 2002 at 07:50:02PM +1000, Greg Schafer wrote:
> On Sun, Aug 18, 2002 at 08:36:04AM -0700, H. J. Lu wrote:
> > I am testing this now.
> > 
> > 
> > H.J.
> 
> > 2002-08-18  H.J. Lu <hjl@gnu.org>
> > 
> > 	* calls.c (store_one_arg): Remove ATTRIBUTE_UNUSED on
> > 	variable_size. Mark any slots used for the argument as in-use
> > 	only if we can't pass all arguments to a library call in
> > 	registers.
> > 
> > --- gcc/calls.c.copy	Sun Aug 18 07:35:11 2002
> > +++ gcc/calls.c	Sun Aug 18 08:27:29 2002
> 
> Fabulous. This fixed it for me. And I didn't see any regressions on
> i686-pc-linux-gnu (with the default arch in i386.c hacked to be i686)
> 

Now, let's wait for someone to review it :-(.


H.J.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2002-08-19  7:09 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20020818093401.A15946@tigers-lfs.nsw.bigpond.net.au>
     [not found] ` <20020817184800.A2198@lucon.org>
     [not found]   ` <20020818152009.A29717@tigers-lfs.nsw.bigpond.net.au>
2002-08-18  0:09     ` Results for 3.2.1 20020816 (prerelease) testsuite on i686-pc-linux-gnu H. J. Lu
2002-08-18  8:06       ` optimization/7591: function-related struct copy bug H. J. Lu
2002-08-18  8:14         ` H. J. Lu
2002-08-18  8:36           ` H. J. Lu
2002-08-18 13:28             ` H. J. Lu
2002-08-19  2:50             ` Greg Schafer
2002-08-19  7:09               ` H. J. Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).