[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #17 from ubizjak at gmail dot com 2007-03-17 09:45 --- (In reply to comment #16) As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks Richard for your patience. I have just noticed the following oddity with the code: [karma] bug/cexp_pb% g++-4 -O1 failure_v6.c failure_v6.c: In function 'int main()': failure_v6.c:4: warning: canonical types differ for identical types double __complex__ and double __complex__ complex_type 0x9958c0 type real_type 0x42e238c0 double sizes-gimplified DF This is PR middle-end/30666. Patch for this problem is waiting for review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-17 12:29 --- Subject: Re: __builtin_cexpi is broken on Darwin This is PR middle-end/30666. Patch for this problem is waiting for review. Thanks for the answer. I did not worried about the warn, but was only in the mode I report what I don't expect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-16 09:27 --- Darwin people. Or at least someone with enough knowledge of ppc asm... Do they exist? If yes, are some living on planet earth? If yes, how do you catch them (at least their attention!-)? Fixed. (The ICE, the wrong-code is tracked by the other PR) I have applied the patch, now the code given in the first post yields: -1 1.22465e-16 6.12323e-17 1 i.e., cexpi returns a wrong answer (first line) when compiled with gcc (so from a practical point of view the fix is worse than the original error unless it breaks enough c codes to make more people to look at the problem). Now I have a question that will show how ignorant I am: what fallback does exactly? If it is just a remapping of cexpi to cexp, then I think it is wrong. If I am not mistaken, cexpi takes real argument x and returns a complex result (cos(x), sin(x)), while cexp takes a complex argument z and returns a complex result exp(real(z))*(cos(imag(z)),sin(imag(z))), so the correct definition of cexpi should be: cexpi(x)=cexp(complex(0,x)) Is this correct? If yes what should be done to implement this behavior? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-16 09:50 --- Yes, it's supposed to call cexp(complex(0,x)), but now looking at the code there seems to be a typo: narg = fold_build2 (COMPLEX_EXPR, ctype, build_real (type, dconst0), arg); /* Make sure not to fold the cexp call again. */ call = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (fn)), fn); return expand_expr (build_call_nary (ctype, call, 1, arg), target, VOIDmode, 0); it builds the call with 'arg' instead of 'narg'. Argh. This bug was introduced by the CALL_EXPR changes: narg = fold_build2 (COMPLEX_EXPR, ctype, build_real (type, dconst0), arg); /* Make sure not to fold the cexp call again. */ call = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (fn)), fn); - return expand_expr (build3 (CALL_EXPR, ctype, call, - build_tree_list (NULL_TREE, narg), - NULL_TREE), target, VOIDmode, 0); + return expand_expr (build_call_nary (ctype, call, 1, arg), + target, VOIDmode, 0); I'll fix it in a second. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-16 14:43 --- This bug was introduced by the CALL_EXPR changes: Good catch! Can you date the bug, i.e., was it introduced between snapshots 20070216 and 20070223? Thanks for the work. i'ld just like to see the darwin people as helpful! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-17 00:22 ---
As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks
Richard for your
patience.
I have just noticed the following oddity with the code:
#include math.h
#include stdio.h
int main()
{
__complex__ double x;
__real__ x = -1.0;
__imag__ x = 0.0;
__complex__ double t = __builtin_clog(x);
double tmp = 0.5 * (__imag__ t);
printf(%g %g\n, cos(tmp), sin(tmp));
x = __builtin_cexpi(tmp);
printf(%g %g\n, (__real__ x), (__imag__ x));
x = __builtin_cexpi(tmp);
printf(%g %g\n, (__real__ x), (__imag__ x));
tmp = 0.5 * tmp;
x = __builtin_cexpi(tmp);
printf(%g %g\n, (__real__ x), (__imag__ x));
tmp = 0.0;
x = __builtin_cexpi(tmp);
printf(%g %g\n, (__real__ x), (__imag__ x));
}
leads to:
[karma] bug/cexp_pb% g++-4 -O1 failure_v6.c
failure_v6.c: In function 'int main()':
failure_v6.c:4: warning: canonical types differ for identical types double
__complex__ and double __complex__
complex_type 0x9958c0
type real_type 0x42e238c0 double sizes-gimplified DF
size integer_cst 0x42e0a740 constant invariant 64
unit size integer_cst 0x42e0a760 constant invariant 8
align 64 symtab 0 alias set -1 canonical type 0x42e238c0 precision 64
pointer_to_this pointer_type 0x42e23a10
DC
size integer_cst 0x42e0a860 type integer_type 0x42e1d070 bit_size_type
constant invariant 128
unit size integer_cst 0x42e0a880 type integer_type 0x42e1d000 long
unsigned int constant invariant 16
align 64 symtab 0 alias set -1 canonical type 0x9958c0
complex_type 0x42e26000 complex double
type real_type 0x42e238c0 double sizes-gimplified DF
size integer_cst 0x42e0a740 constant invariant 64
unit size integer_cst 0x42e0a760 constant invariant 8
align 64 symtab 0 alias set -1 canonical type 0x42e238c0 precision 64
pointer_to_this pointer_type 0x42e23a10
sizes-gimplified DC
size integer_cst 0x42e0a860 type integer_type 0x42e1d070 bit_size_type
constant invariant 128
unit size integer_cst 0x42e0a880 type integer_type 0x42e1d000 long
unsigned int constant invariant 16
align 64 symtab 0 alias set -1 canonical type 0x42e26000
failure_v6.c:4: warning: canonical types differ for identical types double
__complex__ and double __complex__
complex_type 0x9958c0
type real_type 0x42e238c0 double sizes-gimplified DF
size integer_cst 0x42e0a740 constant invariant 64
unit size integer_cst 0x42e0a760 constant invariant 8
align 64 symtab 0 alias set -1 canonical type 0x42e238c0 precision 64
pointer_to_this pointer_type 0x42e23a10
DC
size integer_cst 0x42e0a860 type integer_type 0x42e1d070 bit_size_type
constant invariant 128
unit size integer_cst 0x42e0a880 type integer_type 0x42e1d000 long
unsigned int constant invariant 16
align 64 symtab 0 alias set -1 canonical type 0x9958c0
complex_type 0x42e26000 complex double
type real_type 0x42e238c0 double sizes-gimplified DF
size integer_cst 0x42e0a740 constant invariant 64
unit size integer_cst 0x42e0a760 constant invariant 8
align 64 symtab 0 alias set -1 canonical type 0x42e238c0 precision 64
pointer_to_this pointer_type 0x42e23a10
sizes-gimplified DC
size integer_cst 0x42e0a860 type integer_type 0x42e1d070 bit_size_type
constant invariant 128
unit size integer_cst 0x42e0a880 type integer_type 0x42e1d000 long
unsigned int constant invariant 16
align 64 symtab 0 alias set -1 canonical type 0x42e26000
without -O1, I don't get the warnings, nor with similar codes (as the ones in
comments), nor
with gcc. The executable works as expected. Any idea?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-15 08:34 ---
Can you check if the attached patch gives a more reasonable error?
I now get:
failure_v2.c: In function 'main':
failure_v2.c:15: sorry, unimplemented: no way to expand a call to 'cexpi'
but would not it be more natural to get the behavior I see with gcc version
4.2.0 20070221?
/usr/bin/ld: Undefined symbols:
___builtin_cexpi
collect2: ld returned 1 exit status
Now from this, am I right to conclude that TARGET_C99_FUNCTIONS is not set in
my build?
If yes, how does it come that g++ and gfortran use __builtin_cexpi when a code
use
cos(phi) and sin(phi) with -O1:
;; Function int main() (main)
Analyzing Edge Insertions.
int main() ()
{
complex double sincostmp.18;
bb 2:
sincostmp.18 = __builtin_cexpi (IMAGPART_EXPR __builtin_clog (__complex__
(-1.0e+0, 0.0)) * 5.0e-1);
printf (%g %g\n[0], REALPART_EXPR sincostmp.18, IMAGPART_EXPR
sincostmp.18);
return 0;
}
where __builtin_cexpi seems to be used and returning a wrong result, thus
leading to PR30980?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-15 09:40 ---
Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a function
call to cexp would be more natural...
The Problem with Fortran and C++ is that they assume a C99 runtime and so they
effectively set TARGET_C99_FUNCTIONS and provide fallback implementations. For
example libgfortran contains
#if !defined(HAVE_CEXP)
#define HAVE_CEXP 1
double complex
cexp (double complex z)
{
double a, b;
double complex v;
a = REALPART (z);
b = IMAGPART (z);
COMPLEX_ASSIGN (v, cos (b), sin (b));
return exp (a) * v;
}
#endif
and C++ simply relies on the target cexp() functioning correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 10:11 --- Subject: Re: __builtin_cexpi is broken on Darwin Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a function call to cexp would be more natural... I agree (see below). The Problem with Fortran and C++ is that they assume a C99 runtime and so they effectively set TARGET_C99_FUNCTIONS and provide fallback implementations. For example libgfortran contains ... and C++ simply relies on the target cexp() functioning correctly. As far as I can tell this assumption is correct (see my comment #2), so why the fallback not working properly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-15 10:40 --- I have no idea why it is not working properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-15 11:33 --- Subject: Re: __builtin_cexpi is broken on Darwin I have no idea why it is not working properly. Who could? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-15 11:37 --- Darwin people. Or at least someone with enough knowledge of ppc asm... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-15 20:15 --- Subject: Bug 31161 Author: rguenth Date: Thu Mar 15 20:14:49 2007 New Revision: 122958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122958 Log: 2007-03-15 Richard Guenther [EMAIL PROTECTED] PR middle-end/29719 PR middle-end/31161 * builtins.c (expand_builtin_int_roundingfn): Always fall back to floor/ceil and its variants even if they may be not available. (expand_builtin_cexpi): As a fallback if we don't have builtins for sincos or cexp create a function declaration for cexp and expand to a call to that. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-15 20:17 --- Fixed. (The ICE, the wrong-code is tracked by the other PR) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-13 10:30 --- It's a target issue. Darwin is broken that it doesn't set TARGET_C99_FUNCTIONS but still appears to have cexp. Your testcase is also invalid for this reason, you should not use __builtin_cexpi if neither sincos nor cexp is available. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-13 10:58 ---
Subject: Re: __builtin_cexpi is broken on Darwin
you should not use __builtin_cexpi if neither sincos nor cexp is available.
Yes indeed, but an ICE is certainly not the best way to say it!
Now I have tested __builtin_cexpi, not because I want to use it, but because
it is used by the optimizer with a wrong result I would like to see fixed
ASAP.
Note that __builtin_cexp is available on Darwin and seems to work:
#include math.h
#include stdio.h
int main()
{
__complex__ double x;
__real__ x = -1.0;
__imag__ x = 0.0;
__complex__ double t = __builtin_clog(x);
double tmp = 0.5 * (__imag__ t);
x = __builtin_cexp(0.5*t);
printf(%g %g\n, (__real__ x), (__imag__ x));
printf(%g %g\n, cos(tmp), sin(tmp));
}
gives with gcc and with or without optimization:
6.12323e-17 1
6.12323e-17 1
while when compiled with g++ -O1, it gives:
6.12323e-17 1
-1 1.22465e-16
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-13 13:39 --- Created an attachment (id=13199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13199action=view) patch for a better error Can you check if the attached patch gives a more reasonable error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-13 13:53 --- With a cross compiler to powerpc-apple-darwin7 I now get for the testcase: gcc ./cc1 -quiet t.i t.i: In function 'main': t.i:13: warning: incompatible implicit declaration of built-in function 'printf' t.i:12: sorry, unimplemented: no way to expand a call to 'cexpi' no idea if that's better ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
