Created attachment 41572 [details] Exemplar target is x86_64 The attached ICEs in expr.c, lowering the second call to Quux to RTL: <materialize-all-clones> <simdclone> void Frob(const Good&, const Bad&)during RTL pass: expand bug.ii: In function 'void Frob(const Good&, const Bad&)': bug.ii:20:13: internal compiler error: in convert_move, at expr.c:231 Quux (bad.val); ~~~~^~~ 0xcc9f5b convert_move(rtx_def*, rtx_def*, int) /data/users/nathans/trunk/obj/x86_64/../../src/gcc/expr.c:231 0xcd9bd1 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) /data/users/nathans/trunk/obj/x86_64/../../src/gcc/expr.c:5631 0xcd8038 expand_assignment(tree_node*, tree_node*, bool) /data/users/nathans/trunk/obj/x86_64/../../src/gcc/expr.c:5323 0xb80c31 expand_gimple_stmt_1 /data/users/nathans/trunk/obj/x86_64/../../src/gcc/cfgexpand.c:3645 0xb8101c expand_gimple_stmt /data/users/nathans/trunk/obj/x86_64/../../src/gcc/cfgexpand.c:3741 0xb880d6 expand_gimple_basic_block /data/users/nathans/trunk/obj/x86_64/../../src/gcc/cfgexpand.c:5745 0xb89b06 execute /data/users/nathans/trunk/obj/x86_64/../../src/gcc/cfgexpand.c:6354 The Good struct is passed just fine. Both Good and Bad have the same size and alignment. I suspect different modes though.
Upon investigation, I discover that Bad::val field_decl gets BLKmode, because vector_type_mode is being used outside of an AVX target option region. Simply using TYPE_MODE_RAW in layout_type dies horribly. in expansion store_expr_with_bounds uses get_inner_reference to extract the field, and that returns a BLKmode MEM_REF. it then tries to use convert_move to turn that into V8SFmode, but convert_move's not expecting a BLKmode source. Not sure if the FIELD_DECL's mode is the error, or store_expr_with_bounds needs to become smarter?
This kind of arbitrary mixing of ISA options on types vs functions isn't really supported. All that context dependent mode selection stuff is a hack as it doesn't extend to containers or as you see decls in general. I believe I've seen dups of this issue.
Fixed in GCC 6.5, 7.3, 8+ by the patch which fixed PR 85496. The code is not the best generated code but works though.