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 fe
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 hardwa
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,
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 ju
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
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
> t
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 imple
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
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
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 v
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 a
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 ever
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
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 calculati
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, chec
16 matches
Mail list logo
