http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
Richard Guenther <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2012-04-10 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-10 12:06:26 UTC --- (gdb) prt to <mem_ref 0xfffafed2790 type <real_type 0xfffb0057b60 double DF size <integer_cst 0xfffafe125e0 constant 64> unit size <integer_cst 0xfffafe12600 constant 8> align 8 symtab 0 alias set 2 canonical type 0xfffaff00f18 precision 64> I suppose SRA does this. Can you check with -fno-tree-sra? The code in SRA, which is /* If prev_base were always an originally performed access we can extract more optimistic alignment information by looking at the access mode. That would constrain the alignment of base + base_offset which we would need to adjust according to offset. */ align = get_pointer_alignment_1 (base, &misalign); if (misalign == 0 && (TREE_CODE (prev_base) == MEM_REF || TREE_CODE (prev_base) == TARGET_MEM_REF)) align = MAX (align, TYPE_ALIGN (TREE_TYPE (prev_base))); misalign += (double_int_sext (tree_to_double_int (off), TYPE_PRECISION (TREE_TYPE (off))).low * BITS_PER_UNIT); misalign = misalign & (align - 1); if (misalign != 0) align = (misalign & -misalign); if (align < TYPE_ALIGN (exp_type)) exp_type = build_aligned_type (exp_type, align); only looks at conservative alignment in this case (prev_base is not a base, but a COMPONENT_REF). I think martin has a patch to fix this.