http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-16
14:25:12 UTC ---
Hum. We generate calls to sincos() if TARGET_HAS_SINCOS is true and a call
to cexp() if TARGET_C99_FUNCTIONS is true. We do so in two steps. First
we generate a call to a GCC internal builtin cexpi () which is a complex
exponentation with just an imaginary argument. Then during expansion we
expand that to either sincos() or cexp(). If you look at
expand_builtin_cexpi then it is obvious that we'd ICE if TARGET_HAS_SINCOS
is true but the sincos builtin is not available. Thus I conclude that
the sincos builtin is available when it really is should not be (with -ansi),
which makes this a C frontend bug(?). It would of course start to ICE
if TARGET_HAS_SINCOS is true but the builtin isn't there, but that's another
issue.
Thus, I'm not sure how the frontend communicates -ansi effects to the
middle-end.
We have:
DEF_EXT_LIB_BUILTIN (BUILT_IN_SINCOS, "sincos",
BT_FN_VOID_DOUBLE_DOUBLEPTR_DOUBLEPTR, ATTR_MATHFN_FPROUNDING_STORE)
but built_in_decls has a decl for it.
