Fix wrong SRA with VIEW_CONVERT_EXPR and reverse SSO
authorEric Botcazou <ebotcazou@adacore.com>
Fri, 13 May 2022 09:15:08 +0000 (11:15 +0200)
committerEric Botcazou <ebotcazou@adacore.com>
Fri, 13 May 2022 09:19:01 +0000 (11:19 +0200)
commit7b844206ec51931d0a81aa4e4fa3b62f6ecef0ca
tree13319be8c4b929b89715cafc316236e6273a7800
parentc77e4873b14bd84fc6715db8980ce14886b28906
Fix wrong SRA with VIEW_CONVERT_EXPR and reverse SSO

Most cases of VIEW_CONVERT_EXPRs involving reverse scalar storage order are
disqualified for SRA because they are storage_order_barrier_p, but you can
still have a VIEW_CONVERT_EXPR to a regular composite type being applied to
a component of a record type with reverse scalar storage order.

In this case the bypass for !useless_type_conversion_p in sra_modify_assign,
albeit already heavily guarded, triggers and may generate wrong code, so the
patch makes sure that it does only when the SSO is the same on both side.

gcc/
* tree-sra.cc (sra_modify_assign): Check that scalar storage order
is the same on the LHS and RHS before rewriting one with the model
of the other.
gcc/testsuite/
* gnat.dg/sso17.adb: New test.
gcc/testsuite/gnat.dg/sso17.adb [new file with mode: 0644]
gcc/tree-sra.cc