[Bug 1347637] [NEW] arm-linux-gnueabihf-gcc 4.8.2 produces wrong code when optimizing a function-pointer tail call when calling from softfp to hard fp ABI

[Margarita Manterola]

Public bug reported:

Hi,

gcc used to perform the appropriate conversions for software using
softfp that linked against software using hard fp ABI in ARM, using
version 4.6.3 (the one found in precise), but version 4.8.2 (trusty)
yields weird results from indirect functions that return a floating-
point value.

Calling the function directly, yields the expected result.

As an example (complete code attached), these functions would stand for the hard fp ABI:
---------
struct Test {
  __attribute__((pcs("aapcs-vfp"))) float (*f) ();
};

__attribute__((pcs("aapcs-vfp"))) float f();

const struct Test* GetTest();
---------

Using these wrappers for the softfp:
---------
float wrapper() {
  return GetTest()->f();
}

float wrapper_correct() {
  return f();
}
---------

The first one, that calls the function indirectly, yields incorrect assembler (dissasembly from wrapper.a):
00000000 <_Z7wrapperv>:
  0:   e52d4008        str     r4, [sp, #-8]!
  4:   e58de004        str     lr, [sp, #4]
  8:   ebfffffe        bl      0 <GetTest>
  c:   e5903000        ldr     r3, [r0]
 10:   e59d4000        ldr     r4, [sp]
 14:   e59de004        ldr     lr, [sp, #4]
 18:   e28dd008        add     sp, sp, #8
 1c:   e12fff13        bx      r3      // not populating r0

While the second one yields correct assembler:
00000020 <_Z15wrapper_correctv>:
 20:   e52d4008        str     r4, [sp, #-8]!
 24:   e58de004        str     lr, [sp, #4]
 28:   ebfffffe        bl      0 <f>
 2c:   e59d4000        ldr     r4, [sp]
 30:   e28dd004        add     sp, sp, #4
 34:   ee100a10        vmov    r0, s0      // populating r0
 38:   e49df004        pop     {pc}            ; (ldr pc, [sp], #4)

For comparison, these are the dissasemblies of both functions when compiled with 4.6.3 (precise):
00000000 <_Z7wrapperv>:
  0:   e92d4008        push    {r3, lr}
  4:   ebfffffe        bl      0 <GetTest>
  8:   e5903000        ldr     r3, [r0]
  c:   e12fff33        blx     r3
 10:   ee100a10        vmov    r0, s0
 14:   e8bd8008        pop     {r3, pc}

00000018 <_Z15wrapper_correctv>:
 18:   e92d4008        push    {r3, lr}
 1c:   ebfffffe        bl      0 <f>
 20:   ee100a10        vmov    r0, s0
 24:   e8bd8008        pop     {r3, pc}

** Affects: gcc-4.8-armhf-cross (Ubuntu)
     Importance: Undecided
         Status: New

** Attachment added: "Example code to reproduce the problem."
   https://bugs.launchpad.net/bugs/1347637/+attachment/4160894/+files/repro.zip

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-4.8-armhf-cross in Ubuntu.
https://bugs.launchpad.net/bugs/1347637

Title:
  arm-linux-gnueabihf-gcc 4.8.2 produces wrong code when optimizing a
  function-pointer tail call when calling from softfp to hard fp ABI

Status in “gcc-4.8-armhf-cross” package in Ubuntu:
  New

Bug description:
  Hi,

  gcc used to perform the appropriate conversions for software using
  softfp that linked against software using hard fp ABI in ARM, using
  version 4.6.3 (the one found in precise), but version 4.8.2 (trusty)
  yields weird results from indirect functions that return a floating-
  point value.

  Calling the function directly, yields the expected result.

  As an example (complete code attached), these functions would stand for the hard fp ABI:
  ---------
  struct Test {
    __attribute__((pcs("aapcs-vfp"))) float (*f) ();
  };

  __attribute__((pcs("aapcs-vfp"))) float f();

  const struct Test* GetTest();
  ---------

  Using these wrappers for the softfp:
  ---------
  float wrapper() {
    return GetTest()->f();
  }

  float wrapper_correct() {
    return f();
  }
  ---------

  The first one, that calls the function indirectly, yields incorrect assembler (dissasembly from wrapper.a):
  00000000 <_Z7wrapperv>:
    0:   e52d4008        str     r4, [sp, #-8]!
    4:   e58de004        str     lr, [sp, #4]
    8:   ebfffffe        bl      0 <GetTest>
    c:   e5903000        ldr     r3, [r0]
   10:   e59d4000        ldr     r4, [sp]
   14:   e59de004        ldr     lr, [sp, #4]
   18:   e28dd008        add     sp, sp, #8
   1c:   e12fff13        bx      r3      // not populating r0

  While the second one yields correct assembler:
  00000020 <_Z15wrapper_correctv>:
   20:   e52d4008        str     r4, [sp, #-8]!
   24:   e58de004        str     lr, [sp, #4]
   28:   ebfffffe        bl      0 <f>
   2c:   e59d4000        ldr     r4, [sp]
   30:   e28dd004        add     sp, sp, #4
   34:   ee100a10        vmov    r0, s0      // populating r0
   38:   e49df004        pop     {pc}            ; (ldr pc, [sp], #4)

  For comparison, these are the dissasemblies of both functions when compiled with 4.6.3 (precise):
  00000000 <_Z7wrapperv>:
    0:   e92d4008        push    {r3, lr}
    4:   ebfffffe        bl      0 <GetTest>
    8:   e5903000        ldr     r3, [r0]
    c:   e12fff33        blx     r3
   10:   ee100a10        vmov    r0, s0
   14:   e8bd8008        pop     {r3, pc}

  00000018 <_Z15wrapper_correctv>:
   18:   e92d4008        push    {r3, lr}
   1c:   ebfffffe        bl      0 <f>
   20:   ee100a10        vmov    r0, s0
   24:   e8bd8008        pop     {r3, pc}

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8-armhf-cross/+bug/1347637/+subscriptions