Hi Segher,
on 2021/11/30 上午8:16, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 28, 2021 at 04:13:40PM +0800, Kewen.Lin wrote:
>> PR target/102347
>> * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
>> mask check.
>
> (Don't wrap lines early please).
>
Fixed.
Hi!
On Tue, Sep 28, 2021 at 04:13:40PM +0800, Kewen.Lin wrote:
> PR target/102347
> * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
> mask check.
(Don't wrap lines early please).
Okay for trunk and all backports. Thanks!
Segher
Hi!
On Mon, Oct 11, 2021 at 02:30:42PM +0800, Kewen.Lin wrote:
> > If we do need a band-aid for 10 and 11 (and we do as far as I can see),
> > I'd like to see one for just MMA there, and let all other badness fade
> > into history. Unless you can convince me (in the patch / commit
> > message) th
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
>> on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> As the discussion in PR102347,
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
>
> on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As the discussion in PR102347, cu
Hi,
As the discussions and the testing result under the main thread, this
patch would be safe.
Ping for this:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html
BR,
Kewen
on 2021/9/28 下午4:13, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As the discussion in PR102347, currently
Hi Bill!
on 2021/10/13 上午12:36, Bill Schmidt wrote:
> Hi Kewen,
>
> On 10/11/21 1:30 AM, Kewen.Lin wrote:
>> Hi Segher,
>>
>> Thanks for the comments.
>>
>> on 2021/10/1 上午6:13, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Thu, Sep 30, 2021 at 11:06:50AM +0800, Kewen.Lin wrote:
>>>
>>> [ huge sni
Hi Kewen,
On 10/11/21 1:30 AM, Kewen.Lin wrote:
> Hi Segher,
>
> Thanks for the comments.
>
> on 2021/10/1 上午6:13, Segher Boessenkool wrote:
>> Hi!
>>
>> On Thu, Sep 30, 2021 at 11:06:50AM +0800, Kewen.Lin wrote:
>>
>> [ huge snip ]
>>
>>> Based on the understanding and testing, I think it's safe
Hi Segher,
Thanks for the comments.
on 2021/10/1 上午6:13, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Sep 30, 2021 at 11:06:50AM +0800, Kewen.Lin wrote:
>
> [ huge snip ]
>
>> Based on the understanding and testing, I think it's safe to adopt this
>> patch.
>> Do both Peter and you agree the r
Hi!
On Thu, Sep 30, 2021 at 11:06:50AM +0800, Kewen.Lin wrote:
[ huge snip ]
> Based on the understanding and testing, I think it's safe to adopt this patch.
> Do both Peter and you agree the rs6000_expand_builtin will catch the invalid
> built-in?
> Is there some special case which probably es
Hi Bill,
on 2021/9/29 下午7:59, Bill Schmidt wrote:
> Hi Kewen,
>
> On 9/28/21 9:34 PM, Kewen.Lin wrote:
>> Hi Bill,
>>
>> Thanks for your prompt comments!
>>
>> on 2021/9/29 上午3:24, Bill Schmidt wrote:
>>> Hi Kewen,
>>>
>>> Although I agree that what we do now is tragically bad (and will be fixed
Hi Kewen,
On 9/28/21 9:34 PM, Kewen.Lin wrote:
> Hi Bill,
>
> Thanks for your prompt comments!
>
> on 2021/9/29 上午3:24, Bill Schmidt wrote:
>> Hi Kewen,
>>
>> Although I agree that what we do now is tragically bad (and will be fixed in
>> the builtin rewrite), this seems a little too cavalier to
Hi Bill,
Thanks for your prompt comments!
on 2021/9/29 上午3:24, Bill Schmidt wrote:
> Hi Kewen,
>
> Although I agree that what we do now is tragically bad (and will be fixed in
> the builtin rewrite), this seems a little too cavalier to remove all checking
> during initialization without adding
On 9/28/21 2:24 PM, Bill Schmidt via Gcc-patches wrote:
> Unless you are planning to do a backport, I think the proper way forward
> here is to just wait for the new builtin support to land. In the new code,
> we initialize all built-ins up front, and check properly at expansion time
> whether the
Hi Kewen,
Although I agree that what we do now is tragically bad (and will be fixed in
the builtin rewrite), this seems a little too cavalier to remove all checking
during initialization without adding any checking somewhere else. :-) We still
need to check for invalid usage when the builtin i
Hi,
As the discussion in PR102347, currently builtin_decl is invoked so
early, it's when making up the function_decl for builtin functions,
at that time the rs6000_builtin_mask could be wrong for those
builtins sitting in #pragma/attribute target functions, though it
will be updated properly later
16 matches
Mail list logo