[Bug c/11151] New: __builtin_return(__builtin_apply(...)) gives wrong result

["gcczilla at achurch dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: __builtin_return(__builtin_apply(...)) gives wrong
                    result
           Product: gcc
           Version: 3.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gcczilla@achurch.org
                CC: gcc-bugs@gcc.gnu.org
 GCC build triplet: sparc-sun-solaris2.9
  GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9

__builtin_return(__builtin_apply(...)) does not return the correct value on
Solaris/SPARC systems.  Using the test code from bug 8028:

--------------- BEGIN foo.c ---------------
int foo(int n)
{
    return n;
}

int bar(int n)
{
    return n+1;
}

int quux(int n)
{
    foo(0);
    __builtin_return(__builtin_apply((void *)bar, __builtin_apply_args(), 64));
}

int main(int argc, char **argv)
{
    return quux(argc);
}
---------------- END foo.c ----------------

(compiled with "gcc -O0 foo.c -o foo") should exit with a value of argc+1, but
instead exits with 0 on my system.  I'm not a SPARC assembly expert by any
means, but the following part of the assembly generated for quux() looks suspicious:

        call    bar, 0          <-- __builtin_apply(bar,...)
        nop
        nop
        std     %o0, [%fp-64]   <-- save return value at -64(%fp)
        std     %f0, [%fp-56]
        mov     %l1, %sp
        add     %fp, -64, %o1   <-- %o1 = %fp-64
        [...]
        ld      [%o1], %i0      <-- restore return value
        ld      [%o1+4], %i1
        ld      [%o1+8], %f0
        ld      [%o1+12], %f1
        mov     %o0, %i0        <-- return value overwritten (BUG?)
        nop
        ret
        restore

The best guess I can make is that GCC is forgetting that the return value has
already been restored to %i0 and tries to copy it from %o0, which contains
garbage (it's used for other purposes in the intervening code, omitted here for
brevity).