public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
@ 2012-01-16 10:15 amker.cheng at gmail dot com
2012-01-16 10:19 ` [Bug middle-end/51867] " amker.cheng at gmail dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: amker.cheng at gmail dot com @ 2012-01-16 10:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
@ 2012-01-16 10:19 ` amker.cheng at gmail dot com
2012-01-16 14:45 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: amker.cheng at gmail dot com @ 2012-01-16 10:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867
--- Comment #1 from amker.cheng <amker.cheng at gmail dot com> 2012-01-16 10:15:59 UTC ---
The cause is in function expand_builtin, gcc checks following conditions:
----------------------------------------------
/* When not optimizing, generate calls to library functions for a certain
set of builtins. */
if (!optimize
&& !called_as_built_in (fndecl)
&& DECL_ASSEMBLER_NAME_SET_P (fndecl)
&& fcode != BUILT_IN_ALLOCA
&& fcode != BUILT_IN_ALLOCA_WITH_ALIGN
&& fcode != BUILT_IN_FREE)
return expand_call (exp, target, ignore);
The control flow is:
1, DECL_ASSEMBLER_NAME_SET_P (fndecl) is false at the first time when compiling
a;
2, It is then set in following codes when expanding sqrtf call in function a;
3, When compiling function b, gcc checks DECL_ASSEMBLER_NAME_SET_P (fndecl)
again and this time it's true;
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
2012-01-16 10:19 ` [Bug middle-end/51867] " amker.cheng at gmail dot com
@ 2012-01-16 14:45 ` rguenth at gcc dot gnu.org
2012-01-17 10:43 ` amker.cheng at gmail dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-16 14:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-01-16
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-16 14:33:58 UTC ---
Confirmed. That check is definitely bogus.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
2012-01-16 10:19 ` [Bug middle-end/51867] " amker.cheng at gmail dot com
2012-01-16 14:45 ` rguenth at gcc dot gnu.org
@ 2012-01-17 10:43 ` amker.cheng at gmail dot com
2012-02-09 9:38 ` amker at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: amker.cheng at gmail dot com @ 2012-01-17 10:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867
--- Comment #3 from amker.cheng <amker.cheng at gmail dot com> 2012-01-17 10:35:14 UTC ---
test case c-c++-common/dfp/signbit-2.c depends on this check.
the case is like:
---------------------------------------------------------------------
/* { dg-options "-O0" } */
/* Check that the compiler uses builtins for signbit; if not the link
will fail because library functions are in libm. */
#include "dfp-dbg.h"
volatile _Decimal32 sd = 2.3df;
volatile _Decimal64 dd = -4.5dd;
volatile _Decimal128 tf = 5.3dl;
volatile float f = 1.2f;
volatile double d = -7.8;
volatile long double ld = 3.4L;
EXTERN int signbitf (float);
EXTERN int signbit (double);
EXTERN int signbitl (long double);
EXTERN int signbitd32 (_Decimal32);
EXTERN int signbitd64 (_Decimal64);
EXTERN int signbitd128 (_Decimal128);
int
main ()
{
if (signbitf (f) != 0) FAILURE
if (signbit (d) == 0) FAILURE
if (signbitl (ld) != 0) FAILURE
if (signbitd32 (sd) != 0) FAILURE
if (signbitd64 (dd) == 0) FAILURE
if (signbitd128 (tf) != 0) FAILURE
FINISH
}
It is compiled without optimization and will fail if no builtin_* functions are
used.
Not sure it is intended or not.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
` (2 preceding siblings ...)
2012-01-17 10:43 ` amker.cheng at gmail dot com
@ 2012-02-09 9:38 ` amker at gcc dot gnu.org
2012-06-18 2:03 ` amker.cheng at gmail dot com
2022-01-06 3:42 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: amker at gcc dot gnu.org @ 2012-02-09 9:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867
--- Comment #4 from amker at gcc dot gnu.org 2012-02-09 09:37:43 UTC ---
Author: amker
Date: Thu Feb 9 09:37:37 2012
New Revision: 184037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184037
Log:
PR target/51867
* builtins.c (expand_builtin): Don't check DECL_ASSEMBLER_NAME_SET_P.
PR target/51867
* testsuite/c-c++-common/dfp/signbit-2.c: Change '-O0' to '-O1'.
* testsuite/gcc.dg/pr51867.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/pr51867.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/dfp/signbit-2.c
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
` (3 preceding siblings ...)
2012-02-09 9:38 ` amker at gcc dot gnu.org
@ 2012-06-18 2:03 ` amker.cheng at gmail dot com
2022-01-06 3:42 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: amker.cheng at gmail dot com @ 2012-06-18 2:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867
--- Comment #5 from amker.cheng <amker.cheng at gmail dot com> 2012-06-18 02:03:21 UTC ---
Should be fixed.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
` (4 preceding siblings ...)
2012-06-18 2:03 ` amker.cheng at gmail dot com
@ 2022-01-06 3:42 ` pinskia at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-06 3:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Keywords| |missed-optimization
Resolution|--- |FIXED
Target Milestone|--- |4.7.0
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-01-06 3:42 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-16 10:15 [Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf amker.cheng at gmail dot com
2012-01-16 10:19 ` [Bug middle-end/51867] " amker.cheng at gmail dot com
2012-01-16 14:45 ` rguenth at gcc dot gnu.org
2012-01-17 10:43 ` amker.cheng at gmail dot com
2012-02-09 9:38 ` amker at gcc dot gnu.org
2012-06-18 2:03 ` amker.cheng at gmail dot com
2022-01-06 3:42 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).