On 10/17/2016 09:29 PM, Andreas Krebbel1 wrote:
>> Here is a patch implementing what I think has been discussed in this
> thread.
>>
>> OK?
>
> Looks good to me.
>
> Uli, do you agree with that change for S/390 or would you rather see us
> fixing the float_t type definition in Glibc?
I had a d
> Here is a patch implementing what I think has been discussed in this
thread.
>
> OK?
Looks good to me.
Uli, do you agree with that change for S/390 or would you rather see us
fixing the float_t type definition in Glibc?
-Andreas-
Hi,
On Fri, Oct 07, 2016 at 10:34:25AM +0200, Andreas Krebbel wrote:
> On 10/04/2016 03:42 PM, Joseph Myers wrote:
> > On Tue, 4 Oct 2016, Andreas Krebbel wrote:
> >
> >>> (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like
> >>> EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end
On Wed, 12 Oct 2016, Andreas Krebbel wrote:
> Regarding (c) imagemagick is also affected (it wasn't really clear from
> my last email). Since it is a widely used lib I think this counts as a
> blocker. The ABI relevant MagickRealType depends on the size of float_t:
I think distributions manage
On 10/07/2016 03:11 PM, Joseph Myers wrote:
> On Fri, 7 Oct 2016, Andreas Krebbel wrote:
>
>> wrt (c): float_t appears to be more widely used than I expected. But the
>> only hits which might indicate potential ABI problems where in clucene
>> and libassa. (I've scanned the header files of about
On Fri, 7 Oct 2016, Andreas Krebbel wrote:
> wrt (c): float_t appears to be more widely used than I expected. But the
> only hits which might indicate potential ABI problems where in clucene
> and libassa. (I've scanned the header files of about 25k Ubuntu source
> packages).
If it's two out o
On 10/04/2016 03:42 PM, Joseph Myers wrote:
> On Tue, 4 Oct 2016, Andreas Krebbel wrote:
>
>>> (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like
>>> EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end
>>> does. It would mean that the default FLT_EVAL_METHOD is 0, which is a
>
On Tue, 4 Oct 2016, Andreas Krebbel wrote:
> > (b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like
> > EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end
> > does. It would mean that the default FLT_EVAL_METHOD is 0, which is a
> > more accurate description of how the compiler
On 09/30/2016 07:57 PM, Joseph Myers wrote:
> On Fri, 30 Sep 2016, Jeff Law wrote:
>
>> On 09/30/2016 11:34 AM, Joseph Myers wrote:
>>> On Fri, 30 Sep 2016, James Greenhalgh wrote:
>>>
+ case EXCESS_PRECISION_TYPE_STANDARD:
+ case EXCESS_PRECISION_TYPE_IMPLICIT:
+ /* Othe
On Fri, Sep 30, 2016 at 05:57:45PM +, Joseph Myers wrote:
> On Fri, 30 Sep 2016, Jeff Law wrote:
>
> > On 09/30/2016 11:34 AM, Joseph Myers wrote:
> > > On Fri, 30 Sep 2016, James Greenhalgh wrote:
> > >
> > > > + case EXCESS_PRECISION_TYPE_STANDARD:
> > > > + case EXCESS_PRECISION_
On Fri, 30 Sep 2016, Jeff Law wrote:
> On 09/30/2016 11:34 AM, Joseph Myers wrote:
> > On Fri, 30 Sep 2016, James Greenhalgh wrote:
> >
> > > + case EXCESS_PRECISION_TYPE_STANDARD:
> > > + case EXCESS_PRECISION_TYPE_IMPLICIT:
> > > + /* Otherwise, the excess precision we want when we ar
On 09/30/2016 11:34 AM, Joseph Myers wrote:
On Fri, 30 Sep 2016, James Greenhalgh wrote:
+ case EXCESS_PRECISION_TYPE_STANDARD:
+ case EXCESS_PRECISION_TYPE_IMPLICIT:
+ /* Otherwise, the excess precision we want when we are
+ in a standards compliant mode, and the impli
On Fri, 30 Sep 2016, James Greenhalgh wrote:
> + case EXCESS_PRECISION_TYPE_STANDARD:
> + case EXCESS_PRECISION_TYPE_IMPLICIT:
> + /* Otherwise, the excess precision we want when we are
> +in a standards compliant mode, and the implicit precision we
> +provide can be
Hi,
This patch ports the logic from s390's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an s390-none-linux toolchain and running
s390.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code wh
14 matches
Mail list logo
