On Tue, May 14, 2013 at 12:22:05PM +0200, Richard Biener wrote: > > The problem is that in the first testcase, the VAR_DECL c (guess also b and > > a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector > > types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode > > (it has been laid out while -mno-avx has been the current) and also > > DECL_RTL which is a mem:BLK. Guess expr.c would need to special case > > TREE_STATIC or DECL_EXTERNAL VAR_DECLs with vector type, if they have > > DECL_MODE BLKmode, but TYPE_MODE some vector type, just adjust the MEM > > to the desired mode?
--- gcc/expr.c.jj 2013-05-14 08:25:40.000000000 +0200 +++ gcc/expr.c 2013-05-14 12:55:46.331983406 +0200 @@ -9310,6 +9310,8 @@ expand_expr_real_1 (tree exp, rtx target set_curr_insn_location (saved_loc); if (REG_P (r) && !REG_EXPR (r)) set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r); + if (MEM_P (r) && GET_MODE (r) == BLKmode && mode != BLKmode) + r = adjust_address (r, mode, 0); return r; } fixes the ICE on that testcase. > I think any entity with static storage (maybe even automatic storage) should > have BLKmode (or rather its mode should not matter) and what matters > is the mode we use for the access - that is, the mode of the MEM_REF we > expand, for example. There wasn't any MEM_REF in that case, just SSA_NAME with SSA_NAME_DEF_STMT of a load from VAR_DECL. > That TYPE_MODE is dynamic for vector types is a bad thing. It also means > that type layout may be variable (consider PPC where double has different > alignment in structs, so what layout would a struct with a vector_size(16) > double vector get with -mvsx vs. -mno-vsx?) I haven't introduced the dynamic TYPE_MODE, but getting rid of it would be terribly hard I'm afraid. Anyway, if struct layout depends on modes and handles the vector modes differently from BLKmode, then it is a target bug, it really should look at the types instead. Otherwise if you have such struct in a header, then -mvsx code will be ABI incompatible with -mno-vsx code using the same header. Jakub