On Thu, 30 Jan 2014, Jakub Jelinek wrote: > On Thu, Jan 30, 2014 at 07:25:03PM +0100, Richard Biener wrote: > > *** 8886,8891 **** > > --- 8892,8932 ---- > > || TREE_ADDRESSABLE (desttype)) > > return NULL_TREE; > > > > + /* Make sure we are not copying using a floating-point mode or > > + a type whose size possibly does not match its precision. */ > > + if (FLOAT_MODE_P (TYPE_MODE (desttype)) > > + || TREE_CODE (desttype) == BOOLEAN_TYPE > > + || TREE_CODE (desttype) == ENUMERAL_TYPE) > > + { > > + /* A more suitable int_mode_for_mode would return a vector > > + integer mode for a vector float mode or a integer complex > > + mode for a float complex mode if there isn't a regular > > + integer mode covering the mode of desttype. */ > > + enum machine_mode mode = int_mode_for_mode (TYPE_MODE (desttype)); > > + if (mode == BLKmode) > > + desttype = NULL_TREE; > > + else > > + desttype = build_nonstandard_integer_type (GET_MODE_BITSIZE (mode), > > + 1); > > + } > > As I said in the PR, I think you want to do the build_aligned_type > just in case e.g. the floating point type is more aligned than the integer > or vice versa.
I think that calls were misguided - we don't use the types alignment as-is, in fact we rely on pointer alignment for the source and destination addresses and then only for !STRICT_ALIGNMENT targets make mis-aligned accesses by lowering the types alignment. If you apply custom alignment to a type that will override the pointer/decl alignment forcefully thus IMHO those type align adjustments were simply wrong. Richard. > > - { > > - tree srcitype > > - = lang_hooks.types.type_for_mode (TYPE_MODE (srctype), > > - TYPE_UNSIGNED (srctype)); > > - srctype = build_aligned_type (srcitype, TYPE_ALIGN (srctype)); > > - } > > - > > Jakub