[Bug target/59613] New: Incorrect code generation in MSP430 large model

[l.marcantonio at logossrl dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613

            Bug ID: 59613
           Summary: Incorrect code generation in MSP430 large model
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: l.marcantonio at logossrl dot com

Found on 4.9.0 fresh from trunk (svn 206223); it's actually a showstopper for
large model since it miscompiles crtbegin.o (frame_dummy(), for example).
However I found a minimal sample which gives the problem  (it's a function
pointer instead of a weak symbol but the problem is the same).

Code generation (or optimization) is broken for MSP430 in large model; given
this simple code:

/*****/
extern void (*unk_function)(void);

void do_stuff(void)
{
    if (unk_function)
        unk_function();
}
/*****/

Compiling in standard mode with 

msp430-elf-gcc -mmcu=msp430x -Wall -S -O2 test.c

gives the following assembly (which is quite adequate)

.text
        .balign 2
        .global do_stuff
do_stuff:
; start of function
; framesize_regs:     0
; framesize_locals:   0
; framesize_outgoing: 0
; framesize:          0
; elim ap -> fp       2
; elim fp -> sp       0
; saved regs:(none)
        ; start of prologue
        ; end of prologue
        MOV.W   &unk_function, R12
        CMP.W   #0, R12 { JEQ   .L1
        CALL    R12
.L1:
        ; start of epilogue
        RET

However in large model (adding -mlarge to the above command line) the result is

.text
        .balign 2
        .global do_stuff
do_stuff:
; start of function
; framesize_regs:     0
; framesize_locals:   0
; framesize_outgoing: 0
; framesize:          0
; elim ap -> fp       4
; elim fp -> sp       0
; saved regs:(none)
        ; start of prologue
        ; end of prologue
        CALLA   &unk_function
        ; start of epilogue
        RETA

The condition checking is not done, and a crash follows. Using -O0 or -Os
doesn't change the behaviour. Looking in the RTL with -fdump-final-insns shows
a NOTE_INSN_DELETED instead of the condition check but I'm not proficient to
interpretate that...