[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.