------- Comment #29 from rguenth at gcc dot gnu dot org 2010-01-18 11:43 ------- (In reply to comment #28) > Btw, get_pointer_alignment should get passed an access type to put it into > context. For alignment of say INDIRECT_REFs it would be the pointed-to type > but for function arguments in general it needs to be 'char' if you don't know > anything about the kind of the accesses the function does. That would be > the default/fallback align get_pointer_alignment has to assume.
Which, if you look at all current callers, boils down to effectively Index: gcc/builtins.c =================================================================== --- gcc/builtins.c (revision 156006) +++ gcc/builtins.c (working copy) @@ -369,8 +369,7 @@ get_pointer_alignment (tree exp, unsigne if (!POINTER_TYPE_P (TREE_TYPE (exp))) return 0; - align = TYPE_ALIGN (TREE_TYPE (TREE_TYPE (exp))); - align = MIN (align, max_align); + align = BITS_PER_UNIT; while (1) { @@ -380,9 +379,6 @@ get_pointer_alignment (tree exp, unsigne exp = TREE_OPERAND (exp, 0); if (! POINTER_TYPE_P (TREE_TYPE (exp))) return align; - - inner = TYPE_ALIGN (TREE_TYPE (TREE_TYPE (exp))); - align = MIN (inner, max_align); break; case POINTER_PLUS_EXPR: which of course will regress generated code quite a bit (even though it's correct). We might be able to recover some bits by walking SSA defs here but we'll still lose when reaching function arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954