https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64980
--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- Created attachment 34751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34751&action=edit Proposed Fix OK, now I see the original test case exposes an aliasing violation when node is passed to node._vptr->get_d_position(&node) struct __class_muli_trapezium_Muli_trapezium_node_class_t_p node; but muli_trapezium_get_d_position (struct __class_muli_trapezium_Muli_trapezium_t_t & restrict this) So my previous patch is just not aggressive enough. How about the attached patch, which looks like it simplifies the code. I will post this new patch, which combines Mikael's patch and fixes class_41.f03 and these test cases, by rewriting _all_ cases where the class type is different, either because of different attributes, or because of a derived base type even when the other attributes are identical as in class_41.f03. 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; Given the complexity of the generated code, it would be good to have a positive test, instead of a compile-only test. Could you please propose a positive test case for this? Thanks, Bernd.
