toolchain/48026: devel/bison crashes on earm because of compiler bug

[mlelstv%serpens.de@localhost]

>Number:         48026
>Category:       toolchain
>Synopsis:       devel/bison crashes on earm because of compiler bug
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 06 16:20:00 +0000 2013
>Originator:     Michael van Elst
>Release:        NetBSD 6.99.22
>Organization:
        
>Environment:
        
        
System: NetBSD twitty 6.99.22 NetBSD 6.99.22 (TWITTY) #1: Sat Jun 29 18:09:58 
CEST 2013 
mlelstv@pussyfoot:/home/netbsd-current/obj.evbarm/home/netbsd-current/src/sys/arch/evbarm/compile/TWITTY
 evbarm
Architecture: earm
Machine: evbarm
>Description:

Building x11/wxGTK28 on earm fails because bison crashes with a bus error.
The crash seems to be caused by a compiler bug.

bison crashes in function action_row:

Core was generated by `bison'.
Program terminated with signal 10, Bus error.
#0  0x00033678 in action_row ()
(gdb) bt
#0  0x00033678 in action_row ()
#1  0x00033e18 in tables_generate ()
#2  0x00015538 in main ()
(gdb) info registers
r0             0x9      9
r1             0xbfffba80       3221207680
r2             0x4023a2c0       1076077248
r3             0xbfffba80       3221207680
r4             0xbfffba7c       3221207676
r5             0x0      0
r6             0x60758  395096
r7             0x4020f330       1075901232
r8             0xbfffca84       3221211780
r9             0x1      1
r10            0xbfffca7c       3221211772
r11            0xbfffcab4       3221211828
r12            0x4024c5d8       1076151768
sp             0xbfffba40       0xbfffba40
lr             0x1      1
pc             0x33678  0x33678 <action_row+344>
cpsr           0xa0000110       2684354832

The relevant code part is:

   0x3364c <action_row+300>:    sub     r0, r11, #4096  ; 0x1000
   0x33650 <action_row+304>:    str     r9, [r0, #-64]  ; 0x40
   0x33654 <action_row+308>:    ldr     r9, [r2, r9, lsl #2]
   0x33658 <action_row+312>:    cmp     r9, #0
   0x3365c <action_row+316>:    beq     0x33680 <action_row+352>
   0x33660 <action_row+320>:    sub     r0, r11, #4096  ; 0x1000
   0x33664 <action_row+324>:    ldr     r0, [r0, #-64]  ; 0x40
   0x33668 <action_row+328>:    mov     lr, #1
   0x3366c <action_row+332>:    sub     r9, r11, #4096  ; 0x1000
   0x33670 <action_row+336>:    str     lr, [r9, #-72]  ; 0x48
   0x33674 <action_row+340>:    mov     r9, lr
=> 0x33678 <action_row+344>:    ldr     lr, [r0, #-104] ; 0x68
   0x3367c <action_row+348>:    str     r9, [lr, r0, lsl #2]
   0x33680 <action_row+352>:......

which corresponds to the source fragment (src/tables.c:265ff)
from bison-2.7.1:

          /* and record this rule as the rule to use if that
             token follows.  */
          if (actrow[j] != 0)
            {
              conflicted = true;
              conflrow[j] = 1;
            }

global variables:
static action_number *actrow;
static unsigned int *conflrow;

local variable:
  bool conflicted = false;



store j
   0x3364c <action_row+300>:    sub     r0, r11, #4096  ; 0x1000
   0x33650 <action_row+304>:    str     r9, [r0, #-64]  ; 0x40

fetch actrow[j]
   0x33654 <action_row+308>:    ldr     r9, [r2, r9, lsl #2]

if == 0 skip then part
   0x33658 <action_row+312>:    cmp     r9, #0
   0x3365c <action_row+316>:    beq     0x33680 <action_row+352>

fetch j
   0x33660 <action_row+320>:    sub     r0, r11, #4096  ; 0x1000
   0x33664 <action_row+324>:    ldr     r0, [r0, #-64]  ; 0x40

store 1 (==true) to the local variable conflicted
   0x33668 <action_row+328>:    mov     lr, #1
conflicted is accessed like a global variable?
   0x3366c <action_row+332>:    sub     r9, r11, #4096  ; 0x1000
   0x33670 <action_row+336>:    str     lr, [r9, #-72]  ; 0x48

store 1 to the global variable conflrow[j]
   0x33674 <action_row+340>:    mov     r9, lr
assumes r0 contains pointer to global variables to fetch conflrow
=> 0x33678 <action_row+344>:    ldr     lr, [r0, #-104] ; 0x68
assumes r0 contains index j
   0x3367c <action_row+348>:    str     r9, [lr, r0, lsl #2]

next instruction after then-part
   0x33680 <action_row+352>:......


The compiler made 'conflicted' a global variable, but that might
be a valid optimization.

The problem is that r0 is assumed to contain the global variable
base address and also the value of the index j.





>How-To-Repeat:
Build gxGTK28 on evbarm with eabi to see bison crashing.

>Fix:
        

>Unformatted: