public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Paul Edwards" <mutazilah@gmail.com>
To: "Richard Guenther" <richard.guenther@gmail.com>
Cc: <gcc@gcc.gnu.org>
Subject: Re: i370 port - music/sp - possible generic gcc problem
Date: Sun, 29 Nov 2009 07:57:00 -0000	[thread overview]
Message-ID: <07600C4C9EAE47ADB6B1F8C655EDE27E@Paullaptop> (raw)

> <stdin>: In function `acos':
> <stdin>:137: Internal compiler error in ?, at <stdin>:724
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> I might be able to trace it from a different approach, getting more
> information about that internal error, now that I know where some
> of the involved memory is.  I'll get that <stdin> converted into a
> PC filename first.

6 hours of compilation later, I was unsuccessful in getting the proper
filename displayed.  As far as I can tell, it's aborting but not displaying
any output.  ie randomly displaying the above message.

However, not to worry, since there's only one line 724 with an
abort() in it, and it's this bit of code:

static int
insert_save (chain, before_p, regno, to_save, save_mode)
     struct insn_chain *chain;
     int before_p;
     int regno;
     HARD_REG_SET *to_save;
     enum machine_mode *save_mode;
{
  int i;
  unsigned int k;
  rtx pat = NULL_RTX;
  int code;
  unsigned int numregs = 0;
  struct insn_chain *new;
  rtx mem;

  /* A common failure mode if register status is not correct in the RTL
     is for this routine to be called with a REGNO we didn't expect to
     save.  That will cause us to write an insn with a (nil) SET_DEST
     or SET_SRC.  Instead of doing so and causing a crash later, check
     for this common case and abort here instead.  This will remove one
     step in debugging such problems.  */

  if (regno_save_mem[regno][1] == 0)
    abort ();


which is in the same file as the init_caller_save() function that
allocated the memory in the first place.

One fortunate thing is that this source file is under 1000 lines
long so hopefully amenable to debugging.

BFN.  Paul.

             reply	other threads:[~2009-11-29  7:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-29  7:57 Paul Edwards [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-11-29 14:31 Paul Edwards
2009-11-24 14:05 i370 port - 3.4.6 to 4.4 upgrade attempt Ulrich Weigand
2009-11-28 15:14 ` i370 port - music/sp - possible generic gcc problem Paul Edwards
2009-11-28 16:03   ` Richard Guenther
2009-11-28 16:35     ` Paul Edwards
2009-11-28 17:03       ` Richard Guenther
2009-11-28 23:44         ` Paul Edwards

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=07600C4C9EAE47ADB6B1F8C655EDE27E@Paullaptop \
    --to=mutazilah@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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).