[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

2009-01-15 Thread sje at cup dot hp dot com 


--- Comment #6 from sje at cup dot hp dot com  2009-01-15 22:58 ---
It looks like this test is passing since the test was changed to include
the #ifdef HAVE_C99_RUNTIME.  It looks OK on the 4.3 branch and trunk so
I think we can close it.  Any objections?


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

2009-01-15 Thread dave at hiauly1 dot hia dot nrc dot ca 


--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2009-01-15 
23:40 ---
Subject: Re:  FAIL: gcc.dg/builtins-20.c (test for excess errors)

 I think we can close it.  Any objections?

No.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

2009-01-15 Thread sje at cup dot hp dot com 


--- Comment #8 from sje at cup dot hp dot com  2009-01-15 23:45 ---
Fixed with change to test.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

2007-09-15 Thread danglin at gcc dot gnu dot org 


--- Comment #3 from danglin at gcc dot gnu dot org  2007-09-15 23:12 ---
I believe that this test started failing when mode cases were added
in the Handle CONJ_EXPR in negate_expr_p and fold_negate_expr.  Test
doesn't fail on linux, so this has something to do with missing C99
functions. 


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at caip dot rutgers
   ||dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

2007-09-15 Thread danglin at gcc dot gnu dot org 


--- 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

[Bug tree-optimization/31496] FAIL: gcc.dg/builtins-20.c (test for excess errors)

2007-09-15 Thread danglin at gcc dot gnu dot org 


--- Comment #5 from danglin at gcc dot gnu dot org  2007-09-16 02:03 ---
There doesn't seem to be any difference between the definitions
for DEF_C99_BUILTIN and DEF_C99_C90RES_BUILTIN.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31496