[Bug middle-end/58335] New: S/390: reload vs lra regression - testcase builtin-in-setjmp

["krebbel at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 58335
           Summary: S/390: reload vs lra regression - testcase
                    builtin-in-setjmp
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: krebbel at gcc dot gnu.org

The following testcase fails when compiling with LRA enabled and succeeds
without LRA:

FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O1

main:
.LFB1:
    .loc 1 16 0
    stmg    %r6,%r15,48(%r15)
.LCFI2:
    larl    %r13,.L13
    lgr    %r14,%r15
    aghi    %r15,-240
.LCFI3:
    aghi    %r14,-64
    std    %f8,0(%r14)
    std    %f10,8(%r14)
    std    %f12,16(%r14)
    std    %f14,24(%r14)
    std    %f9,32(%r14)
    std    %f11,40(%r14)
    std    %f13,48(%r14)
    std    %f15,56(%r14)
    lgr    %r11,%r15
.LCFI4:
    .loc 1 17 0
    aghi    %r15,-32
    lgr    %r2,%r15
    aghi    %r2,160
    stg    %r2,160(%r11)
.LVL0:
    .loc 1 19 0
    larl    %r1,.LC1
    mvc    0(5,%r2),0(%r1)
    .loc 1 21 0
    larl    %r1,buf
    la    %r3,176(%r11)       176+r11 is stored as framepointer
    stg    %r3,0(%r1)
    larl    %r3,.L4
    stg    %r3,8(%r1)
    stg    %r15,24(%r1)
    stg    %r13,32(%r1)
    lhi    %r1,0
    .loc 1 23 0
    stg    %r2,168(%r11)
    j    .L5
.LVL1:
.L4:
    .loc 1 21 0
    lghi    %r1,-160
    la    %r11,0(%r1,%r11)    When restoring r11 only 160 is subtracted
    lhi    %r1,1
.L5:
    .loc 1 21 0 is_stmt 0 discriminator 4
    ltr    %r1,%r1
    je    .L6
    .loc 1 23 0 is_stmt 1
    lhi    %r0,0
    larl    %r1,.LC1
    lg    %r2,168(%r11)       Wrong value loaded here
    clst    %r1,%r2             segfault here


During LRA the elimination offset for r34 %fp to r11 changes from 160 to 176.
The first insn gets the update but not the second.  From a first glance the
reason appears to be that the insn for "lghi %r1,-160" it self is generated by
a reload using a pseudo register which equals -160. This register does not seem
to get the update after the offset changed.