Hi, Adhemerval
I cornered Honza during his visit to IBM Research to help me
understand my concerns with the function.
The code for *hold does:
+ tree fenv_var = create_tmp_var (double_type_node, NULL);
+
+ tree hold_mffs = build2 (MODIFY_EXPR, void_type_node, fenv_var, call_mffs);
+
+ tree
On Thu, 4 Sep 2014, Adhemerval Zanella wrote:
While at it, may I propose another change on top of this?
I've noticed the test case is rather slow, it certainly takes much more
time than the average one, I've seen elapsed times of well over a minute
on reasonably fast hardware and
On Wed, 3 Sep 2014, Uros Bizjak wrote:
So I think the default timeout that's used for really quick tests should
be extended a bit. I propose a factor of 2, just not to make it too
excessive, at least for the beginning (maybe it'll have to be higher
eventually).
Or you can just lower
On 03-09-2014 11:01, Maciej W. Rozycki wrote:
On Tue, 2 Sep 2014, Adhemerval Zanella wrote:
Ping.
On 19-08-2014 13:54, Adhemerval Zanella wrote:
Ping.
On 06-08-2014 17:21, Adhemerval Zanella wrote:
On 01-08-2014 12:31, Joseph S. Myers wrote:
On Thu, 31 Jul 2014, David Edelsohn wrote:
On Tue, 2 Sep 2014, Adhemerval Zanella wrote:
Ping.
On 19-08-2014 13:54, Adhemerval Zanella wrote:
Ping.
On 06-08-2014 17:21, Adhemerval Zanella wrote:
On 01-08-2014 12:31, Joseph S. Myers wrote:
On Thu, 31 Jul 2014, David Edelsohn wrote:
Thanks for implementing the FENV
Hello!
While at it, may I propose another change on top of this?
I've noticed the test case is rather slow, it certainly takes much more
time than the average one, I've seen elapsed times of well over a minute
on reasonably fast hardware and occasionally a timeout midway through even
though
On Wed, 3 Sep 2014, Maciej W. Rozycki wrote:
(floating-point environment is of course unsupported for soft-float
targets and for the SPE FPU another change is required to implement
floating-point environment handling to complement one proposed here).
Support for SPE will depend on the C
Ping.
On 19-08-2014 13:54, Adhemerval Zanella wrote:
Ping.
On 06-08-2014 17:21, Adhemerval Zanella wrote:
On 01-08-2014 12:31, Joseph S. Myers wrote:
On Thu, 31 Jul 2014, David Edelsohn wrote:
Thanks for implementing the FENV support. The patch generally looks
good to me.
My one
Ping.
On 06-08-2014 17:21, Adhemerval Zanella wrote:
On 01-08-2014 12:31, Joseph S. Myers wrote:
On Thu, 31 Jul 2014, David Edelsohn wrote:
Thanks for implementing the FENV support. The patch generally looks
good to me.
My one concern is a detail in the implementation of update. I do not
On 01-08-2014 12:31, Joseph S. Myers wrote:
On Thu, 31 Jul 2014, David Edelsohn wrote:
Thanks for implementing the FENV support. The patch generally looks
good to me.
My one concern is a detail in the implementation of update. I do not
have enough experience with GENERIC to verify the
On Thu, 31 Jul 2014, David Edelsohn wrote:
Thanks for implementing the FENV support. The patch generally looks
good to me.
My one concern is a detail in the implementation of update. I do not
have enough experience with GENERIC to verify the details and it seems
like it is missing
Thanks for implementing the FENV support. The patch generally looks good to me.
My one concern is a detail in the implementation of update. I do not
have enough experience with GENERIC to verify the details and it seems
like it is missing building an outer COMPOUND_EXPR containing
update_mffs
On Thu, 3 Jul 2014, Adhemerval Zanella wrote:
+ /* Generates the equivalent of feclearexcept (FE_ALL_EXCEPT):
+
+ double fenv_clear = __builtin_mffs ();
+ *(uint64_t)fenv_clear = 0xLL;
+ __builtin_mtfsf (0xff, fenv_clear); */
+
+ /* Mask to clear everything
Ping.
On 03-07-2014 18:08, Adhemerval Zanella wrote:
This patch implements the TARGET_ATOMIC_ASSIGN_EXPAND_FENV for
powerpc-fpu. I have to adjust current c11-atomic-exec-5 testcase
because for IBM long double 0 += LDBL_MAX might generate
overflow/underflow in internal __gcc_qadd
Adhemerval,
This looks very good. Thanks for helping with the FENV implementation.
I will discuss this with some GIMPLE experts during Cauldron. I want
to check that the GIMPLE is correct before approving this.
Thanks, David
This patch implements the TARGET_ATOMIC_ASSIGN_EXPAND_FENV for
powerpc-fpu. I have to adjust current c11-atomic-exec-5 testcase
because for IBM long double 0 += LDBL_MAX might generate
overflow/underflow in internal __gcc_qadd calculations.
The c11-atomic-exec-5 now passes for linux/powerpc,
16 matches
Mail list logo
