reload segfault

reload segfault

[Bill Currie]

First off, this is with a heavily modified i860 port of yesterday's CVS
tree, so it's *probably* my fault.  The problem insn is occurring in
__bb_exit_func (ie I can't 1st stage bootstrap).

I'm getting a segmentation fault in reload_cse_noop_set_p with the
following insn:

(insn 1396 1393 455 (set (reg:SI 30 r30)
        (reg:SI 169)) 56 {bleu+1} (nil)
    (nil))

at line 8901 of reload1.c

8897              for (x = reg_values[sreg]; x; x = XEXP (x, 1))
8898                {
8899                  rtx tmp;
8900    
8901                  if (XEXP (x, 0) == 0)
8902                    continue;

To me, the symptom is obvious: sreg is 169, much higher than
FIRST_PSEUDO_REGISTER.  Now, the question is: who is wrong? Is there a
bug in reload_cse_noop_set_p where it should be checking the register
number first, or did I screw up somewhere and cause a pseudo reg to show
up where it shouldn't?

Here's the traceback:

#0  0x1fb018 in reload_cse_noop_set_p (set=0x3a74b0, insn=0x3a7500)
    at ../../egcs/gcc/reload1.c:8901
#1  0x1fa590 in reload_cse_regs_1 (first=0x344758)
    at ../../egcs/gcc/reload1.c:8661
#2  0x1fabf4 in reload_cse_regs (first=0x344758)
    at ../../egcs/gcc/reload1.c:8806
#3  0xa68c in rest_of_compilation (decl=0x343240)
    at ../../egcs/gcc/toplev.c:3979
#4  0x262a7c in finish_function (nested=0) at
../../egcs/gcc/c-decl.c:7272
#5  0x243b24 in yyparse () at ../../egcs/gcc/c-parse.c:313
#6  0x6f84 in compile_file (name=0x7ffffe31 "f.c")
    at ../../egcs/gcc/toplev.c:2899
#7  0xd618 in main (argc=3, argv=0x7ffffd74) at
../../egcs/gcc/toplev.c:5192
#8  0x2474 in _start ()

Bill
-- 
Leave others their otherness.

Re: reload segfault

[Jeffrey A Law]

  In message < 36AA3677.7837E26D@taniwha.tssc.co.nz >you write:
  > First off, this is with a heavily modified i860 port of yesterday's CVS
  > tree, so it's *probably* my fault.  The problem insn is occurring in
  > __bb_exit_func (ie I can't 1st stage bootstrap).
  > 
  > I'm getting a segmentation fault in reload_cse_noop_set_p with the
  > following insn:
  > 
  > (insn 1396 1393 455 (set (reg:SI 30 r30)
  >         (reg:SI 169)) 56 {bleu+1} (nil)
  >     (nil))
  > 
  > at line 8901 of reload1.c
  > 
  > 8897              for (x = reg_values[sreg]; x; x = XEXP (x, 1))
  > 8898                {
  > 8899                  rtx tmp;
  > 8900    
  > 8901                  if (XEXP (x, 0) == 0)
  > 8902                    continue;
  > 
  > To me, the symptom is obvious: sreg is 169, much higher than
  > FIRST_PSEUDO_REGISTER.  Now, the question is: who is wrong? Is there a
  > bug in reload_cse_noop_set_p where it should be checking the register
  > number first, or did I screw up somewhere and cause a pseudo reg to show
  > up where it shouldn't?
This pseudo should have been replaced by a hard reg or a stack slot by the
time reload_cse runs.

The first thing I check for when I see this kind of problem is the use/set
counts for the register in question.

p reg_n_info.u.regs[169]

In particular check the "refs" field.  If it is zero, then the problem is
probably before allocation & reload.  If it's nonzero, then you're going to
have to dive deeper into reload.

jeff

Re: reload segfault

[Bill Currie]

Jeffrey A Law wrote:
> This pseudo should have been replaced by a hard reg or a stack slot by the
> time reload_cse runs.

That's what I suspected.  This means I did something wrong somewhere
during the reload pass (ie allocating a pseudo is my best guess).

> The first thing I check for when I see this kind of problem is the use/set
> counts for the register in question.
> 
> p reg_n_info.u.regs[169]

gdb didn't like that: `There is no member named u.'

> In particular check the "refs" field.  If it is zero, then the problem is
> probably before allocation & reload.  If it's nonzero, then you're going to
> have to dive deeper into reload.

I beleive I'll have to anyway (I can't quickly find the info your
talking about) as I think I've incorrectly allocated a pseudo (thanks to
your confirmation of that thought) that somehow slipped though the check
in gen_reg_rtx.  I'll do some careful breakpoint trickery on that
function and see if it get's me anywhere.

I seem to remember a discussion about reload_in_progress and
reload_completed not being enough to test whether it's safe to allocate
pseudos.  Is this true, and if so, what's the solution?

Bill
-- 
Leave others their otherness.

Re: reload segfault

[Jeffrey A Law]

  In message < 36AB9655.30985146@taniwha.tssc.co.nz >you write:

  > > counts for the register in question.
  > > 
  > > p reg_n_info.u.regs[169]
  > 
  > gdb didn't like that: `There is no member named u.'
It's something close to that :-)  maybe "data" instead of "u"  Not sure off
the top of my head.


  > I seem to remember a discussion about reload_in_progress and
  > reload_completed not being enough to test whether it's safe to allocate
  > pseudos.  Is this true, and if so, what's the solution?
Check no_new_pseudos.

jeff

Re: reload segfault

[Jeffrey A Law]

  In message < 36AB9655.30985146@taniwha.tssc.co.nz >you write:

  > > counts for the register in question.
  > > 
  > > p reg_n_info.u.regs[169]
  > 
  > gdb didn't like that: `There is no member named u.'
It's something close to that :-)  maybe "data" instead of "u"  Not sure off
the top of my head.


  > I seem to remember a discussion about reload_in_progress and
  > reload_completed not being enough to test whether it's safe to allocate
  > pseudos.  Is this true, and if so, what's the solution?
Check no_new_pseudos.

jeff

Re: reload segfault

[Bill Currie]

Jeffrey A Law wrote:
> This pseudo should have been replaced by a hard reg or a stack slot by the
> time reload_cse runs.

That's what I suspected.  This means I did something wrong somewhere
during the reload pass (ie allocating a pseudo is my best guess).

> The first thing I check for when I see this kind of problem is the use/set
> counts for the register in question.
> 
> p reg_n_info.u.regs[169]

gdb didn't like that: `There is no member named u.'

> In particular check the "refs" field.  If it is zero, then the problem is
> probably before allocation & reload.  If it's nonzero, then you're going to
> have to dive deeper into reload.

I beleive I'll have to anyway (I can't quickly find the info your
talking about) as I think I've incorrectly allocated a pseudo (thanks to
your confirmation of that thought) that somehow slipped though the check
in gen_reg_rtx.  I'll do some careful breakpoint trickery on that
function and see if it get's me anywhere.

I seem to remember a discussion about reload_in_progress and
reload_completed not being enough to test whether it's safe to allocate
pseudos.  Is this true, and if so, what's the solution?

Bill
-- 
Leave others their otherness.

Re: reload segfault

[Bill Currie]

Jeffrey A Law wrote:
> 
>   In message < 36AA3677.7837E26D@taniwha.tssc.co.nz >you write:
>   > First off, this is with a heavily modified i860 port of yesterday's CVS
>   > tree, so it's *probably* my fault.  The problem insn is occurring in
>   > __bb_exit_func (ie I can't 1st stage bootstrap).
>   >
>   > I'm getting a segmentation fault in reload_cse_noop_set_p with the
>   > following insn:
>   >
>   > (insn 1396 1393 455 (set (reg:SI 30 r30)
>   >         (reg:SI 169)) 56 {bleu+1} (nil)
>   >     (nil))

Same problem again, different instance.

(insn 2962 4714 2966 (set (reg:DF 60 f28)
        (mult:DF (reg:DF 60 f28)
            (reg:DF 54 f22))) 130 {muldf3} (insn_list 2959 (nil))
    (nil))

Tweaking PREFERRED_RELOAD_CLASS didn't seem to make much difference this
time.

> This pseudo should have been replaced by a hard reg or a stack slot by the
> time reload_cse runs.
> 
> The first thing I check for when I see this kind of problem is the use/set
> counts for the register in question.
> 
> p reg_n_info.u.regs[169]

(gdb) p *reg_n_info->data.reg[839]
$19 = {first_uid = 4049, last_uid = 2962, last_note_uid = 2962, sets =
1, 
  refs = 5, deaths = 0, live_length = 236, calls_crossed = 6, 
  basic_block = -2, changes_size = 0 '\000'}
 
> In particular check the "refs" field.  If it is zero, then the problem is
> probably before allocation & reload.  If it's nonzero, then you're going to
> have to dive deeper into reload.

'Elp!! refs is most definitly nonzero (5).  Due to my solution to the
first time I had this problem, I still suspect PREFERRED_RELOAD_CLASS,
but reload seams to be extreamly fagile with inexperienced gcc hackers
(I'm a fair coder, but reload scares me, it's *HUGE*, does any one have
some notes on the operation of reload they're willing to share with me?)

I am so close to getting egcs/gcc to work nicely on the i860, it's not
funny (big endian, no less).  This is so frustrating.  I'm begginning to
wander if I'ld be better off starting from scratch and rewriting the
i860 backend (big job, I know, which is why I haven't, but it would get
rid of all that bitrot).

Bill
-- 
Leave others their otherness

Re: reload segfault

[Bill Currie]

Bill Currie wrote:
> 
> Same problem again, different instance.
> 
> (insn 2962 4714 2966 (set (reg:DF 60 f28)
>         (mult:DF (reg:DF 60 f28)
>             (reg:DF 54 f22))) 130 {muldf3} (insn_list 2959 (nil))
>     (nil))

Hmm, oops, not same problem, BUT I am having problems with reload in
general, so my plea for help still stands.
-- 
Leave others their otherness

Re: reload segfault

[Jeffrey A Law]

  In message < 36B1137E.3D3D7CDB@tssc.co.nz >you write:
  > 'Elp!! refs is most definitly nonzero (5).  Due to my solution to the
  > first time I had this problem, I still suspect PREFERRED_RELOAD_CLASS,
  > but reload seams to be extreamly fagile with inexperienced gcc hackers
  > (I'm a fair coder, but reload scares me, it's *HUGE*, does any one have
  > some notes on the operation of reload they're willing to share with me?)
OK.  Look at reg_renumber[169] and reg_equiv_mem[169]

reg_renumber should be >= 0 else reg_equiv_mem should be an rtx for a stack
slot.


jeff

Re: reload segfault

[Bill Currie]

Jeffrey A Law wrote:
> 
>   In message < 36B1137E.3D3D7CDB@tssc.co.nz >you write:
>   > 'Elp!! refs is most definitly nonzero (5).  Due to my solution to the
>   > first time I had this problem, I still suspect PREFERRED_RELOAD_CLASS,
>   > but reload seams to be extreamly fagile with inexperienced gcc hackers
>   > (I'm a fair coder, but reload scares me, it's *HUGE*, does any one have
>   > some notes on the operation of reload they're willing to share with me?)
> OK.  Look at reg_renumber[169] and reg_equiv_mem[169]
> 
> reg_renumber should be >= 0 else reg_equiv_mem should be an rtx for a stack
> slot.
> 
> jeff

Sorry, I grabbed the wrong insn dump in my previous message.

(insn 4723 4720 2962 (set (reg:DF 54 f22)
        (reg:DF 839)) 74 {movstrsi+2} (nil)
    (nil))

(gdb) p *reg_n_info.data.reg[839]
$3 = {first_uid = 4049, last_uid = 2962, last_note_uid = 2962, sets = 1, 
  refs = 5, deaths = 0, live_length = 236, calls_crossed = 6, 
  basic_block = -2, changes_size = 0 '\000'}
(gdb) p reg_renumber[839]
$4 = -1
(gdb) p reg_equiv_mem[839]
$5 = (rtx_def *) 0x0
(gdb) 

I now know it is definitly PREFERRED_RELOAD_CLASS, defined as:

#define PREFERRED_RELOAD_CLASS(X,CLASS) preferred_reload_class (X,
CLASS)

With

enum reg_class
preferred_reload_class(x, class)
     rtx x;
     enum reg_class class;
{
  if (GET_CODE (x) == HIGH
      || GET_CODE (x) == LO_SUM)
    return GENERAL_REGS;
  if (!CONSTANT_P (x))
    return class;
  if (class == FP_REGS)
    {
      if (CONST_DOUBLE_OK_FOR_LETTER_P (x, 'G'))
        return class;
      /* a constant int that can be loaded into a general register in
one
	 instruction takes the same number of instructions to put into an
	 fp reg as loading from memory, but saves the 4 bytes of memory
	 needed to store the constant */
      if (GET_CODE (x) == CONST_INT
	  && ((INTVAL (x) & 0x0000ffff) == 0
	      || (INTVAL (x) & 0xffff0000) == 0))
	return GENERAL_REGS;
      return NO_REGS;
    }
  /* int->reg is proabably always best as general regs */
  if ((class == SCRATCH_REGS
       || class == GENERAL_REGS
       || class == ALL_REGS)
      && GET_MODE_CLASS (GET_MODE (x)) == MODE_INT)
    return GENERAL_REGS;
  if (GET_CODE (x) == CONST_DOUBLE)
      return NO_REGS;
  return class;
/*  return GENERAL_REGS;*/
}

If I change the #define to just return CLASS (rather than the function
call), this particular problem dissapears, but in other code I get:

(insn 2193 1790 2194 (set (reg:PSI 31 r31)
        (high:PSI (lo_sum:PSI (reg:PSI 27 r27)
                (symbol_ref:SI ("system_include_depth"))))) -1 (nil)
    (nil))

which is definitly bogus.

I'm going to continue tweaking my preferred_reload_class function and
see if I can get it to work.  As it seems to only be DFmode regs that
give me problems, I should get something soon (I hope).

Bill
-- 
Leave others their otherness.

Re: reload segfault

[Michael Hayes]

Bill Currie writes:

 > If I change the #define to just return CLASS (rather than the function
 > call), this particular problem dissapears, but in other code I get:
 > 
 > (insn 2193 1790 2194 (set (reg:PSI 31 r31)
 >         (high:PSI (lo_sum:PSI (reg:PSI 27 r27)
 >                 (symbol_ref:SI ("system_include_depth"))))) -1 (nil)
 >     (nil))
 > 
 > which is definitly bogus.
 > 
 > I'm going to continue tweaking my preferred_reload_class function and
 > see if I can get it to work.  As it seems to only be DFmode regs that
 > give me problems, I should get something soon (I hope).

FYI, I had to tweak PREFERRED_RELOAD_CLASS for the C4x recently as
well to fix a problem I had with an optional inherited reload.
(I think this was triggered by Jim Wilson's 2 Dec patch).
I ended up just returning CLASS to solve the problem.  

Re: reload segfault

[Bill Currie]

Michael Hayes wrote:
> 
> Bill Currie writes:
> 
>  > If I change the #define to just return CLASS (rather than the function
>  > call), this particular problem dissapears, but in other code I get:
>  >
>  > (insn 2193 1790 2194 (set (reg:PSI 31 r31)
>  >         (high:PSI (lo_sum:PSI (reg:PSI 27 r27)
>  >                 (symbol_ref:SI ("system_include_depth"))))) -1 (nil)
>  >     (nil))
>  >
>  > which is definitly bogus.
>  >
>  > I'm going to continue tweaking my preferred_reload_class function and
>  > see if I can get it to work.  As it seems to only be DFmode regs that
>  > give me problems, I should get something soon (I hope).
> 
> FYI, I had to tweak PREFERRED_RELOAD_CLASS for the C4x recently as
> well to fix a problem I had with an optional inherited reload.
> (I think this was triggered by Jim Wilson's 2 Dec patch).
> I ended up just returning CLASS to solve the problem.

I was returning NO_REGS when I really should have been returning CLASS
(just the one line in the whole function was wrong).

However, I think I may have just discovered the root cause of all my
problems:  Insufficient strict versions of various macros, and possibly
some missing ones.  I believe the original i860 work is quite old, so it
probably pre-dates many macros, definitly many of the recent changes. 
Lots of bitrot I guess.

I'm currently having problems with incorrect regclasses (more
PREFERRED_RELOAD_CLASS bogosity?), such as int regs being assigned to fp
operands, but that may be due to me not getting my regclass defines
right (I added a new class).

Bill
-- 
Leave others their otherness

Re: reload segfault

[Jeffrey A Law]

  In message < 36B176BE.40047244@taniwha.tssc.co.nz >you write:
  > Sorry, I grabbed the wrong insn dump in my previous message.
  > 
  > (insn 4723 4720 2962 (set (reg:DF 54 f22)
  >         (reg:DF 839)) 74 {movstrsi+2} (nil)
  >     (nil))
  > 
  > (gdb) p *reg_n_info.data.reg[839]
  > $3 = {first_uid = 4049, last_uid = 2962, last_note_uid = 2962, sets = 1, 
  >   refs = 5, deaths = 0, live_length = 236, calls_crossed = 6, 
  >   basic_block = -2, changes_size = 0 '\000'}
  > (gdb) p reg_renumber[839]
  > $4 = -1
  > (gdb) p reg_equiv_mem[839]
  > $5 = (rtx_def *) 0x0
  > (gdb) 
A bad sign.  You should also probably check reg_equiv_constant[839]

Basically 839 didn't get a hard reg or a stack slot.  There's not many ways
that can/should happen. 

You might want to put a breakpoints in this code from reload1.c and try to
sort out what's going on (then work forwards or backwards in reload1.c
depending on what you find)

      /* For each pseudo register that has an equivalent location defined,
         try to eliminate any eliminable registers (such as the frame pointer)
         assuming initial offsets for the replacement register, which
         is the normal case.

         If the resulting location is directly addressable, substitute
         the MEM we just got directly for the old REG.
[ ... ]

      for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
        if (reg_renumber[i] < 0 && reg_equiv_memory_loc[i])




jeff

Re: reload segfault

[Jeffrey A Law]

  In message < 36AA3677.7837E26D@taniwha.tssc.co.nz >you write:
  > First off, this is with a heavily modified i860 port of yesterday's CVS
  > tree, so it's *probably* my fault.  The problem insn is occurring in
  > __bb_exit_func (ie I can't 1st stage bootstrap).
  > 
  > I'm getting a segmentation fault in reload_cse_noop_set_p with the
  > following insn:
  > 
  > (insn 1396 1393 455 (set (reg:SI 30 r30)
  >         (reg:SI 169)) 56 {bleu+1} (nil)
  >     (nil))
  > 
  > at line 8901 of reload1.c
  > 
  > 8897              for (x = reg_values[sreg]; x; x = XEXP (x, 1))
  > 8898                {
  > 8899                  rtx tmp;
  > 8900    
  > 8901                  if (XEXP (x, 0) == 0)
  > 8902                    continue;
  > 
  > To me, the symptom is obvious: sreg is 169, much higher than
  > FIRST_PSEUDO_REGISTER.  Now, the question is: who is wrong? Is there a
  > bug in reload_cse_noop_set_p where it should be checking the register
  > number first, or did I screw up somewhere and cause a pseudo reg to show
  > up where it shouldn't?
This pseudo should have been replaced by a hard reg or a stack slot by the
time reload_cse runs.

The first thing I check for when I see this kind of problem is the use/set
counts for the register in question.

p reg_n_info.u.regs[169]

In particular check the "refs" field.  If it is zero, then the problem is
probably before allocation & reload.  If it's nonzero, then you're going to
have to dive deeper into reload.

jeff

reload segfault

[Bill Currie]

First off, this is with a heavily modified i860 port of yesterday's CVS
tree, so it's *probably* my fault.  The problem insn is occurring in
__bb_exit_func (ie I can't 1st stage bootstrap).

I'm getting a segmentation fault in reload_cse_noop_set_p with the
following insn:

(insn 1396 1393 455 (set (reg:SI 30 r30)
        (reg:SI 169)) 56 {bleu+1} (nil)
    (nil))

at line 8901 of reload1.c

8897              for (x = reg_values[sreg]; x; x = XEXP (x, 1))
8898                {
8899                  rtx tmp;
8900    
8901                  if (XEXP (x, 0) == 0)
8902                    continue;

To me, the symptom is obvious: sreg is 169, much higher than
FIRST_PSEUDO_REGISTER.  Now, the question is: who is wrong? Is there a
bug in reload_cse_noop_set_p where it should be checking the register
number first, or did I screw up somewhere and cause a pseudo reg to show
up where it shouldn't?

Here's the traceback:

#0  0x1fb018 in reload_cse_noop_set_p (set=0x3a74b0, insn=0x3a7500)
    at ../../egcs/gcc/reload1.c:8901
#1  0x1fa590 in reload_cse_regs_1 (first=0x344758)
    at ../../egcs/gcc/reload1.c:8661
#2  0x1fabf4 in reload_cse_regs (first=0x344758)
    at ../../egcs/gcc/reload1.c:8806
#3  0xa68c in rest_of_compilation (decl=0x343240)
    at ../../egcs/gcc/toplev.c:3979
#4  0x262a7c in finish_function (nested=0) at
../../egcs/gcc/c-decl.c:7272
#5  0x243b24 in yyparse () at ../../egcs/gcc/c-parse.c:313
#6  0x6f84 in compile_file (name=0x7ffffe31 "f.c")
    at ../../egcs/gcc/toplev.c:2899
#7  0xd618 in main (argc=3, argv=0x7ffffd74) at
../../egcs/gcc/toplev.c:5192
#8  0x2474 in _start ()

Bill
-- 
Leave others their otherness.