------- Comment #4 from danglin at gcc dot gnu dot org 2007-09-16 00:21 -------
Sorry, comment #3 is wrong.
This change was introduced by the additions to builtins-20.c for the
carg(z) -> atan2(z.i, z.r). There we have:
+static tree
+fold_builtin_carg(tree arglist, tree type)
+{
+ if (validate_arglist (arglist, COMPLEX_TYPE, VOID_TYPE))
+ {
+ tree atan2_fn = mathfn_built_in (type, BUILT_IN_ATAN2);
+
+ if (atan2_fn)
+ {
+ tree arg = builtin_save_expr (TREE_VALUE (arglist));
+ tree r_arg = fold_build1 (REALPART_EXPR, type, arg);
+ tree i_arg = fold_build1 (IMAGPART_EXPR, type, arg);
+ tree newarglist = tree_cons (NULL_TREE, i_arg,
+ build_tree_list (NULL_TREE, r_arg));
+ return build_function_call_expr (atan2_fn, newarglist);
+ }
+ }
+
+ return NULL_TREE;
+}
PA-RISC HP-UX has atan2 and atan2f, but not atan2l. We have in
builtins.def:
DEF_C99_C90RES_BUILTIN (BUILT_IN_ATAN2F, "atan2f", BT_FN_FLOAT_FLOAT_FLOAT,
ATTR
_MATHFN_FPROUNDING_ERRNO)
and
/* Builtin that is specified by C99 and C90 reserve the name for future use.
We can still recognize the builtin in C90 mode but we can't produce it
implicitly. */
#undef DEF_C99_C90RES_BUILTIN
#define DEF_C99_C90RES_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE, \
true, true, !flag_isoc99, ATTRS, TARGET_C99_FUNCTIONS, true)
Think we need to do something about atan2f in the backend. However,
we don't have atan2l, so the test will have to be xfailed...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496
