GCC: ARITHMODE restore not dominated by save

[margnus1]

Hi! I believe I have stumbled upon a bug in your GCC backend:

#define FUNNY_NUMBER1  268440163

/*
 * When compiled with -Os, -Og or -O0 and sz==0, I will set the ARITHMODE flags
 * of the config register from an unitilialized gp register.
 */
unsigned
hash(char *ptr, unsigned sz, unsigned hash)
{
    while (sz--) {
        hash = hash*FUNNY_NUMBER1 + *ptr++;
    }
    return hash;
}

The issue is easily spotted in the assembly output:

kalle ~/repro> e-gcc -Og -S -c gcc.c && cat gcc.s
    .file   "gcc.c"
    .section .text
    .balign 4
    .global _hash
_hash:
    mov r3,r0
    mov r0,r2
    mov r17, %low(#268440163)
    movt r17, %high(#268440163)
    b .L2
.L3:
    mov r1, %low(#524288)
    movt r1, %high(#524288)
    movfs r16,config
    gid
    movfs r18,config
    orr r18,r18,r1
    movts config,r18
    gie
    gid
    movfs r19,config
    orr r19,r19,r1
    movts config,r19
    gie
    imul r0, r0, r17
    ldrb r1,[r3]
    add r0,r0,r1
    mov r1,r2
    add r3,r3,#1
.L2:
    add r2,r1,#-1
    sub r19,r1,#0
    bne .L3
    mov r1, %low(#-917506)
    movt r1, %high(#-917506)
    gid
    movfs r3,config
    eor r3,r3,r16
    and r3,r3,r1
    eor r3,r3,r16
    movts config,r3
    gie
    gid
    movfs r19,config
    eor r19,r19,r16
    and r19,r19,r1
    eor r19,r19,r16
    movts config,r19
    gie
    rts
    .size   _hash, .-_hash
    .ident  "GCC: (Epiphany toolchain 2015.1) 4.8.2 20130729 (prerelease)"

Control will flow from _hash to .L2, never take the branch to .L3, thus never saving config to r16, and proceed to restore ARITHMODE from r16 (that remains unitinialized) before returning.

You might ask, what's the issue? Well, consider that this function might set ARITHMODE to 010. The next time any function attempts integer multiplication, it will assert config bit 19, assuming that it results in an ARITHMODE of 100. In this case, though, that results in an ARITHMODE of 110, which on my E16G301 causes the "FPU/IALU2" pipeline to perform floating-point math.

[olajep]

Hi Magnus,

Thank you for reporting. Yes, it is a bug.

Fore future reference, here's a gcc test that also miscompiles because of it:

FAIL: gcc.c-torture/execute/struct-ret-1.c   -Os  execution test