* 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).