diff options
author | Jason Merrill <jason@redhat.com> | 2022-10-03 17:16:38 -0400 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2022-10-05 10:09:51 -0400 |
commit | 49192c41de94b2746cd33366134b6aeaefa6ca2a (patch) | |
tree | 59eea4766af245e0a5857fbdd6e4a2697c799bbf /gcc/fortran | |
parent | 7d935cdd1a6772699ec0ab4f93711928ca4d30a1 (diff) | |
download | gcc-49192c41de94b2746cd33366134b6aeaefa6ca2a.zip gcc-49192c41de94b2746cd33366134b6aeaefa6ca2a.tar.gz gcc-49192c41de94b2746cd33366134b6aeaefa6ca2a.tar.bz2 |
c++: lvalue_kind tweak
I was wondering how lvalue_kind handles VIEW_CONVERT_EXPR; in cases where
the type actually changes, it should have the same prvalue->xvalue effect as
ARRAY_REF, since we need to materialize a temporary to get an object we can
reinterpret as another type.
Currently this only fires on builtin-shufflevector-3.c, where we use
VIEW_CONVERT_EXPR to reinterpret a vector as an array.
REALPART_EXPR and IMAGPART_EXPR should also be treated like COMPONENT_REF.
PREINCREMENT_EXPR and PREDECREMENT_EXPR should only be applied to glvalues,
but if for some reason they were applied to a prvalue this would be correct.
TRY_CATCH_EXPR around a prvalue is also questionable, but this is the right
handling.
gcc/cp/ChangeLog:
* tree.cc (lvalue_kind) [VIEW_CONVERT_EXPR]: Change prvalue to
xvalue.
Diffstat (limited to 'gcc/fortran')
0 files changed, 0 insertions, 0 deletions