Hi,
This patch implements built-ins to support __float128 on 64-bit PowerPC.
This is a minimum set of built-ins required for use by glibc. The following
six built-ins are supported:
__builtin_absf128
__builtin_copysignf128
__builtin_huge_valf128
__builtin_inff128
__builtin_nanf128
__
On Wed, 22 Jun 2016, Bill Schmidt wrote:
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions. All new tests pass except for the test for vspltish in
> the infinity test; this relies on a patch in progress to fix things so we
> generate that instead of an inferior sequ
Hi Joseph,
That's indeed preferable for the long term -- given how close we are to the
cutoff for 6.2, though, I'm worried about adding any new dependencies for
getting this upstream. I'd suggest that we go ahead with reviewing this
patch in the short term, and I'll be happy to work with you l
On Wed, 22 Jun 2016, Bill Schmidt wrote:
> Hi Joseph,
>
> That's indeed preferable for the long term -- given how close we are to the
> cutoff for 6.2, though, I'm worried about adding any new dependencies for
> getting this upstream. I'd suggest that we go ahead with reviewing this
> patch i
> On Jun 22, 2016, at 6:27 PM, Joseph Myers wrote:
>
> On Wed, 22 Jun 2016, Bill Schmidt wrote:
>
>> Hi Joseph,
>>
>> That's indeed preferable for the long term -- given how close we are to the
>> cutoff for 6.2, though, I'm worried about adding any new dependencies for
>> getting this upst
On Wed, 22 Jun 2016, Bill Schmidt wrote:
> I understand that this is what we want for GCC 7. My current concern is to
> get my patch included in GCC 6.2, where I can't be polluting common code.
> To get it accepted there, I first need this code approved in mainline. So I
> am quite willing to mo
> On Jun 22, 2016, at 8:10 PM, Bill Schmidt wrote:
>
>> On Jun 22, 2016, at 6:27 PM, Joseph Myers wrote:
>>
>> (b) for trunk, having an insn pattern infkf1 for a built-in function that
>> loads a constant is not appropriate (other insn patterns to optimize the
>> architecture-independent bui
Joseph Myers writes:
> On Wed, 22 Jun 2016, Bill Schmidt wrote:
>> The fact that I hook this built-in directly to a pattern named infkf1
>> doesn't seem to preclude anything you suggest. I named it this way
>> on the off-chance that inf1 becomes a standard pattern in the
>> future, in which case
> On Jun 27, 2016, at 12:41 PM, Richard Sandiford
> wrote:
>
> Joseph Myers writes:
>> On Wed, 22 Jun 2016, Bill Schmidt wrote:
>>> The fact that I hook this built-in directly to a pattern named infkf1
>>> doesn't seem to preclude anything you suggest. I named it this way
>>> on the off-chanc