[Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf

["amker.cheng at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

             Bug #: 51867
           Summary: GCC generates inconsistent code for same sources
                    calling builtin calls, like sqrtf
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: amker.cheng@gmail.com


compile following program:
----------------------------------------------
#include <math.h>
int a(float x) {
     return sqrtf(x);
}
int b(float x) {
     return sqrtf(x);
}

With command:
arm-none-eabi-gcc -mthumb -mhard-float -mfpu=fpv4-sp-d16
-mcpu=cortex-m4 -O0 -S a.c -o a.S

The generated assembly codes is like:
----------------------------------------------
a:
       @ args = 0, pretend = 0, frame = 8
       @ frame_needed = 1, uses_anonymous_args = 0
       push    {r7, lr}
       sub     sp, sp, #8
       add     r7, sp, #0
       fsts    s0, [r7, #4]
       flds    s15, [r7, #4]
       fsqrts  s15, s15
       fcmps   s15, s15
       fmstat
       beq     .L2
       flds    s0, [r7, #4]
       bl      sqrtf
       fcpys   s15, s0
.L2:
       ftosizs s15, s15
       fmrs    r3, s15 @ int
       mov     r0, r3
       add     r7, r7, #8
       mov     sp, r7
       pop     {r7, pc}
       .size   a, .-a
       .align  2
       .global b
       .thumb
       .thumb_func
       .type   b, %function
b:
       @ args = 0, pretend = 0, frame = 8
       @ frame_needed = 1, uses_anonymous_args = 0
       push    {r7, lr}
       sub     sp, sp, #8
       add     r7, sp, #0
       fsts    s0, [r7, #4]
       flds    s0, [r7, #4]
       bl      sqrtf
       fcpys   s15, s0
       ftosizs s15, s15
       fmrs    r3, s15 @ int
       mov     r0, r3
       add     r7, r7, #8
       mov     sp, r7
       pop     {r7, pc}
       .size   b, .-b

The problem exists on trunk and triggered only by O0 optimization.
The problem stands for x86 target too.