on 2022/9/1 22:17, Peter Bergner wrote:
> On 9/1/22 3:29 AM, Kewen.Lin wrote:
>>> I have no idea why ptr_vector_*_type would behave differently here than
>>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>>> fixed it for me, so that's why I went with it. :-) Maybe this i
On Thu, Sep 01, 2022 at 04:28:56PM +0800, Kewen.Lin wrote:
> tree.def has some note about VIEW_CONVERT_EXPR, it quite matches what Segher
> replied.
> In my experience, VIEW_CONVERT_EXPR are used a lot for vector type conversion.
It is needed whenever vector types are not compatible otherwise.
V4
On 9/1/22 3:29 AM, Kewen.Lin wrote:
>> I have no idea why ptr_vector_*_type would behave differently here than
>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>> fixed it for me, so that's why I went with it. :-) Maybe this is a bug
>> in lto???
>
> Thanks for your tim
>>> ...and of course, now I can't recreate that issue at all and the
>>> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
>>> Maybe the behavior changed since my PR106017 fix went in???
>>
>> That is my best guess as well. But, how did that help this test?
>
> It didn't. :-) Du
+ if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>>>
>>> This line looks unexpected, the former is type char while the latter is
>>> type __vector_pair *.
>>>
>>> I guess you meant to compare the type of pointer type like:
>>>
>>>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (s
On 8/31/22 6:08 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
>> The problem goes away if I use use -O1 or above, I drop -flto or I use
>> the code I originally posted without the ptr_vector_*_type
>>
>> The assert in gimple_canonical_types_compatibl
On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
> The problem goes away if I use use -O1 or above, I drop -flto or I use
> the code I originally posted without the ptr_vector_*_type
>
> The assert in gimple_canonical_types_compatible_p() we're hitting is:
> 13673 default:
> 1367
On 8/31/22 3:51 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
>> Question for my own education, when would you use VIEW_CONVERT_EXPR over
>> NOP_EXPR?
>
> VIEW_CONVERT_EXPR is essentially a bit_cast. Only use it when you need
> that, it is sub-opt
On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
> ...and of course, now I can't recreate that issue at all and the
> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
> Maybe the behavior changed since my PR106017 fix went in???
That is my best guess as well. But, h
On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> - tree src_type = TREE_TYPE (src_ptr);
>>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> + ? build_pointer_type (v
Hi!
On Fri, Aug 26, 2022 at 10:50:00PM -0500, Peter Bergner wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
(The perfect tense of cast is "cast").
> machinery and we end up using the base
On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> - tree src_type = TREE_TYPE (src_ptr);
>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> + ? build_pointer_type (vector_quad_type_node)
>> + :
Hi Peter,
Thanks for the patch! Some comments are inline as below.
on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
> machinery and we end
I'd like to ping the following patch.
Peter
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html
Message-ID:
>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
>machinery and we e
When we expand an MMA disassemble built-in with C++ using a pointer that
is casted to a valid MMA type, the type isn't passed down to the expand
machinery and we end up using the base type of the pointer which leads to
an ICE. This patch enforces we always use the correct MMA type regardless
of th
15 matches
Mail list logo
