> This is something of a corner case, where gfc_conv_expr comes back > with a SAVE_EXPR, in the case of complex, scalar, coarray lvalues. The > first field of the SAVE_EXPR is a perfectly viable expression to > assign to, so I have taken that. If anybody out there has a better > solution, please speak up!
If the SAVE_EXPR is a useless one, it should have SAVE_EXPR_RESOLVED_P(…) be true. Then you can simply discard it as you’re doing. If not, we need to created a temp variable, as simply removing the SAVE_EXPR will lead to multiple side-effects evalution in some cases otherwise. But I’m curious as to where the SAVE_EXPR is created. As far as I can tell, all SAVE_EXPR in our front-end are created by explicit calls to save_expr(), of which there are very few. I don’t see which one is the culprit here :( But creating a SAVE_EXPR for a LHS is definitely not a good idea in the first place. FX
