https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- (In reply to Mikael Morin from comment #9) > > (In reply to Bernd Edlinger from comment #8) > > The call of get_d_position is now rewritten as follows: > > > > this.22 = VIEW_CONVERT_EXPR<struct > > __class_muli_trapezium_Muli_trapezium_t_t>(node); > > D.3752 = node._vptr->get_d_position (&this.22); > > this.23 = VIEW_CONVERT_EXPR<struct > > __class_muli_trapezium_Muli_trapezium_t_t>(node); > > D.3754 = &this.23; > > D.3755 = D.3754->_data->dim; > > D.3756 = (integer(kind=8)) D.3755 + -1; > > > It seems to me that the second VIEW_CONVERT_EXPR is not necessary. > If that's correct, there should be two references, one through > VIEW_CONVERT_EXPR for the function call, and one without VIEW_CONVERT_EXPR > to use for interface mapping (to get the resulting size). Yes, but I have no idea how to know how the result is going to be used, in gfc_conv_procedure_call, line 4544. If you have an idea how to detect this case, that would be great. If if is later passed to a subroutine, it should be a VIEW_CONVERT_EXPR, But if it is later fixed in gfc_apply_interface_mapping_to_expr, then it would be better to avoid the VIEW_CONVERT_EXPR in the first place. Until yesterday, I thought the result is always used in a procedure call context, and I thought we only have aliasing violations on different variations of the same principal class, but that was also wrong. The good news is: The code should be correct this way, and if we are lucky the optimizer will do its job and optimize that redundant assignment away.
