diff mbox

Missing guard in ira-color.c ?

Message ID 73132AAC-F8D8-4807-9703-3731332D7A93@adacore.com
State New
Headers show

Commit Message

Tristan Gingold May 10, 2012, 1:10 p.m. UTC 
Hi,

I am getting a segfault in ira-color.c:2945 on the trunk:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
2945		      || ira_reg_equiv_const[regno] != NULL_RTX
(gdb) l
2940		      /* don't do the optimization because it can create
2941			 copies and the reload pass can spill the allocno set
2942			 by copy although the allocno will not get memory
2943			 slot.  */
2944		      || ira_reg_equiv_invariant_p[regno]
2945		      || ira_reg_equiv_const[regno] != NULL_RTX
2946		      || !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
2947		    continue;
2948		  mode = ALLOCNO_MODE (a);
2949		  rclass = ALLOCNO_CLASS (a);

while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler (target=ia64-vms, host=x86_64-linux).

The reason looks to be an out of bounds access:

(gdb) print regno
$10 = 18476
(gdb) print ira_reg_equiv_len 
$11 = 17984

(I suppose this setup is not easy at all to reproduce, but I can provide any files, if necessary).

Wild guess, as I don't know IRA at all:  looks like in this file most accesses to ira_reg_equiv_* are guarded.  Is it expected that they aren't at this point ?

[I am currently trying with the following chunk:

]

Thanks for any comment,
Tristan.

Comments

Vladimir Makarov May 10, 2012, 8:41 p.m. UTC | #1 
On 05/10/2012 09:10 AM, Tristan Gingold wrote:
> Hi,
>
> I am getting a segfault in ira-color.c:2945 on the trunk:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
> 2945		      || ira_reg_equiv_const[regno] != NULL_RTX
> (gdb) l
> 2940		      /* don't do the optimization because it can create
> 2941			 copies and the reload pass can spill the allocno set
> 2942			 by copy although the allocno will not get memory
> 2943			 slot.  */
> 2944		      || ira_reg_equiv_invariant_p[regno]
> 2945		      || ira_reg_equiv_const[regno] != NULL_RTX
> 2946		      || !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
> 2947		    continue;
> 2948		  mode = ALLOCNO_MODE (a);
> 2949		  rclass = ALLOCNO_CLASS (a);
>
> while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler (target=ia64-vms, host=x86_64-linux).
>
> The reason looks to be an out of bounds access:
>
> (gdb) print regno
> $10 = 18476
> (gdb) print ira_reg_equiv_len
> $11 = 17984
>
> (I suppose this setup is not easy at all to reproduce, but I can provide any files, if necessary).
Tristan, thanks for reporting this.
> Wild guess, as I don't know IRA at all:  looks like in this file most accesses to ira_reg_equiv_* are guarded.  Is it expected that they aren't at this point ?
Yes, I guess.  It is possible to have the pseudos which are out of range 
ira_reg_equiv_const.  It should be hard to reproduce such error because 
they are generated when we need to break circular dependence (e.g. when 
hard register 1 should be moved to hard register 2 and hard register 2 
to hard register 1).

Your solution is perfectly fine.  So you can commit the patch into the 
trunk as pre-approved.

Thanks again.

> [I am currently trying with the following chunk:
>
> --- a/gcc/ira-color.c
> +++ b/gcc/ira-color.c
> @@ -2941,8 +2941,9 @@ move_spill_restore (void)
>                   copies and the reload pass can spill the allocno set
>                   by copy although the allocno will not get memory
>                   slot.  */
> -             || ira_reg_equiv_invariant_p[regno]
> -             || ira_reg_equiv_const[regno] != NULL_RTX
> +             || (regno<  ira_reg_equiv_len
> +&&  (ira_reg_equiv_invariant_p[regno]
> +                     || ira_reg_equiv_const[regno] != NULL_RTX))
>                || !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
>              continue;
>            mode = ALLOCNO_MODE (a);
> ]
>
>
Tristan Gingold May 11, 2012, 7:38 a.m. UTC | #2 
On May 10, 2012, at 10:41 PM, Vladimir Makarov wrote:

> On 05/10/2012 09:10 AM, Tristan Gingold wrote:
>> Hi,
>> 
>> I am getting a segfault in ira-color.c:2945 on the trunk:
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
>> 2945		      || ira_reg_equiv_const[regno] != NULL_RTX
>> (gdb) l
>> 2940		      /* don't do the optimization because it can create
>> 2941			 copies and the reload pass can spill the allocno set
>> 2942			 by copy although the allocno will not get memory
>> 2943			 slot.  */
>> 2944		      || ira_reg_equiv_invariant_p[regno]
>> 2945		      || ira_reg_equiv_const[regno] != NULL_RTX
>> 2946		      || !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
>> 2947		    continue;
>> 2948		  mode = ALLOCNO_MODE (a);
>> 2949		  rclass = ALLOCNO_CLASS (a);
>> 
>> while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler (target=ia64-vms, host=x86_64-linux).
>> 
>> The reason looks to be an out of bounds access:
>> 
>> (gdb) print regno
>> $10 = 18476
>> (gdb) print ira_reg_equiv_len
>> $11 = 17984
>> 
>> (I suppose this setup is not easy at all to reproduce, but I can provide any files, if necessary).
> Tristan, thanks for reporting this.
>> Wild guess, as I don't know IRA at all:  looks like in this file most accesses to ira_reg_equiv_* are guarded.  Is it expected that they aren't at this point ?
> Yes, I guess.  It is possible to have the pseudos which are out of range ira_reg_equiv_const.  It should be hard to reproduce such error because they are generated when we need to break circular dependence (e.g. when hard register 1 should be moved to hard register 2 and hard register 2 to hard register 1).
> 
> Your solution is perfectly fine.  So you can commit the patch into the trunk as pre-approved.

Thank you for your prompt answer.  I will commit it after regtesting.

Tristan.
Tristan Gingold May 15, 2012, 7:59 a.m. UTC | #3 
On May 10, 2012, at 10:41 PM, Vladimir Makarov wrote:

> On 05/10/2012 09:10 AM, Tristan Gingold wrote:
>> Hi,
>> 
>> I am getting a segfault in ira-color.c:2945 on the trunk:
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
>> 2945		      || ira_reg_equiv_const[regno] != NULL_RTX
>> (gdb) l
>> 2940		      /* don't do the optimization because it can create
>> 2941			 copies and the reload pass can spill the allocno set
>> 2942			 by copy although the allocno will not get memory
>> 2943			 slot.  */
>> 2944		      || ira_reg_equiv_invariant_p[regno]
>> 2945		      || ira_reg_equiv_const[regno] != NULL_RTX
>> 2946		      || !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
>> 2947		    continue;
>> 2948		  mode = ALLOCNO_MODE (a);
>> 2949		  rclass = ALLOCNO_CLASS (a);
>> 
>> while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler (target=ia64-vms, host=x86_64-linux).
>> 
>> The reason looks to be an out of bounds access:
>> 
>> (gdb) print regno
>> $10 = 18476
>> (gdb) print ira_reg_equiv_len
>> $11 = 17984
>> 
>> (I suppose this setup is not easy at all to reproduce, but I can provide any files, if necessary).
> Tristan, thanks for reporting this.
>> Wild guess, as I don't know IRA at all:  looks like in this file most accesses to ira_reg_equiv_* are guarded.  Is it expected that they aren't at this point ?
> Yes, I guess.  It is possible to have the pseudos which are out of range ira_reg_equiv_const.  It should be hard to reproduce such error because they are generated when we need to break circular dependence (e.g. when hard register 1 should be moved to hard register 2 and hard register 2 to hard register 1).
> 
> Your solution is perfectly fine.  So you can commit the patch into the trunk as pre-approved.

Now committed, after reg-testing on GNU/Linux x86_64.

Tristan.
diff mbox

Patch

--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -2941,8 +2941,9 @@  move_spill_restore (void)
                 copies and the reload pass can spill the allocno set
                 by copy although the allocno will not get memory
                 slot.  */
-             || ira_reg_equiv_invariant_p[regno]
-             || ira_reg_equiv_const[regno] != NULL_RTX
+             || (regno < ira_reg_equiv_len
+                 && (ira_reg_equiv_invariant_p[regno]
+                     || ira_reg_equiv_const[regno] != NULL_RTX))
              || !bitmap_bit_p (loop_node->border_allocnos, ALLOCNO_NUM (a)))
            continue;
          mode = ALLOCNO_MODE (a);