* [PATCH]: Add some more builtins opts for sqrt/cbrt
@ 2004-03-12 14:36 Kaveh R. Ghazi
2004-03-19 8:14 ` Kaveh R. Ghazi
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-12 14:36 UTC (permalink / raw)
To: gcc-patches
This patch adds a few more builtin optimizations for sqrt and cbrt.
The new transformations are:
sqrt(Nroot(x)) -> pow(x,1/(2*N)) (where Nroot is either sqrt or cbrt)
cbrt(N) -> N (for N == {0,1,-1})
cbrt(expN(x)) -> expN(x/3)
cbrt(sqrt(x)) -> pow(x,1/6)
cbrt(x)*cbrt(y) -> cbrt(x*y)
I didn't do cbrt(cbrt(x)), cbrt(pow(x,y)) and pow(cbrt(x),y) into
plain pow because I believe all of these would succeed with innocuous
negative values of x but might fail if tranformed into just pow. I'll
do these later by checking if x is nonnegative or y is a multiple of
three.
Tested on sparc-sun-solaris2.7, no regressions and the new cases pass.
Ok for mainline?
Thanks,
--Kaveh
2004-03-12 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* builtins.c (fold_builtin): Add new builtin optimizations for
sqrt and/or cbrt.
* fold-const.c (fold): Likewise.
testsuite:
* gcc.dg/torture/builtin-explog-1.c: Add new cases.
* gcc.dg/torture/builtin-math-1.c: Likewise.
* builtin-power-1.c: New test.
diff -rup orig/egcc-CVS20040310/gcc/builtins.c egcc-CVS20040310/gcc/builtins.c
--- orig/egcc-CVS20040310/gcc/builtins.c 2004-03-10 20:02:07.000000000 -0500
+++ egcc-CVS20040310/gcc/builtins.c 2004-03-11 18:03:17.721038000 -0500
@@ -6748,6 +6748,29 @@ fold_builtin (tree exp)
return build_function_call_expr (expfn, arglist);
}
+ /* Optimize sqrt(Nroot(x)) -> pow(x,1/(2*N)). */
+ if (flag_unsafe_math_optimizations && BUILTIN_ROOT_P (fcode))
+ {
+ tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+
+ if (powfn)
+ {
+ tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+ tree tree_root;
+ /* The inner root was either sqrt or cbrt. */
+ REAL_VALUE_TYPE dconstroot =
+ BUILTIN_SQRT_P (fcode) ? dconsthalf : dconstthird;
+
+ /* Adjust for the outer root. */
+ dconstroot.exp--;
+ dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+ tree_root = build_real (type, dconstroot);
+ arglist = tree_cons (NULL_TREE, arg0,
+ build_tree_list (NULL_TREE, tree_root));
+ return build_function_call_expr (powfn, arglist);
+ }
+ }
+
/* Optimize sqrt(pow(x,y)) = pow(x,y*0.5). */
if (flag_unsafe_math_optimizations
&& (fcode == BUILT_IN_POW
@@ -6766,6 +6789,56 @@ fold_builtin (tree exp)
}
break;
+ case BUILT_IN_CBRT:
+ case BUILT_IN_CBRTF:
+ case BUILT_IN_CBRTL:
+ if (validate_arglist (arglist, REAL_TYPE, VOID_TYPE))
+ {
+ tree arg = TREE_VALUE (arglist);
+ const enum built_in_function fcode = builtin_mathfn_code (arg);
+
+ /* Optimize cbrt of constant value. */
+ if (real_zerop (arg) || real_onep (arg) || real_minus_onep (arg))
+ return arg;
+
+ /* Optimize cbrt(expN(x)) -> expN(x/3). */
+ if (flag_unsafe_math_optimizations && BUILTIN_EXPONENT_P (fcode))
+ {
+ tree expfn = TREE_OPERAND (TREE_OPERAND (arg, 0), 0);
+ const REAL_VALUE_TYPE third_trunc =
+ real_value_truncate (TYPE_MODE (type), dconstthird);
+ arg = fold (build (MULT_EXPR, type,
+ TREE_VALUE (TREE_OPERAND (arg, 1)),
+ build_real (type, third_trunc)));
+ arglist = build_tree_list (NULL_TREE, arg);
+ return build_function_call_expr (expfn, arglist);
+ }
+
+ /* Optimize cbrt(sqrt(x)) -> pow(x,1/6). */
+ /* We don't optimize cbrt(cbrt(x)) -> pow(x,1/9) because if
+ x is negative pow will error but cbrt won't. */
+ if (flag_unsafe_math_optimizations && BUILTIN_SQRT_P (fcode))
+ {
+ tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+
+ if (powfn)
+ {
+ tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+ tree tree_root;
+ REAL_VALUE_TYPE dconstroot = dconstthird;
+
+ dconstroot.exp--;
+ dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+ tree_root = build_real (type, dconstroot);
+ arglist = tree_cons (NULL_TREE, arg0,
+ build_tree_list (NULL_TREE, tree_root));
+ return build_function_call_expr (powfn, arglist);
+ }
+
+ }
+ }
+ break;
+
case BUILT_IN_SIN:
case BUILT_IN_SINF:
case BUILT_IN_SINL:
diff -rup orig/egcc-CVS20040310/gcc/fold-const.c egcc-CVS20040310/gcc/fold-const.c
--- orig/egcc-CVS20040310/gcc/fold-const.c 2004-03-10 13:13:01.000000000 -0500
+++ egcc-CVS20040310/gcc/fold-const.c 2004-03-11 13:17:27.744332000 -0500
@@ -6422,23 +6422,24 @@ fold (tree expr)
enum built_in_function fcode0 = builtin_mathfn_code (arg0);
enum built_in_function fcode1 = builtin_mathfn_code (arg1);
- /* Optimizations of sqrt(...)*sqrt(...). */
- if (fcode0 == fcode1 && BUILTIN_SQRT_P (fcode0))
+ /* Optimizations of root(...)*root(...). */
+ if (fcode0 == fcode1 && BUILTIN_ROOT_P (fcode0))
{
- tree sqrtfn, arg, arglist;
+ tree rootfn, arg, arglist;
tree arg00 = TREE_VALUE (TREE_OPERAND (arg0, 1));
tree arg10 = TREE_VALUE (TREE_OPERAND (arg1, 1));
/* Optimize sqrt(x)*sqrt(x) as x. */
- if (operand_equal_p (arg00, arg10, 0)
+ if (BUILTIN_SQRT_P (fcode0)
+ && operand_equal_p (arg00, arg10, 0)
&& ! HONOR_SNANS (TYPE_MODE (type)))
return arg00;
- /* Optimize sqrt(x)*sqrt(y) as sqrt(x*y). */
- sqrtfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
+ /* Optimize root(x)*root(y) as root(x*y). */
+ rootfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
arg = fold (build (MULT_EXPR, type, arg00, arg10));
arglist = build_tree_list (NULL_TREE, arg);
- return build_function_call_expr (sqrtfn, arglist);
+ return build_function_call_expr (rootfn, arglist);
}
/* Optimize expN(x)*expN(y) as expN(x+y). */
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c 2004-03-06 12:53:57.000000000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c 2004-03-11 18:56:30.834742000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2003 Free Software Foundation.
+/* Copyright (C) 2003, 2004 Free Software Foundation.
Verify that built-in math function constant folding of log & exp is
correctly performed by the compiler.
@@ -119,6 +119,17 @@ void test(double d1, double d2, float f1
LOG_CBRT(log2);
LOG_CBRT(log10);
+ /* Test cbrt(expN(x)) -> expN(x/3). */
+#define CBRT_EXP(EXP) \
+ extern void link_failure_cbrt_##EXP(void); \
+ if (cbrt(EXP(d1)) != EXP(d1/3.0) || cbrtf(EXP##f(f1)) != EXP##f(f1/3.0F) \
+ || cbrtl(EXP##l(ld1)) != EXP##l(ld1/3.0L)) link_failure_cbrt_##EXP()
+
+ CBRT_EXP(exp);
+ CBRT_EXP(exp2);
+ CBRT_EXP(exp10);
+ CBRT_EXP(pow10);
+
/* Test logN(pow(x,y)) -> y*logN(x). */
#define LOG_POW(LOG, POW) \
extern void link_failure_##LOG##_##POW(void); \
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c 2003-08-02 15:09:54.000000000 -0400
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c 2004-03-11 18:56:25.215208000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2002, 2003 Free Software Foundation.
+/* Copyright (C) 2002, 2003, 2004 Free Software Foundation.
Verify that built-in math function constant folding of constant
arguments is correctly performed by the compiler.
@@ -18,6 +18,15 @@ void test (float f, double d, long doubl
if (sqrt (1.0) != 1.0)
link_error ();
+ if (cbrt (0.0) != 0.0)
+ link_error ();
+
+ if (cbrt (1.0) != 1.0)
+ link_error ();
+
+ if (cbrt (-1.0) != -1.0)
+ link_error ();
+
if (exp (0.0) != 1.0)
link_error ();
@@ -55,6 +64,15 @@ void test (float f, double d, long doubl
if (sqrtf (1.0F) != 1.0F)
link_error ();
+ if (cbrtf (0.0F) != 0.0F)
+ link_error ();
+
+ if (cbrtf (1.0F) != 1.0F)
+ link_error ();
+
+ if (cbrtf (-1.0F) != -1.0F)
+ link_error ();
+
if (expf (0.0F) != 1.0F)
link_error ();
@@ -92,6 +110,15 @@ void test (float f, double d, long doubl
if (sqrtl (1.0L) != 1.0L)
link_error ();
+ if (cbrtl (0.0L) != 0.0L)
+ link_error ();
+
+ if (cbrtl (1.0L) != 1.0L)
+ link_error ();
+
+ if (cbrtl (-1.0L) != -1.0L)
+ link_error ();
+
if (expl (0.0L) != 1.0L)
link_error ();
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c 2004-03-11 18:14:10.341709000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c 2004-03-11 18:56:03.906846000 -0500
@@ -0,0 +1,105 @@
+/* Copyright (C) 2004 Free Software Foundation.
+
+ Verify that built-in folding of various math "power" functions is
+ correctly performed by the compiler.
+
+ Written by Kaveh Ghazi, 2004-03-11. */
+
+/* { dg-do link } */
+/* { dg-options "-ffast-math" } */
+
+#include "../builtins-config.h"
+
+#ifdef HAVE_C99_RUNTIME
+#define C99CODE(CODE) CODE
+#else
+#define C99CODE(CODE) 0
+#endif
+
+#define PROTOTYPE(FN) extern double FN(double); extern float FN##f(float); \
+ extern long double FN##l(long double);
+#define PROTOTYPE2(FN) extern double FN(double, double); \
+ extern float FN##f(float, float); \
+ extern long double FN##l(long double, long double);
+
+PROTOTYPE(sqrt)
+PROTOTYPE(cbrt)
+PROTOTYPE2(pow)
+
+void test(double d1, double d2, double d3,
+ float f1, float f2, float f3,
+ long double ld1, long double ld2, long double ld3)
+{
+ /* Test N1root(N2root(x)) -> pow(x,1/(N1*N2)). */
+ /* E.g. sqrt(cbrt(x)) -> pow(x,1/6). */
+#define ROOT_ROOT(FN1,N1,FN2,N2) \
+ extern void link_failure_##FN1##_##FN2(void); \
+ if (FN1(FN2(d1)) != pow(d1,1.0/(N1*N2)) \
+ || C99CODE (FN1##f(FN2##f(f1)) != powf(f1,1.0F/(N1*N2))) \
+ || C99CODE (FN1##l(FN2##l(ld1)) != powl(ld1,1.0L/(N1*N2)))) \
+ link_failure_##FN1##_##FN2()
+
+ ROOT_ROOT(sqrt,2,sqrt,2);
+ ROOT_ROOT(sqrt,2,cbrt,3);
+ ROOT_ROOT(cbrt,3,sqrt,2);
+ /*ROOT_ROOT(cbrt,3,cbrt,3); Intentionally not implemented. */
+
+ /* Test pow(Nroot(x),y) -> pow(x,y/N). */
+#define POW_ROOT(FN,N) \
+ extern void link_failure_pow_##FN(void); \
+ if (pow(FN(d1), d2) != pow(d1,d2/N) \
+ || powf(FN##f(f1),f2) != powf(f1,f2/N) \
+ || powl(FN##l(ld1),ld2) != powl(ld1,ld2/N)) \
+ link_failure_pow_##FN()
+
+ POW_ROOT(sqrt,2);
+ /*POW_ROOT(cbrt,3); Intentionally not implemented. */
+
+ /* Test Nroot(pow(x,y)) -> pow(x,y/N). */
+#define ROOT_POW(FN,N) \
+ extern void link_failure_##FN##_pow(void); \
+ if (FN(pow(d1, d2)) != pow(d1,d2/N) \
+ || FN##f(powf(f1,f2)) != powf(f1,f2/N) \
+ || FN##l(powl(ld1,ld2)) != powl(ld1,ld2/N)) \
+ link_failure_##FN##_pow()
+
+ ROOT_POW(sqrt,2);
+ /*ROOT_POW(cbrt,3); Intentionally not implemented. */
+
+ /* Test pow(pow(x,y),z) -> pow(x,y*z). */
+#define POW_POW \
+ extern void link_failure_pow_pow(void); \
+ if (pow(pow(d1, d2), d3) != pow(d1,d2*d3) \
+ || powf(powf(f1,f2),f3) != powf(f1,f2*f3) \
+ || powl(powl(ld1,ld2),ld3) != powl(ld1,ld2*ld3)) \
+ link_failure_pow_pow()
+
+ POW_POW;
+
+ /* Test Nroot(x)*Nroot(y) -> Nroot(x*y). */
+#define ROOT_X_ROOT(FN) \
+ extern void link_failure_root_x_root(void); \
+ if (FN(d1)*FN(d2) != FN(d1*d2) \
+ || FN##f(f1)*FN##f(f2) != FN##f(f1*f2) \
+ || FN##l(ld1)*FN##l(ld2) != FN##l(ld1*ld2)) \
+ link_failure_root_x_root()
+
+ ROOT_X_ROOT(sqrt);
+ ROOT_X_ROOT(cbrt);
+
+ /* Test pow(x,y)*pow(x,z) -> pow(x,y+z). */
+#define POW_X_POW \
+ extern void link_failure_pow_x_pow(void); \
+ if (pow(d1,d2)*pow(d1,d3) != pow(d1,d2+d3) \
+ || powf(f1,f2)*powf(f1,f3) != powf(f1,f2+f3) \
+ || powl(ld1,ld2)*powl(ld1,ld3) != powl(ld1,ld2+ld3)) \
+ link_failure_pow_x_pow()
+
+ POW_X_POW;
+
+}
+
+int main (void)
+{
+ return 0;
+}
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-12 14:36 [PATCH]: Add some more builtins opts for sqrt/cbrt Kaveh R. Ghazi
@ 2004-03-19 8:14 ` Kaveh R. Ghazi
2004-03-25 13:10 ` Unreviewed patch Kaveh R. Ghazi
2004-03-27 18:43 ` [PATCH]: Add some more builtins opts for sqrt/cbrt David Edelsohn
2 siblings, 0 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-19 8:14 UTC (permalink / raw)
To: gcc-patches
This patch adds a few more builtin optimizations for sqrt and cbrt.
The new transformations are:
sqrt(Nroot(x)) -> pow(x,1/(2*N)) (where Nroot is either sqrt or cbrt)
cbrt(N) -> N (for N == {0,1,-1})
cbrt(expN(x)) -> expN(x/3)
cbrt(sqrt(x)) -> pow(x,1/6)
cbrt(x)*cbrt(y) -> cbrt(x*y)
I didn't do cbrt(cbrt(x)), cbrt(pow(x,y)) and pow(cbrt(x),y) into
plain pow because I believe all of these would succeed with innocuous
negative values of x but might fail if tranformed into just pow. I'll
do these later by checking if x is nonnegative or y is a multiple of
three.
Tested on sparc-sun-solaris2.7, no regressions and the new cases pass.
Ok for mainline?
Thanks,
--Kaveh
2004-03-12 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* builtins.c (fold_builtin): Add new builtin optimizations for
sqrt and/or cbrt.
* fold-const.c (fold): Likewise.
testsuite:
* gcc.dg/torture/builtin-explog-1.c: Add new cases.
* gcc.dg/torture/builtin-math-1.c: Likewise.
* builtin-power-1.c: New test.
diff -rup orig/egcc-CVS20040310/gcc/builtins.c egcc-CVS20040310/gcc/builtins.c
--- orig/egcc-CVS20040310/gcc/builtins.c 2004-03-10 20:02:07.000000000 -0500
+++ egcc-CVS20040310/gcc/builtins.c 2004-03-11 18:03:17.721038000 -0500
@@ -6748,6 +6748,29 @@ fold_builtin (tree exp)
return build_function_call_expr (expfn, arglist);
}
+ /* Optimize sqrt(Nroot(x)) -> pow(x,1/(2*N)). */
+ if (flag_unsafe_math_optimizations && BUILTIN_ROOT_P (fcode))
+ {
+ tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+
+ if (powfn)
+ {
+ tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+ tree tree_root;
+ /* The inner root was either sqrt or cbrt. */
+ REAL_VALUE_TYPE dconstroot =
+ BUILTIN_SQRT_P (fcode) ? dconsthalf : dconstthird;
+
+ /* Adjust for the outer root. */
+ dconstroot.exp--;
+ dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+ tree_root = build_real (type, dconstroot);
+ arglist = tree_cons (NULL_TREE, arg0,
+ build_tree_list (NULL_TREE, tree_root));
+ return build_function_call_expr (powfn, arglist);
+ }
+ }
+
/* Optimize sqrt(pow(x,y)) = pow(x,y*0.5). */
if (flag_unsafe_math_optimizations
&& (fcode == BUILT_IN_POW
@@ -6766,6 +6789,56 @@ fold_builtin (tree exp)
}
break;
+ case BUILT_IN_CBRT:
+ case BUILT_IN_CBRTF:
+ case BUILT_IN_CBRTL:
+ if (validate_arglist (arglist, REAL_TYPE, VOID_TYPE))
+ {
+ tree arg = TREE_VALUE (arglist);
+ const enum built_in_function fcode = builtin_mathfn_code (arg);
+
+ /* Optimize cbrt of constant value. */
+ if (real_zerop (arg) || real_onep (arg) || real_minus_onep (arg))
+ return arg;
+
+ /* Optimize cbrt(expN(x)) -> expN(x/3). */
+ if (flag_unsafe_math_optimizations && BUILTIN_EXPONENT_P (fcode))
+ {
+ tree expfn = TREE_OPERAND (TREE_OPERAND (arg, 0), 0);
+ const REAL_VALUE_TYPE third_trunc =
+ real_value_truncate (TYPE_MODE (type), dconstthird);
+ arg = fold (build (MULT_EXPR, type,
+ TREE_VALUE (TREE_OPERAND (arg, 1)),
+ build_real (type, third_trunc)));
+ arglist = build_tree_list (NULL_TREE, arg);
+ return build_function_call_expr (expfn, arglist);
+ }
+
+ /* Optimize cbrt(sqrt(x)) -> pow(x,1/6). */
+ /* We don't optimize cbrt(cbrt(x)) -> pow(x,1/9) because if
+ x is negative pow will error but cbrt won't. */
+ if (flag_unsafe_math_optimizations && BUILTIN_SQRT_P (fcode))
+ {
+ tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+
+ if (powfn)
+ {
+ tree arg0 = TREE_VALUE (TREE_OPERAND (arg, 1));
+ tree tree_root;
+ REAL_VALUE_TYPE dconstroot = dconstthird;
+
+ dconstroot.exp--;
+ dconstroot = real_value_truncate (TYPE_MODE (type), dconstroot);
+ tree_root = build_real (type, dconstroot);
+ arglist = tree_cons (NULL_TREE, arg0,
+ build_tree_list (NULL_TREE, tree_root));
+ return build_function_call_expr (powfn, arglist);
+ }
+
+ }
+ }
+ break;
+
case BUILT_IN_SIN:
case BUILT_IN_SINF:
case BUILT_IN_SINL:
diff -rup orig/egcc-CVS20040310/gcc/fold-const.c egcc-CVS20040310/gcc/fold-const.c
--- orig/egcc-CVS20040310/gcc/fold-const.c 2004-03-10 13:13:01.000000000 -0500
+++ egcc-CVS20040310/gcc/fold-const.c 2004-03-11 13:17:27.744332000 -0500
@@ -6422,23 +6422,24 @@ fold (tree expr)
enum built_in_function fcode0 = builtin_mathfn_code (arg0);
enum built_in_function fcode1 = builtin_mathfn_code (arg1);
- /* Optimizations of sqrt(...)*sqrt(...). */
- if (fcode0 == fcode1 && BUILTIN_SQRT_P (fcode0))
+ /* Optimizations of root(...)*root(...). */
+ if (fcode0 == fcode1 && BUILTIN_ROOT_P (fcode0))
{
- tree sqrtfn, arg, arglist;
+ tree rootfn, arg, arglist;
tree arg00 = TREE_VALUE (TREE_OPERAND (arg0, 1));
tree arg10 = TREE_VALUE (TREE_OPERAND (arg1, 1));
/* Optimize sqrt(x)*sqrt(x) as x. */
- if (operand_equal_p (arg00, arg10, 0)
+ if (BUILTIN_SQRT_P (fcode0)
+ && operand_equal_p (arg00, arg10, 0)
&& ! HONOR_SNANS (TYPE_MODE (type)))
return arg00;
- /* Optimize sqrt(x)*sqrt(y) as sqrt(x*y). */
- sqrtfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
+ /* Optimize root(x)*root(y) as root(x*y). */
+ rootfn = TREE_OPERAND (TREE_OPERAND (arg0, 0), 0);
arg = fold (build (MULT_EXPR, type, arg00, arg10));
arglist = build_tree_list (NULL_TREE, arg);
- return build_function_call_expr (sqrtfn, arglist);
+ return build_function_call_expr (rootfn, arglist);
}
/* Optimize expN(x)*expN(y) as expN(x+y). */
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c 2004-03-06 12:53:57.000000000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c 2004-03-11 18:56:30.834742000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2003 Free Software Foundation.
+/* Copyright (C) 2003, 2004 Free Software Foundation.
Verify that built-in math function constant folding of log & exp is
correctly performed by the compiler.
@@ -119,6 +119,17 @@ void test(double d1, double d2, float f1
LOG_CBRT(log2);
LOG_CBRT(log10);
+ /* Test cbrt(expN(x)) -> expN(x/3). */
+#define CBRT_EXP(EXP) \
+ extern void link_failure_cbrt_##EXP(void); \
+ if (cbrt(EXP(d1)) != EXP(d1/3.0) || cbrtf(EXP##f(f1)) != EXP##f(f1/3.0F) \
+ || cbrtl(EXP##l(ld1)) != EXP##l(ld1/3.0L)) link_failure_cbrt_##EXP()
+
+ CBRT_EXP(exp);
+ CBRT_EXP(exp2);
+ CBRT_EXP(exp10);
+ CBRT_EXP(pow10);
+
/* Test logN(pow(x,y)) -> y*logN(x). */
#define LOG_POW(LOG, POW) \
extern void link_failure_##LOG##_##POW(void); \
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c 2003-08-02 15:09:54.000000000 -0400
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-math-1.c 2004-03-11 18:56:25.215208000 -0500
@@ -1,4 +1,4 @@
-/* Copyright (C) 2002, 2003 Free Software Foundation.
+/* Copyright (C) 2002, 2003, 2004 Free Software Foundation.
Verify that built-in math function constant folding of constant
arguments is correctly performed by the compiler.
@@ -18,6 +18,15 @@ void test (float f, double d, long doubl
if (sqrt (1.0) != 1.0)
link_error ();
+ if (cbrt (0.0) != 0.0)
+ link_error ();
+
+ if (cbrt (1.0) != 1.0)
+ link_error ();
+
+ if (cbrt (-1.0) != -1.0)
+ link_error ();
+
if (exp (0.0) != 1.0)
link_error ();
@@ -55,6 +64,15 @@ void test (float f, double d, long doubl
if (sqrtf (1.0F) != 1.0F)
link_error ();
+ if (cbrtf (0.0F) != 0.0F)
+ link_error ();
+
+ if (cbrtf (1.0F) != 1.0F)
+ link_error ();
+
+ if (cbrtf (-1.0F) != -1.0F)
+ link_error ();
+
if (expf (0.0F) != 1.0F)
link_error ();
@@ -92,6 +110,15 @@ void test (float f, double d, long doubl
if (sqrtl (1.0L) != 1.0L)
link_error ();
+ if (cbrtl (0.0L) != 0.0L)
+ link_error ();
+
+ if (cbrtl (1.0L) != 1.0L)
+ link_error ();
+
+ if (cbrtl (-1.0L) != -1.0L)
+ link_error ();
+
if (expl (0.0L) != 1.0L)
link_error ();
diff -rup orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c
--- orig/egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c 2004-03-11 18:14:10.341709000 -0500
+++ egcc-CVS20040310/gcc/testsuite/gcc.dg/torture/builtin-power-1.c 2004-03-11 18:56:03.906846000 -0500
@@ -0,0 +1,105 @@
+/* Copyright (C) 2004 Free Software Foundation.
+
+ Verify that built-in folding of various math "power" functions is
+ correctly performed by the compiler.
+
+ Written by Kaveh Ghazi, 2004-03-11. */
+
+/* { dg-do link } */
+/* { dg-options "-ffast-math" } */
+
+#include "../builtins-config.h"
+
+#ifdef HAVE_C99_RUNTIME
+#define C99CODE(CODE) CODE
+#else
+#define C99CODE(CODE) 0
+#endif
+
+#define PROTOTYPE(FN) extern double FN(double); extern float FN##f(float); \
+ extern long double FN##l(long double);
+#define PROTOTYPE2(FN) extern double FN(double, double); \
+ extern float FN##f(float, float); \
+ extern long double FN##l(long double, long double);
+
+PROTOTYPE(sqrt)
+PROTOTYPE(cbrt)
+PROTOTYPE2(pow)
+
+void test(double d1, double d2, double d3,
+ float f1, float f2, float f3,
+ long double ld1, long double ld2, long double ld3)
+{
+ /* Test N1root(N2root(x)) -> pow(x,1/(N1*N2)). */
+ /* E.g. sqrt(cbrt(x)) -> pow(x,1/6). */
+#define ROOT_ROOT(FN1,N1,FN2,N2) \
+ extern void link_failure_##FN1##_##FN2(void); \
+ if (FN1(FN2(d1)) != pow(d1,1.0/(N1*N2)) \
+ || C99CODE (FN1##f(FN2##f(f1)) != powf(f1,1.0F/(N1*N2))) \
+ || C99CODE (FN1##l(FN2##l(ld1)) != powl(ld1,1.0L/(N1*N2)))) \
+ link_failure_##FN1##_##FN2()
+
+ ROOT_ROOT(sqrt,2,sqrt,2);
+ ROOT_ROOT(sqrt,2,cbrt,3);
+ ROOT_ROOT(cbrt,3,sqrt,2);
+ /*ROOT_ROOT(cbrt,3,cbrt,3); Intentionally not implemented. */
+
+ /* Test pow(Nroot(x),y) -> pow(x,y/N). */
+#define POW_ROOT(FN,N) \
+ extern void link_failure_pow_##FN(void); \
+ if (pow(FN(d1), d2) != pow(d1,d2/N) \
+ || powf(FN##f(f1),f2) != powf(f1,f2/N) \
+ || powl(FN##l(ld1),ld2) != powl(ld1,ld2/N)) \
+ link_failure_pow_##FN()
+
+ POW_ROOT(sqrt,2);
+ /*POW_ROOT(cbrt,3); Intentionally not implemented. */
+
+ /* Test Nroot(pow(x,y)) -> pow(x,y/N). */
+#define ROOT_POW(FN,N) \
+ extern void link_failure_##FN##_pow(void); \
+ if (FN(pow(d1, d2)) != pow(d1,d2/N) \
+ || FN##f(powf(f1,f2)) != powf(f1,f2/N) \
+ || FN##l(powl(ld1,ld2)) != powl(ld1,ld2/N)) \
+ link_failure_##FN##_pow()
+
+ ROOT_POW(sqrt,2);
+ /*ROOT_POW(cbrt,3); Intentionally not implemented. */
+
+ /* Test pow(pow(x,y),z) -> pow(x,y*z). */
+#define POW_POW \
+ extern void link_failure_pow_pow(void); \
+ if (pow(pow(d1, d2), d3) != pow(d1,d2*d3) \
+ || powf(powf(f1,f2),f3) != powf(f1,f2*f3) \
+ || powl(powl(ld1,ld2),ld3) != powl(ld1,ld2*ld3)) \
+ link_failure_pow_pow()
+
+ POW_POW;
+
+ /* Test Nroot(x)*Nroot(y) -> Nroot(x*y). */
+#define ROOT_X_ROOT(FN) \
+ extern void link_failure_root_x_root(void); \
+ if (FN(d1)*FN(d2) != FN(d1*d2) \
+ || FN##f(f1)*FN##f(f2) != FN##f(f1*f2) \
+ || FN##l(ld1)*FN##l(ld2) != FN##l(ld1*ld2)) \
+ link_failure_root_x_root()
+
+ ROOT_X_ROOT(sqrt);
+ ROOT_X_ROOT(cbrt);
+
+ /* Test pow(x,y)*pow(x,z) -> pow(x,y+z). */
+#define POW_X_POW \
+ extern void link_failure_pow_x_pow(void); \
+ if (pow(d1,d2)*pow(d1,d3) != pow(d1,d2+d3) \
+ || powf(f1,f2)*powf(f1,f3) != powf(f1,f2+f3) \
+ || powl(ld1,ld2)*powl(ld1,ld3) != powl(ld1,ld2+ld3)) \
+ link_failure_pow_x_pow()
+
+ POW_X_POW;
+
+}
+
+int main (void)
+{
+ return 0;
+}
^ permalink raw reply [flat|nested] 31+ messages in thread
* Unreviewed patch
2004-03-12 14:36 [PATCH]: Add some more builtins opts for sqrt/cbrt Kaveh R. Ghazi
2004-03-19 8:14 ` Kaveh R. Ghazi
@ 2004-03-25 13:10 ` Kaveh R. Ghazi
2004-03-25 14:57 ` Roger Sayle
2004-03-27 18:43 ` [PATCH]: Add some more builtins opts for sqrt/cbrt David Edelsohn
2 siblings, 1 reply; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-25 13:10 UTC (permalink / raw)
To: gcc-patches
It's been around two weeks since I posted this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01033.html
Would someone please review it? It would be much appreciated.
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-12 14:36 [PATCH]: Add some more builtins opts for sqrt/cbrt Kaveh R. Ghazi
2004-03-19 8:14 ` Kaveh R. Ghazi
2004-03-25 13:10 ` Unreviewed patch Kaveh R. Ghazi
@ 2004-03-27 18:43 ` David Edelsohn
2004-03-28 0:05 ` Kaveh R. Ghazi
2004-03-28 0:11 ` Kaveh R. Ghazi
2 siblings, 2 replies; 31+ messages in thread
From: David Edelsohn @ 2004-03-27 18:43 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches
builtin-power-1.c is failing on PowerPC. On AIX I see the
following link failures in the log:
ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_sqrt
ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_cbrt
ld: 0711-317 ERROR: Undefined symbol: .link_failure_cbrt_sqrt
It also is failing on Darwin, along with other builtins.
David
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-27 18:43 ` [PATCH]: Add some more builtins opts for sqrt/cbrt David Edelsohn
@ 2004-03-28 0:05 ` Kaveh R. Ghazi
2004-03-28 1:09 ` David Edelsohn
2004-03-29 18:55 ` Richard Henderson
2004-03-28 0:11 ` Kaveh R. Ghazi
1 sibling, 2 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-28 0:05 UTC (permalink / raw)
To: dje; +Cc: gcc-patches, roger
> From: David Edelsohn <dje@watson.ibm.com>
>
> builtin-power-1.c is failing on PowerPC. On AIX I see the
> following link failures in the log:
>
> ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_sqrt
> ld: 0711-317 ERROR: Undefined symbol: .link_failure_sqrt_cbrt
> ld: 0711-317 ERROR: Undefined symbol: .link_failure_cbrt_sqrt
The problem here was that we were transforming into the wrong FP type,
i.e. pow vs powl. The following patch seems to fix the problem in a
cross config to aix5.1 when visually scanning the assembly output.
David - Does it fix the failure you saw?
Meanwhile, I'm running a full regression test on solaris2.7. Assuming
it fixes David's failure and passes regtest, ok for mainline?
--Kaveh
PS: I indended to use `mathfn_built_in' to say "give me the mathfn
builtin for a particular FP type, e.g. float". It doesn't appear to
do that exactly, so I'm not sure when it's ever correct to use
mathfn_built_in.
2004-03-27 Kaveh R. Ghazi <ghazi@caip.rutgers.edu>
* builtins.c (fold_builtin): Don't use `mathfn_built_in' to lookup
replacement builtin.
diff -rup orig/egcc-CVS20040327/gcc/builtins.c egcc-CVS20040327/gcc/builtins.c
--- orig/egcc-CVS20040327/gcc/builtins.c Thu Mar 25 19:27:52 2004
+++ egcc-CVS20040327/gcc/builtins.c Sat Mar 27 18:45:44 2004
@@ -6693,7 +6693,12 @@ fold_builtin (tree exp)
/* Optimize sqrt(Nroot(x)) -> pow(x,1/(2*N)). */
if (flag_unsafe_math_optimizations && BUILTIN_ROOT_P (fcode))
{
- tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+ tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRT)
+ ? implicit_built_in_decls[BUILT_IN_POW] :
+ (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRTF)
+ ? implicit_built_in_decls[BUILT_IN_POWF] :
+ (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRTL)
+ ? implicit_built_in_decls[BUILT_IN_POWL] : NULL_TREE;
if (powfn)
{
@@ -6761,7 +6766,12 @@ fold_builtin (tree exp)
x is negative pow will error but cbrt won't. */
if (flag_unsafe_math_optimizations && BUILTIN_SQRT_P (fcode))
{
- tree powfn = mathfn_built_in (type, BUILT_IN_POW);
+ tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CBRT)
+ ? implicit_built_in_decls[BUILT_IN_POW] :
+ (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CBRTF)
+ ? implicit_built_in_decls[BUILT_IN_POWF] :
+ (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CBRTL)
+ ? implicit_built_in_decls[BUILT_IN_POWL] : NULL_TREE;
if (powfn)
{
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-28 0:05 ` Kaveh R. Ghazi
@ 2004-03-28 1:09 ` David Edelsohn
2004-03-29 18:55 ` Richard Henderson
1 sibling, 0 replies; 31+ messages in thread
From: David Edelsohn @ 2004-03-28 1:09 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches, roger
>>>>> Kaveh R Ghazi writes:
Kaveh> The problem here was that we were transforming into the wrong FP type,
Kaveh> i.e. pow vs powl. The following patch seems to fix the problem in a
Kaveh> cross config to aix5.1 when visually scanning the assembly output.
Kaveh> David - Does it fix the failure you saw?
Yes, the patch fixes the failures I am seeing on AIX.
Thanks, David
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-28 0:05 ` Kaveh R. Ghazi
2004-03-28 1:09 ` David Edelsohn
@ 2004-03-29 18:55 ` Richard Henderson
2004-03-29 20:47 ` Kaveh R. Ghazi
1 sibling, 1 reply; 31+ messages in thread
From: Richard Henderson @ 2004-03-29 18:55 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: dje, gcc-patches, roger
On Sat, Mar 27, 2004 at 07:05:32PM -0500, Kaveh R. Ghazi wrote:
> - tree powfn = mathfn_built_in (type, BUILT_IN_POW);
> + tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRT)
> + ? implicit_built_in_decls[BUILT_IN_POW] :
...
This would suggest that TYPE is wrong in that call then.
r~
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-29 18:55 ` Richard Henderson
@ 2004-03-29 20:47 ` Kaveh R. Ghazi
2004-03-29 20:52 ` Richard Henderson
0 siblings, 1 reply; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-29 20:47 UTC (permalink / raw)
To: rth; +Cc: dje, gcc-patches, roger
> From: Richard Henderson <rth@redhat.com>
>
> On Sat, Mar 27, 2004 at 07:05:32PM -0500, Kaveh R. Ghazi wrote:
> > - tree powfn = mathfn_built_in (type, BUILT_IN_POW);
> > + tree powfn = (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_SQRT)
> > + ? implicit_built_in_decls[BUILT_IN_POW] :
> ...
>
> This would suggest that TYPE is wrong in that call then.
> r~
No, I don't think so.
I did some further investigating as to why mathfn_built_in didn't do
what I expected. The code in the function says:
const enum machine_mode type_mode = TYPE_MODE (type);
[...]
if (type_mode == TYPE_MODE (double_type_node))
return implicit_built_in_decls[fcode];
else if (type_mode == TYPE_MODE (float_type_node))
return implicit_built_in_decls[fcodef];
else if (type_mode == TYPE_MODE (long_double_type_node))
return implicit_built_in_decls[fcodel];
else
return 0;
If I understand it correctly, there's no guarantee that if you ask for
a "long double" pow function that you'll actually get `powl'. The
code prefers the "double" version if the sizes of double and long
double are equal (as I believe they are on aix5 where the error
appeared.)
I'm not sure this is the best design for `mathfn_built_in'. At least,
it wasn't intuitive to me.
Thoughts?
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-29 20:47 ` Kaveh R. Ghazi
@ 2004-03-29 20:52 ` Richard Henderson
2004-03-29 23:22 ` Kaveh R. Ghazi
0 siblings, 1 reply; 31+ messages in thread
From: Richard Henderson @ 2004-03-29 20:52 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: dje, gcc-patches, roger
On Mon, Mar 29, 2004 at 03:47:17PM -0500, Kaveh R. Ghazi wrote:
> If I understand it correctly, there's no guarantee that if you ask for
> a "long double" pow function that you'll actually get `powl'.
That's also a bug. Why are we comparing modes as opposed
to type-main-variant or such?
r~
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-29 20:52 ` Richard Henderson
@ 2004-03-29 23:22 ` Kaveh R. Ghazi
0 siblings, 0 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-29 23:22 UTC (permalink / raw)
To: rth; +Cc: dje, gcc-patches, jh, roger
> From: Richard Henderson <rth@redhat.com>
>
> On Mon, Mar 29, 2004 at 03:47:17PM -0500, Kaveh R. Ghazi wrote:
> > If I understand it correctly, there's no guarantee that if you ask for
> > a "long double" pow function that you'll actually get `powl'.
>
> That's also a bug. Why are we comparing modes as opposed
> to type-main-variant or such?
> r~
Don't know, let's ask the original author of the function. Jan?
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-27 18:43 ` [PATCH]: Add some more builtins opts for sqrt/cbrt David Edelsohn
2004-03-28 0:05 ` Kaveh R. Ghazi
@ 2004-03-28 0:11 ` Kaveh R. Ghazi
2004-03-28 7:28 ` Andrew Pinski
1 sibling, 1 reply; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-28 0:11 UTC (permalink / raw)
To: dje; +Cc: gcc-patches
> From: David Edelsohn <dje@watson.ibm.com>
>
> builtin-power-1.c is failing on PowerPC. [...]
>
> It also is failing on Darwin, along with other builtins.
> David
The darwin failure is different. It occurs because there is a
mismatch in whether GCC thinks darwin has C99 functions between the
darwin port itself and the testsuite. Fixing this will correct much
more than just builtin-power-1.c. As you noted, there are several
builtins failures on darwin.
If darwin has the C99 functions, then someone needs to add
#define TARGET_C99_FUNCTIONS 1
to config/darwin.h.
If darwin doesn't have the C99 functions, then someone needs to tweek
testsuite/gcc.dg/builtins-config.h appropriately so darwin doesn't
attempt to test any transformations which result in C99 function
calls.
Either way, someone who knows darwin and can test on it should fix
this.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-28 0:11 ` Kaveh R. Ghazi
@ 2004-03-28 7:28 ` Andrew Pinski
2004-03-28 13:03 ` Kaveh R. Ghazi
0 siblings, 1 reply; 31+ messages in thread
From: Andrew Pinski @ 2004-03-28 7:28 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches, Andrew Pinski, dje
On Mar 27, 2004, at 19:11, Kaveh R. Ghazi wrote:
>> From: David Edelsohn <dje@watson.ibm.com>
>>
>> builtin-power-1.c is failing on PowerPC. [...]
>>
>> It also is failing on Darwin, along with other builtins.
>> David
>
> The darwin failure is different. It occurs because there is a
> mismatch in whether GCC thinks darwin has C99 functions between the
> darwin port itself and the testsuite. Fixing this will correct much
> more than just builtin-power-1.c. As you noted, there are several
> builtins failures on darwin.
>
> If darwin has the C99 functions, then someone needs to add
> #define TARGET_C99_FUNCTIONS 1
> to config/darwin.h.
>
> If darwin doesn't have the C99 functions, then someone needs to tweek
> testsuite/gcc.dg/builtins-config.h appropriately so darwin doesn't
> attempt to test any transformations which result in C99 function
> calls.
>
> Either way, someone who knows darwin and can test on it should fix
> this.
I have a fix for darwin but I have not applied it yet, I have been
just to busy to finish it up as the C99 math functions are in the
libmx library which causes so much problems. I have already fixed
libgfortran to support this library but I need to add support for
libstdc++.
I am almost ready to file a bug (with Apple) asking for the
functions to be in libm or libsystem as that makes it more
consistent with the rest of the UNIX world.
Thanks,
Andrew Pinski
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-03-28 7:28 ` Andrew Pinski
@ 2004-03-28 13:03 ` Kaveh R. Ghazi
0 siblings, 0 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-03-28 13:03 UTC (permalink / raw)
To: pinskia; +Cc: dje, gcc-patches
> From: Andrew Pinski <pinskia@physics.uc.edu>
>
> On Mar 27, 2004, at 19:11, Kaveh R. Ghazi wrote:
>
> > If darwin has the C99 functions, then someone needs to add
> > #define TARGET_C99_FUNCTIONS 1
> > to config/darwin.h.
> >
> > If darwin doesn't have the C99 functions, then someone needs to tweek
> > testsuite/gcc.dg/builtins-config.h appropriately so darwin doesn't
> > attempt to test any transformations which result in C99 function
> > calls.
> >
> > Either way, someone who knows darwin and can test on it should fix
> > this.
>
> I have a fix for darwin but I have not applied it yet, I have been
> just to busy to finish it up as the C99 math functions are in the
> libmx library which causes so much problems. I have already fixed
> libgfortran to support this library but I need to add support for
> libstdc++.
>
> I am almost ready to file a bug (with Apple) asking for the
> functions to be in libm or libsystem as that makes it more
> consistent with the rest of the UNIX world.
Ok, thanks for the info. In the mean time, perhaps you would like to
add a darwin bypass into builtins-config.h to reduce the testsuite
noise there?
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
@ 2004-03-25 21:42 Ulrich Weigand
0 siblings, 0 replies; 31+ messages in thread
From: Ulrich Weigand @ 2004-03-25 21:42 UTC (permalink / raw)
To: ghazi; +Cc: gcc-patches
Kaveh Ghazi wrote:
> * builtins.c (fold_builtin): Add new builtin optimizations for
> sqrt and/or cbrt.
>+ dconstroot.exp--;
This causes bootstrap failure due to:
../../gcc-head/gcc/builtins.c: In function `fold_builtin':
../../gcc-head/gcc/builtins.c:6707: error: structure has no member named `exp'
Bye,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
@ 2004-04-07 14:56 John David Anglin
2004-04-07 16:17 ` Kaveh R. Ghazi
2004-04-09 20:06 ` John David Anglin
0 siblings, 2 replies; 31+ messages in thread
From: John David Anglin @ 2004-04-07 14:56 UTC (permalink / raw)
To: gcc-patches; +Cc: ghazi
The following tests are failing under hppa-unknown-linux-gnu:
FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O3 -fomit-frame-pointer (test for exce
ss errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors)
On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
the same size (as defined in defaults.h). It has C99 functions.
I removed the long double tests from builtin-power-1.c and the tests
then pass. I think this points to a problem with the builtins when two
types (double and long double) have the same size.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-07 14:56 John David Anglin
@ 2004-04-07 16:17 ` Kaveh R. Ghazi
2004-04-07 16:46 ` John David Anglin
` (2 more replies)
2004-04-09 20:06 ` John David Anglin
1 sibling, 3 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-04-07 16:17 UTC (permalink / raw)
To: dave, gcc-patches, jh
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>
> The following tests are failing under hppa-unknown-linux-gnu:
>
> FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O1 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O2 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O3 -fomit-frame-pointer (test for exce
> ss errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O3 -g (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors)
>
> On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
> the same size (as defined in defaults.h). It has C99 functions.
>
> I removed the long double tests from builtin-power-1.c and the tests
> then pass. I think this points to a problem with the builtins when two
> types (double and long double) have the same size.
Yes, I know about this one. See
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
The discussion died off waiting for an explanation from Jan about
mathfn_built_in.
This failure is harmless from a code correctness standpoint. It's
simply that when sizeof double and long double are are equal the
testcase doesn't reliably predict the transformed result.
Fixing this can either occur by the patch I submitted in the above
thread, or by changing mathfn_built_in to give predictable results no
matter what the relative sizes of the FP types are.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-07 16:17 ` Kaveh R. Ghazi
@ 2004-04-07 16:46 ` John David Anglin
2004-04-09 20:06 ` John David Anglin
2004-04-08 21:01 ` Jan Hubicka
2004-04-09 20:06 ` Kaveh R. Ghazi
2 siblings, 1 reply; 31+ messages in thread
From: John David Anglin @ 2004-04-07 16:46 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches, jh
> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.
This might be the best approach. There are also about a half-dozen
`long double' related testsuite failures on hppa-linux in the libstdc++
suite. These might also be caused by the above uncertainty.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-07 16:46 ` John David Anglin
@ 2004-04-09 20:06 ` John David Anglin
0 siblings, 0 replies; 31+ messages in thread
From: John David Anglin @ 2004-04-09 20:06 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: gcc-patches, jh
> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.
This might be the best approach. There are also about a half-dozen
`long double' related testsuite failures on hppa-linux in the libstdc++
suite. These might also be caused by the above uncertainty.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-07 16:17 ` Kaveh R. Ghazi
2004-04-07 16:46 ` John David Anglin
@ 2004-04-08 21:01 ` Jan Hubicka
2004-04-08 21:16 ` Kaveh R. Ghazi
2004-04-09 20:06 ` Jan Hubicka
2004-04-09 20:06 ` Kaveh R. Ghazi
2 siblings, 2 replies; 31+ messages in thread
From: Jan Hubicka @ 2004-04-08 21:01 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: dave, gcc-patches, jh
> > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> >
> > The following tests are failing under hppa-unknown-linux-gnu:
> >
> > FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O1 (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O2 (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O3 -fomit-frame-pointer (test for exce
> > ss errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O3 -g (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors)
> >
> > On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
> > the same size (as defined in defaults.h). It has C99 functions.
> >
> > I removed the long double tests from builtin-power-1.c and the tests
> > then pass. I think this points to a problem with the builtins when two
> > types (double and long double) have the same size.
>
> Yes, I know about this one. See
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
>
> The discussion died off waiting for an explanation from Jan about
> mathfn_built_in.
Sorry, I must've missed the thread completely :(
And even now I can't find any question regarding mathfn_built_in in the
thread.
It is supposed to return for given function and type equivalent of
function operating on the type.
>
> This failure is harmless from a code correctness standpoint. It's
> simply that when sizeof double and long double are are equal the
> testcase doesn't reliably predict the transformed result.
>
> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.
You man converting the sinl into sin even when the types are equivalent?
I have nothing against this except that it may be somewhat irratitng to
user to see his code changed for no good reason. But we do that all the
time :)
Honza
>
> --Kaveh
> --
> Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-08 21:01 ` Jan Hubicka
@ 2004-04-08 21:16 ` Kaveh R. Ghazi
2004-04-08 21:19 ` Jan Hubicka
2004-04-09 20:06 ` Kaveh R. Ghazi
2004-04-09 20:06 ` Jan Hubicka
1 sibling, 2 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-04-08 21:16 UTC (permalink / raw)
To: jh; +Cc: dave, gcc-patches
> From: Jan Hubicka <jh@suse.cz>
>
> > Yes, I know about this one. See
> > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
> >
> > The discussion died off waiting for an explanation from Jan about
> > mathfn_built_in.
>
> Sorry, I must've missed the thread completely :(
> And even now I can't find any question regarding mathfn_built_in in
> the thread. It is supposed to return for given function and type
> equivalent of function operating on the type.
The question, as posed by rth in the thread here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html
is why in mathfn_built_in are we comparing the mode rather than
type-main-variant?
Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)
When using mathfn_built_in on a system where the sizes of double and
long double are the same, your algorithm will prefer the double
version of the function and return plain pow even though we asked for
the long double variant.
Was there a reason to write mathfn_built_in this way? E.g. did you
prefer the double type because you were trying to support pre-c99
systems and did it this way before TARGET_C99_FUNCTIONS was
introduced?
If we have no reason to keep the mathfn_built_in algorithm this way,
I'd like to change it to return predictable values regardless of the
sizes of the FP types on the target.
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-08 21:16 ` Kaveh R. Ghazi
@ 2004-04-08 21:19 ` Jan Hubicka
2004-04-09 20:06 ` Jan Hubicka
2004-04-30 15:11 ` David Edelsohn
2004-04-09 20:06 ` Kaveh R. Ghazi
1 sibling, 2 replies; 31+ messages in thread
From: Jan Hubicka @ 2004-04-08 21:19 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: jh, dave, gcc-patches
> > From: Jan Hubicka <jh@suse.cz>
> >
> > > Yes, I know about this one. See
> > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
> > >
> > > The discussion died off waiting for an explanation from Jan about
> > > mathfn_built_in.
> >
> > Sorry, I must've missed the thread completely :(
> > And even now I can't find any question regarding mathfn_built_in in
> > the thread. It is supposed to return for given function and type
> > equivalent of function operating on the type.
>
> The question, as posed by rth in the thread here:
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html
>
> is why in mathfn_built_in are we comparing the mode rather than
> type-main-variant?
>
> Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)
>
> When using mathfn_built_in on a system where the sizes of double and
> long double are the same, your algorithm will prefer the double
> version of the function and return plain pow even though we asked for
> the long double variant.
>
> Was there a reason to write mathfn_built_in this way? E.g. did you
> prefer the double type because you were trying to support pre-c99
> systems and did it this way before TARGET_C99_FUNCTIONS was
> introduced?
No, I guess I wrote it just because I was thinking in RTL way so modes
seemed more natural to compare.
>
> If we have no reason to keep the mathfn_built_in algorithm this way,
> I'd like to change it to return predictable values regardless of the
> sizes of the FP types on the target.
That sounds fine to me.
Honza
>
> Thanks,
> --Kaveh
> --
> Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-08 21:19 ` Jan Hubicka
@ 2004-04-09 20:06 ` Jan Hubicka
2004-04-30 15:11 ` David Edelsohn
1 sibling, 0 replies; 31+ messages in thread
From: Jan Hubicka @ 2004-04-09 20:06 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: jh, dave, gcc-patches
> > From: Jan Hubicka <jh@suse.cz>
> >
> > > Yes, I know about this one. See
> > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
> > >
> > > The discussion died off waiting for an explanation from Jan about
> > > mathfn_built_in.
> >
> > Sorry, I must've missed the thread completely :(
> > And even now I can't find any question regarding mathfn_built_in in
> > the thread. It is supposed to return for given function and type
> > equivalent of function operating on the type.
>
> The question, as posed by rth in the thread here:
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html
>
> is why in mathfn_built_in are we comparing the mode rather than
> type-main-variant?
>
> Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)
>
> When using mathfn_built_in on a system where the sizes of double and
> long double are the same, your algorithm will prefer the double
> version of the function and return plain pow even though we asked for
> the long double variant.
>
> Was there a reason to write mathfn_built_in this way? E.g. did you
> prefer the double type because you were trying to support pre-c99
> systems and did it this way before TARGET_C99_FUNCTIONS was
> introduced?
No, I guess I wrote it just because I was thinking in RTL way so modes
seemed more natural to compare.
>
> If we have no reason to keep the mathfn_built_in algorithm this way,
> I'd like to change it to return predictable values regardless of the
> sizes of the FP types on the target.
That sounds fine to me.
Honza
>
> Thanks,
> --Kaveh
> --
> Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-08 21:19 ` Jan Hubicka
2004-04-09 20:06 ` Jan Hubicka
@ 2004-04-30 15:11 ` David Edelsohn
2004-04-30 15:29 ` Kaveh R. Ghazi
1 sibling, 1 reply; 31+ messages in thread
From: David Edelsohn @ 2004-04-30 15:11 UTC (permalink / raw)
To: Jan Hubicka, Kaveh R. Ghazi; +Cc: gcc-patches, dave
>> If we have no reason to keep the mathfn_built_in algorithm this way,
>> I'd like to change it to return predictable values regardless of the
>> sizes of the FP types on the target.
>That sounds fine to me.
Any progress on reaching a consensus to fix the testsuite failures
and implementing the solution?
Thanks, David
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-08 21:16 ` Kaveh R. Ghazi
2004-04-08 21:19 ` Jan Hubicka
@ 2004-04-09 20:06 ` Kaveh R. Ghazi
1 sibling, 0 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-04-09 20:06 UTC (permalink / raw)
To: jh; +Cc: dave, gcc-patches
> From: Jan Hubicka <jh@suse.cz>
>
> > Yes, I know about this one. See
> > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
> >
> > The discussion died off waiting for an explanation from Jan about
> > mathfn_built_in.
>
> Sorry, I must've missed the thread completely :(
> And even now I can't find any question regarding mathfn_built_in in
> the thread. It is supposed to return for given function and type
> equivalent of function operating on the type.
The question, as posed by rth in the thread here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html
is why in mathfn_built_in are we comparing the mode rather than
type-main-variant?
Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6)
When using mathfn_built_in on a system where the sizes of double and
long double are the same, your algorithm will prefer the double
version of the function and return plain pow even though we asked for
the long double variant.
Was there a reason to write mathfn_built_in this way? E.g. did you
prefer the double type because you were trying to support pre-c99
systems and did it this way before TARGET_C99_FUNCTIONS was
introduced?
If we have no reason to keep the mathfn_built_in algorithm this way,
I'd like to change it to return predictable values regardless of the
sizes of the FP types on the target.
Thanks,
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-08 21:01 ` Jan Hubicka
2004-04-08 21:16 ` Kaveh R. Ghazi
@ 2004-04-09 20:06 ` Jan Hubicka
1 sibling, 0 replies; 31+ messages in thread
From: Jan Hubicka @ 2004-04-09 20:06 UTC (permalink / raw)
To: Kaveh R. Ghazi; +Cc: dave, gcc-patches, jh
> > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> >
> > The following tests are failing under hppa-unknown-linux-gnu:
> >
> > FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O1 (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O2 (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O3 -fomit-frame-pointer (test for exce
> > ss errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -O3 -g (test for excess errors)
> > FAIL: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors)
> >
> > On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
> > the same size (as defined in defaults.h). It has C99 functions.
> >
> > I removed the long double tests from builtin-power-1.c and the tests
> > then pass. I think this points to a problem with the builtins when two
> > types (double and long double) have the same size.
>
> Yes, I know about this one. See
> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
>
> The discussion died off waiting for an explanation from Jan about
> mathfn_built_in.
Sorry, I must've missed the thread completely :(
And even now I can't find any question regarding mathfn_built_in in the
thread.
It is supposed to return for given function and type equivalent of
function operating on the type.
>
> This failure is harmless from a code correctness standpoint. It's
> simply that when sizeof double and long double are are equal the
> testcase doesn't reliably predict the transformed result.
>
> Fixing this can either occur by the patch I submitted in the above
> thread, or by changing mathfn_built_in to give predictable results no
> matter what the relative sizes of the FP types are.
You man converting the sinl into sin even when the types are equivalent?
I have nothing against this except that it may be somewhat irratitng to
user to see his code changed for no good reason. But we do that all the
time :)
Honza
>
> --Kaveh
> --
> Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-07 16:17 ` Kaveh R. Ghazi
2004-04-07 16:46 ` John David Anglin
2004-04-08 21:01 ` Jan Hubicka
@ 2004-04-09 20:06 ` Kaveh R. Ghazi
2 siblings, 0 replies; 31+ messages in thread
From: Kaveh R. Ghazi @ 2004-04-09 20:06 UTC (permalink / raw)
To: dave, gcc-patches, jh
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>
> The following tests are failing under hppa-unknown-linux-gnu:
>
> FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O1 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O2 (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O3 -fomit-frame-pointer (test for exce
> ss errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -O3 -g (test for excess errors)
> FAIL: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors)
>
> On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
> the same size (as defined in defaults.h). It has C99 functions.
>
> I removed the long double tests from builtin-power-1.c and the tests
> then pass. I think this points to a problem with the builtins when two
> types (double and long double) have the same size.
Yes, I know about this one. See
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html
The discussion died off waiting for an explanation from Jan about
mathfn_built_in.
This failure is harmless from a code correctness standpoint. It's
simply that when sizeof double and long double are are equal the
testcase doesn't reliably predict the transformed result.
Fixing this can either occur by the patch I submitted in the above
thread, or by changing mathfn_built_in to give predictable results no
matter what the relative sizes of the FP types are.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH]: Add some more builtins opts for sqrt/cbrt
2004-04-07 14:56 John David Anglin
2004-04-07 16:17 ` Kaveh R. Ghazi
@ 2004-04-09 20:06 ` John David Anglin
1 sibling, 0 replies; 31+ messages in thread
From: John David Anglin @ 2004-04-09 20:06 UTC (permalink / raw)
To: gcc-patches; +Cc: ghazi
The following tests are failing under hppa-unknown-linux-gnu:
FAIL: gcc.dg/torture/builtin-power-1.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O3 -fomit-frame-pointer (test for exce
ss errors)
FAIL: gcc.dg/torture/builtin-power-1.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/builtin-power-1.c -Os (test for excess errors)
On hppa-linux, DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE are currently
the same size (as defined in defaults.h). It has C99 functions.
I removed the long double tests from builtin-power-1.c and the tests
then pass. I think this points to a problem with the builtins when two
types (double and long double) have the same size.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2004-05-02 13:49 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-12 14:36 [PATCH]: Add some more builtins opts for sqrt/cbrt Kaveh R. Ghazi
2004-03-19 8:14 ` Kaveh R. Ghazi
2004-03-25 13:10 ` Unreviewed patch Kaveh R. Ghazi
2004-03-25 14:57 ` Roger Sayle
2004-03-27 18:43 ` [PATCH]: Add some more builtins opts for sqrt/cbrt David Edelsohn
2004-03-28 0:05 ` Kaveh R. Ghazi
2004-03-28 1:09 ` David Edelsohn
2004-03-29 18:55 ` Richard Henderson
2004-03-29 20:47 ` Kaveh R. Ghazi
2004-03-29 20:52 ` Richard Henderson
2004-03-29 23:22 ` Kaveh R. Ghazi
2004-03-28 0:11 ` Kaveh R. Ghazi
2004-03-28 7:28 ` Andrew Pinski
2004-03-28 13:03 ` Kaveh R. Ghazi
2004-03-25 21:42 Ulrich Weigand
2004-04-07 14:56 John David Anglin
2004-04-07 16:17 ` Kaveh R. Ghazi
2004-04-07 16:46 ` John David Anglin
2004-04-09 20:06 ` John David Anglin
2004-04-08 21:01 ` Jan Hubicka
2004-04-08 21:16 ` Kaveh R. Ghazi
2004-04-08 21:19 ` Jan Hubicka
2004-04-09 20:06 ` Jan Hubicka
2004-04-30 15:11 ` David Edelsohn
2004-04-30 15:29 ` Kaveh R. Ghazi
2004-04-30 16:21 ` David Edelsohn
2004-05-02 13:49 ` Kaveh R. Ghazi
2004-04-09 20:06 ` Kaveh R. Ghazi
2004-04-09 20:06 ` Jan Hubicka
2004-04-09 20:06 ` Kaveh R. Ghazi
2004-04-09 20:06 ` John David Anglin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).