Re: [PATCH] rs6000: Mirror fix for PR102347 into the new builtins support

2021-12-01 Thread Bill Schmidt via Gcc-patches
On 12/1/21 11:21 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 01, 2021 at 09:29:42AM -0600, Bill Schmidt wrote:
>> Recently Kewen fixed a problem in the old builtins support where
>> rs6000_builtin_decl prematurely indicated that a target builtin is
>> unavailable.  This also needs to be done for the new builtins support, but in
>> this case we have to ensure the error message is still produced from the
>> overload support in rs6000-c.c.  Unfortunately, this is less straightforward
>> than it could be, because header file includes need to be adjusted to make 
>> this
>> happen.  Someday we'll consolidate all the builtin code in one file and this
>> won't have to be so ugly.
>>
>> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.  Is 
>> this
>> okay for trunk?
> This is okay for trunk.  Thanks!
>
> Is there some place we can store what original builtin was used when
> some overload is resolved?  Just in the new builtin code, don't spend
> time on the old stuff :-)

I think we can do much better, with a little work.  The macros are a little
problematic, but I have ideas about how to make this better in a future
patch.  (There's a fair amount of test suite fallout, so it should wait.)

Thanks for the review!

Bill
>
>
> Segher


Re: [PATCH] rs6000: Mirror fix for PR102347 into the new builtins support

2021-12-01 Thread Segher Boessenkool
Hi!

On Wed, Dec 01, 2021 at 09:29:42AM -0600, Bill Schmidt wrote:
> Recently Kewen fixed a problem in the old builtins support where
> rs6000_builtin_decl prematurely indicated that a target builtin is
> unavailable.  This also needs to be done for the new builtins support, but in
> this case we have to ensure the error message is still produced from the
> overload support in rs6000-c.c.  Unfortunately, this is less straightforward
> than it could be, because header file includes need to be adjusted to make 
> this
> happen.  Someday we'll consolidate all the builtin code in one file and this
> won't have to be so ugly.
> 
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.  Is this
> okay for trunk?

This is okay for trunk.  Thanks!

Is there some place we can store what original builtin was used when
some overload is resolved?  Just in the new builtin code, don't spend
time on the old stuff :-)


Segher