[Bug debug/39432] New: [4.4 Regression] gdb.base/store.exp failures

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

Running ../../../gdb/testsuite/gdb.base/store.exp ...
FAIL: gdb.base/store.exp: upvar charest l; print old l, expecting -1 .*
FAIL: gdb.base/store.exp: upvar short l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar int l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar long l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar longest l; print old l, expecting -1
FAIL: gdb.base/store.exp: upvar doublest l; print old l, expecting -1

are new failures in gdb testsuite when compiled with 4.4 compared to store.c
compiled with 4.3.x.  The difference seems to be introduced by IRA, when
compiled with -fno-ira (when trunk still had that option) the test worked.

With the old RA, -g -O0 -dA -fverbose-asm compiled:
unsigned int foo (unsigned int, unsigned int);

unsigned int bar (register unsigned int a, register unsigned int b)
{
  register unsigned int c = a, d = b;
  c = foo (c, d);
  return c + d;
}

d is allocated in a call-saved register (%ebx), which is fine and c is assigned
a stack slot.  With IRA d is still allocated in %ebx, but c is in %eax,
call-clobbered register.  So when gdb in the foo call does up and checks the
value in c and d, it finds correct value of d, but garbage in c.

Could we perhaps at -O0 avoid allocating user variables that are live accross
function calls in call-clobbered registers?  For -O1 it is obviously a fine
decision.


-- 
           Summary: [4.4 Regression] gdb.base/store.exp failures
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux


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