Hello.
I have come up with the testcases for fadd variants and the following
patch comes with them. Again, the patch follows the points mentioned
above and if good to go, I will post it to the gcc-patches. The patch
bootstraps and survives regression tests.
Thanks,
Tejas
On Fri, 2 Aug 2019 at 16:
Hello.
I have made this patch strictly considering the following points
Joseph mentioned in his initial email :
> * The narrowing functions, e.g. fadd, faddl, daddl, are a bit different
> from most other built-in math.h functions because the return type is
> different from the argument types. You
Hello.
> fold_const_fadd), for example I am not sure what the return values are
> supposed to mean, and add a run-time testcase(s) and I'd say you are
> done for now
I modeled real_fadd function on a similar function, real_nextafter
which would take three arguments. Just as overflow and underflow
Hi,
On Sat, Jul 27 2019, Tejas Joshi wrote:
> Hello.
>
>>> You'll need something different from CASE_MATHFN - these are a different
>>> kind of functions that need handling in a different way, because they are
>>> parametrized over certain *pairs* of types, rather than over a single
>>> type.
>> f
Hello.
>> You'll need something different from CASE_MATHFN - these are a different
>> kind of functions that need handling in a different way, because they are
>> parametrized over certain *pairs* of types, rather than over a single
>> type.
> first phase, please just directly test for in the code
On Tue, 23 Jul 2019, Tejas Joshi wrote:
> Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand
> normal, F and L variants which are assigned to respective fcode
> built_in_function. This makes any function defined in builtins.def to
> have F and L variants mandatory. How these narro
Hi all,
I have some doubts regarding narrowing functions. Functions like fadd
have different variants like fadd, faddl and daddl. These functions
differs from general floating point functions which have float and
long double argument types. These functions are defined in
builtins.def like floor, fl
Tejas Joshi writes:
> Hello.
> I have added fadd variants in builtins.def. For fadd and faddl
> variants, I had to introduce builtin function types in
> builtin-types.def :
>
> +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
> +BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
> +DEF_FUNCTION_T
Hello.
I have added fadd variants in builtins.def. For fadd and faddl
variants, I had to introduce builtin function types in
builtin-types.def :
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDO
Hello.
I am trying to add fadd function variants and as fadd takes two
arguments, the function should be called from fold_const_call_sss ().
The function is closely modeled on function calls and cases according
to real_nextafter (), also used gdb to look at backtrace. Although I
have made changes a
Hello.
Functions like fadd, faddl take two arguments, do the addition and
return the answer in narrower precision than the argument type. The
thing that might be helpful is using the do_add function directly, if
appropriate?
The thing to consider about narrowed down return type is how it can be
ach
11 matches
Mail list logo
