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 <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
