public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael_Collison@iris.com
To: egcs@cygnus.com
Cc: gcc2@cygnus.com
Subject: Problem in 'reload_cse_regno_equal_p'
Date: Tue, 28 Apr 1998 11:00:00 -0000	[thread overview]
Message-ID: <852565F4.005648AF.00@arista.iris.com> (raw)

I have built both gcc-2.8.1 and egc-1.0.2 for the target 'dsp16xx' a DSP
processor.
When I compile with optimization I get an access violation in the function
'reload_cse_regno_equal_p' which is shown below.

static int
reload_cse_regno_equal_p (regno, val, mode)
     int regno;
     rtx val;
     enum machine_mode mode;
{
  rtx x;

  if (val == 0)
    return 0;

  for (x = reg_values[regno]; x; x = XEXP (x, 1))
    if (XEXP (x, 0) != 0
     && rtx_equal_p (XEXP (x, 0), val)
     && (GET_CODE (val) != CONST_INT
         || mode == GET_MODE (x)
         || (GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE (x))
          /* On a big endian machine if the value spans more than
             one register then this register holds the high part of
             it and we can't use it.

             ??? We should also compare with the high part of the
             value.  */
          && !(WORDS_BIG_ENDIAN
               && HARD_REGNO_NREGS (regno, GET_MODE (x)) > 1)
          && TRULY_NOOP_TRUNCATION (GET_MODE_BITSIZE (mode),
                           GET_MODE_BITSIZE (GET_MODE (x))))))
      return 1;

  return 0;
}

The stack trace from gdb is shown below:

(gdb) where
#0  reload_cse_regno_equal_p (regno=42, val=0x1cb5e0, mode=QImode)
    at ../reload1.c:8056
#1  0x139d98 in reload_cse_simplify_operands (insn=0x1b3e58)
    at ../reload1.c:8326
#2  0x138cb8 in reload_cse_regs (first=0x1b3b70) at ../reload1.c:7960
#3  0x4ddd8 in rest_of_compilation (decl=0x1cc2d0) at ../toplev.c:3501
#4  0x39aac in finish_function (nested=0) at ../c-decl.c:7100
#5  0x27c2c in yyparse () at c-parse.y:319
#6  0x4bdf8 in compile_file (name=0xeffff441 "f_play2.i") at
../toplev.c:2484
#7  0x4f2fc in main (argc=3, argv=0xeffff2cc, envp=0xeffff2dc)
    at ../toplev.c:4353
(gdb)

The insn in function 'reload_cse_simplify_operands' is:

insn 8 6 10 (set (reg:QI 9 r0)
        (symbol_ref:QI ("bg_flags"))) 48 {match_movqi2} (nil)
    (expr_list:REG_EQUAL (symbol_ref:QI ("bg_flags"))
        (nil)))

In function 'reload_cse_regno_equal_p' the variable 'x' is initialized to

x = reg_values[42] = (set (reg:QI 9 r0)
               (symbol_ref:QI ("bg_flags")))

Now the second time through the loop 'x' = (symbol_ref:QI ("bg_flags"))

The third time thru the loop 'x' is assigned a bad pointer (because
SYMBOL_REF's only have
one parameter, operand 0). Now XEXP(x,0) is non null (but a bad pointer)
and a memory exception occurs.

It seems that the code for the 'for' loop is incorrect. Why is 'x' being
set
equal to 'XEXP(x,1)' everytime thru the loop? The code seems to be assuming
that it will hit a null pointer and things will be okay with the check at
the next line. Is it okay for the code to assume this?

Michael Collison



             reply	other threads:[~1998-04-28 11:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-28 11:00 Michael_Collison [this message]
1998-04-28 14:10 ` Joern Rennecke
1998-04-29 15:21 Michael_Collison

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=852565F4.005648AF.00@arista.iris.com \
    --to=michael_collison@iris.com \
    --cc=egcs@cygnus.com \
    --cc=gcc2@cygnus.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).