public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
@ 2003-05-02 0:16 Kaveh R. Ghazi
0 siblings, 0 replies; 6+ messages in thread
From: Kaveh R. Ghazi @ 2003-05-02 0:16 UTC (permalink / raw)
To: ghazi; +Cc: gcc-prs
The following reply was made to PR middle-end/10472; it has been noted by GNATS.
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
gcc-prs@gcc.gnu.org, ghazi@gcc.gnu.org, giovannibajo@libero.it,
nobody@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org
Subject: Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
Date: Thu, 1 May 2003 20:08:05 -0400 (EDT)
(Disclaimer: my remote x86 box is down today, everything done with
cross-compilers on sparc.)
I took a look at PR10472.
First I tried to determine under what circumstances and platforms the
bug appears. While the PR was opened against cygwin, it seems it
should occur on any x86 target. I'm guessing the reason we probably
haven't seen breakage on e.g. x86-linux-gnu (and why I'm not being
chased with torches and pitchforks) is that those targets use the
system gettext and don't compile the intl directory where the
triggering code lies.
But one should be able to trigger a bootstrap failure on linux-gnu if
configured using --with-included-gettext.
Second, I tried to see if I could reproduce it anywhere else.
I.e. what was unique about x86? The cmpstr pattern could be playing a
part, so I built cross-compilers to s390-linux-gnu and i370-linux-gnu
(both of which have cmpstr) but they compile the testcase fine.
BTW, IMHO the reduced testcase in the PR is slightly misleading. It
lead me at least to believe the bug had something to do with null
pointers. A better snippet is something like this:
> extern void f (char *);
> void foo (char *s)
> {
> f (__builtin_stpcpy (s, "hi"));
> }
I.e. the problem only seems to occur when stpcpy or mempcpy are
themselves passed as a function call parameter. The function called
does not have to be another builtin, it can be a regular call as shown
above. When you call the stpcpy/mempcpy builtins in other contexts,
(standalone, in assignments, or in `if' statements) they work fine on
x86.
Both the testcase in the PR, and my reduced testcase above, pass
compilation on sparc, i370 and s390. But we get a crash in cc1 on
x86. I tried, but the root cause is beyond my abililty to figure out.
But I suspect something in the x86 backend.
Would someone please assist me in debugging this?
In the mean time, we can disable the optmization on x86 so that cygwin
people can resume bootstrap. (Yes this is lame, sorry I'm not able to
provide a proper fix.) We'll get testsuite failures in
execute/string-opt-18.c on x86 until this can be looked at by someone
more knowledgable that me.
Patch tested by building a cross-compiler to i686-pc-linux-gnu and
compiling the testcase in the PR as well as mine above.
Ok for mainline?
Thanks,
--Kaveh
2003-05-01 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* builtins.c (expand_builtin_stpcpy): Disable on x86.
(BUILT_IN_MEMPCPY): Likewise.
--- orig/egcc-CVS20030430/gcc/builtins.c 2003-04-28 10:00:20.000000000 -0400
+++ egcc-CVS20030430/gcc/builtins.c 2003-05-01 19:47:53.414417864 -0400
@@ -2487,6 +2487,9 @@ expand_builtin_stpcpy (arglist, target,
rtx target;
enum machine_mode mode;
{
+#ifdef TARGET_386 /* There are problems on x86, see PR 10472. */
+ return 0;
+#else
if (!validate_arglist (arglist, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
return 0;
else
@@ -2499,6 +2502,7 @@ expand_builtin_stpcpy (arglist, target,
chainon (arglist, build_tree_list (NULL_TREE, len));
return expand_builtin_memcpy (arglist, target, mode, /*endp=*/2);
}
+#endif
}
/* Callback routine for store_by_pieces. Read GET_MODE_BITSIZE (MODE)
@@ -4621,9 +4625,11 @@ expand_builtin (exp, target, subtarget,
break;
case BUILT_IN_MEMPCPY:
+#ifndef TARGET_386 /* There are problems on x86, see PR 10472. */
target = expand_builtin_memcpy (arglist, target, mode, /*endp=*/1);
if (target)
return target;
+#endif
break;
case BUILT_IN_MEMMOVE:
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
@ 2003-05-02 0:36 Wolfgang Bangerth
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Bangerth @ 2003-05-02 0:36 UTC (permalink / raw)
To: ghazi; +Cc: gcc-prs
The following reply was made to PR middle-end/10472; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ices.utexas.edu>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>, <ghazi@gcc.gnu.org>,
Giovanni Bajo <giovannibajo@libero.it>, <gcc-patches@gcc.gnu.org>
Subject: Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
Date: Thu, 1 May 2003 19:32:14 -0500 (CDT)
> First I tried to determine under what circumstances and platforms the
> bug appears. While the PR was opened against cygwin, it seems it
> should occur on any x86 target.
I'm sorry, I should have made that clearer: the reduced testcase ICEs on
my plain vanilla x86-linux-gnu box with SuSE 8.0.
> (and why I'm not being chased with torches and pitchforks)
We write hate-mails these days -- mental torture is just as effective :-)
> BTW, IMHO the reduced testcase in the PR is slightly misleading. It
> lead me at least to believe the bug had something to do with null
> pointers.
Again my fault.
> In the mean time, we can disable the optmization on x86 so that cygwin
> people can resume bootstrap. (Yes this is lame, sorry I'm not able to
> provide a proper fix.)
Alternatively, one could work around the bootstrap failure with something
like the following instead of your small testcase (I'm surprised this
works):
void foo (char *s)
{
char * tmp = __builtin_stpcpy (s, "hi");
f (tmp);
}
That's just as lame, and fragile on top of that, but we don't have to wield
the sledgehammer to stomp this bug, it would be simpler to add a testcase
and we don't have to remember to re-enable the optimization once someone
gets around to fixing the underlying problem. There can't be that many
places in gcc where such a fix would be necessary, and Giovanni would
surely be willing to find them on his box, right? :-)
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
@ 2003-05-01 4:56 Kaveh R. Ghazi
0 siblings, 0 replies; 6+ messages in thread
From: Kaveh R. Ghazi @ 2003-05-01 4:56 UTC (permalink / raw)
To: ghazi; +Cc: gcc-prs
The following reply was made to PR middle-end/10472; it has been noted by GNATS.
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
gcc-prs@gcc.gnu.org, ghazi@gcc.gnu.org, giovannibajo@libero.it,
nobody@gcc.gnu.org
Cc:
Subject: Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
Date: Thu, 1 May 2003 00:47:06 -0400 (EDT)
> From: bangerth@dealii.org
>
> Synopsis: [3.4 regression] ICE in instantiate_virtual_regs_lossage
>
> Kaveh, would you mind taking a look? It might be due to a
> patch of yours, and it breaks bootstrap on some platforms.
Ok, I'll take a look tomorrow.
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
@ 2003-04-30 21:55 bangerth
0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2003-04-30 21:55 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, ghazi, giovannibajo, nobody
Synopsis: [3.4 regression] ICE in instantiate_virtual_regs_lossage
Responsible-Changed-From-To: unassigned->ghazi
Responsible-Changed-By: bangerth
Responsible-Changed-When: Wed Apr 30 21:55:46 2003
Responsible-Changed-Why:
Kaveh, would you mind taking a look? It might be due to a
patch of yours, and it breaks bootstrap on some platforms.
Thanks
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10472
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
@ 2003-04-30 21:46 Janis Johnson
0 siblings, 0 replies; 6+ messages in thread
From: Janis Johnson @ 2003-04-30 21:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR middle-end/10472; it has been noted by GNATS.
From: Janis Johnson <janis187@us.ibm.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
gcc-prs@gcc.gnu.org, giovannibajo@libero.it, ghazi@caip.rutgers.edu
Cc:
Subject: Re: middle-end/10472: [3.4 regression] ICE in
instantiate_virtual_regs_lossage
Date: Wed, 30 Apr 2003 14:35:59 -0700
A hunt on i686-pc-linux-gnu using the minimized test case
identifies this patch as being responsible for the problem:
> 2003-04-13 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
>
> * builtins.c (expand_builtin_memcpy): Add `endp' argument, use
it.
> (expand_builtin_stpcpy): New.
> (expand_builtin): Add BUILT_IN_MEMPCPY & BUILT_IN_STPCPY.
> * builtins.def: Add mempcpy & stpcpy support.
> * doc/extend.texi (mempcpy, stpcpy): Document new builtins.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10472
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
@ 2003-04-29 1:02 bangerth
0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2003-04-29 1:02 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, giovannibajo, nobody
Old Synopsis: [3.4] [cygwin] mainline broken again since 20030413
New Synopsis: [3.4 regression] ICE in instantiate_virtual_regs_lossage
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Tue Apr 29 01:02:12 2003
State-Changed-Why:
Confirmed, with the small testcase I just sent. Breaks bootstrap
on cygwin, so should be fixed soon if possible!
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10472
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-02 0:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-02 0:16 middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage Kaveh R. Ghazi
-- strict thread matches above, loose matches on Subject: below --
2003-05-02 0:36 Wolfgang Bangerth
2003-05-01 4:56 Kaveh R. Ghazi
2003-04-30 21:55 bangerth
2003-04-30 21:46 Janis Johnson
2003-04-29 1:02 bangerth
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).