public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: ghazi@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: middle-end/10472: [3.4 regression] ICE in instantiate_virtual_regs_lossage
Date: Fri, 02 May 2003 00:16:00 -0000	[thread overview]
Message-ID: <20030502001600.14865.qmail@sources.redhat.com> (raw)

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:


             reply	other threads:[~2003-05-02  0:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-02  0:16 Kaveh R. Ghazi [this message]
  -- 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030502001600.14865.qmail@sources.redhat.com \
    --to=ghazi@caip.rutgers.edu \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=ghazi@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).