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
