[PING][PATCH] constrain one character optimization to one character stores (PR 90989)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01506.html

Jeff (et al.), do you have any outstanding questions/concerns
about the patch?

Martin

On 6/27/19 4:30 PM, Jeff Law wrote:
> On 6/27/19 12:40 PM, Richard Biener wrote:
>> On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
>>>> The LHS is unsigned short so handle_char_store would not be called
>>>> because of the check in the caller.  You would need something like:
>>>>
>>>>    MEM <char[2]> [(char *)&x] = { 'a', 'b' };
>>>
>>> This is invalid, because the rhs is non-empty CONSTRUCTOR that doesn't
>>> have
>>> VECTOR_TYPE - verify_gimple_assign_single has:
>>>     case CONSTRUCTOR:
>>>       if (TREE_CODE (rhs1_type) == VECTOR_TYPE)
>>> ...
>>>       else if (CONSTRUCTOR_NELTS (rhs1) != 0)
>>>         {
>>>           error ("non-vector %qs with elements", code_name);
>>>           debug_generic_stmt (rhs1);
>>>           return true;
>>>         }
>>>
>>> But
>>>   MEM <char[2]> [(char *)&x] = MEM <char[2]> [(char *)"ab"];
>>> is valid.  Or = {} would be valid too, even for array stores.
>>
>> And you can of course write GIMPLE unit tests for the pass using the GIMPLE FE.
> Yea.  And this may ultimately be the way we should think about testing
> this kind of stuff where GIMPLE might allow something that is impossible
> to express in C or C++.
> 
> Realistically I don't think any of us can be expected to know the dusty
> corners of every language.  But we ought to be able to reason about
> what's valid gimple and write tests using the gimple front-end to verify
> how a particular construct would be handled.
> 
> jeff
>