--- 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
--- 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
--- 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
--- 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);
--- 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
--- 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()
{
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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?
--
--- 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:
18 matches
Mail list logo
