On Wed, 22 Jun 2016, Michael Meissner wrote:
> On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> > And I don't understand the layout_type change either - it looks to me
> > it could just have used
> >
> > SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE
> > (TREE_TYPE (typ
On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> And I don't understand the layout_type change either - it looks to me
> it could just have used
>
> SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE
> (TREE_TYPE (type;
>
> and be done with it. To me that looks a lot s
On Tue, 21 Jun 2016, Michael Meissner wrote:
> > I'm now working on support for TS 18661-3 _FloatN / _FloatNx type names
> > (keywords), constant suffixes and addiitions. That will
> > address, for C, the need to use modes for complex float128 (bug 32187) by
> > allowing the standard _Complex
On Thu, Jun 16, 2016 at 10:06:48PM +, Joseph Myers wrote:
> On Wed, 15 Jun 2016, Michael Meissner wrote:
>
> > Note, I do feel the front ends should be modified to allow __complex
> > __float128
> > directly rather than having to use an attribute to force the complex type
> > (and
> > to use
On Wed, 15 Jun 2016, Michael Meissner wrote:
> Note, I do feel the front ends should be modified to allow __complex
> __float128
> directly rather than having to use an attribute to force the complex type (and
> to use mode(TF) on x86 or mode(KF) on PowerPC). It would clean up both x86
> and
>
On Wed, Jun 15, 2016 at 03:12:55PM +0200, Richard Biener wrote:
> On Wed, 15 Jun 2016, Michael Meissner wrote:
> > Eventually, I decided to punt having to have explicit paths for widening. I
> > used fractional modes for IFmode (ibm long double format) and KFmode (IEEE
> > 128-bit format). IFmode
On Wed, 15 Jun 2016, Michael Meissner wrote:
> On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> > On Tue, 14 Jun 2016, Bill Schmidt wrote:
> >
> > > Hi Richard,
> > >
> > > As nobody else has replied, let me take a stab at this one.
> > >
> > > > On Jun 10, 2016, at 2:06 AM, Ri
On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> On Tue, 14 Jun 2016, Bill Schmidt wrote:
>
> > Hi Richard,
> >
> > As nobody else has replied, let me take a stab at this one.
> >
> > > On Jun 10, 2016, at 2:06 AM, Richard Biener wrote:
> > >
> > > On Thu, 9 Jun 2016, Michael
On Tue, 14 Jun 2016, Bill Schmidt wrote:
> Hi Richard,
>
> As nobody else has replied, let me take a stab at this one.
>
> > On Jun 10, 2016, at 2:06 AM, Richard Biener wrote:
> >
> > On Thu, 9 Jun 2016, Michael Meissner wrote:
> >
> >> I'm including the global reviewers on the list. I just
Hi Richard,
As nobody else has replied, let me take a stab at this one.
> On Jun 10, 2016, at 2:06 AM, Richard Biener wrote:
>
> On Thu, 9 Jun 2016, Michael Meissner wrote:
>
>> I'm including the global reviewers on the list. I just want to be sure that
>> there is no problem installing these
On Thu, 9 Jun 2016, Michael Meissner wrote:
> I'm including the global reviewers on the list. I just want to be sure that
> there is no problem installing these patches on the GCC 6.2 branch. While it
> is technically an enchancement, it is needed to be able to install the glibc
> support that i
On Thu, Jun 09, 2016 at 04:06:53PM -0400, Michael Meissner wrote:
> I'm including the global reviewers on the list. I just want to be sure that
> there is no problem installing these patches on the GCC 6.2 branch. While it
> is technically an enchancement, it is needed to be able to install the g
I'm including the global reviewers on the list. I just want to be sure that
there is no problem installing these patches on the GCC 6.2 branch. While it
is technically an enchancement, it is needed to be able to install the glibc
support that is needed to complete the work to add IEEE 128-bit flo
13 matches
Mail list logo
