On 6/27/19 12:40 PM, Richard Biener wrote:
> On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek <ja...@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
