On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
> On 05/05/15 14:06, Jakub Jelinek wrote:
> > On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> >> In a literal sense, yes. However, even K&R & stdarg have standard
> >> promotion and conversion rules (size < int => int, floats promoted to
> >> double, etc). What are those rules for GCC's overaligned types (ie
> >> where in the docs does it say what happens and how a back-end should
> >> interpret them)? Shouldn't the mid-end be doing that work so as to
> >
> > For the middle-end, the TYPE_ALIGN info on expression types is considered
> > useless, you can get there anything. There is no conversion rule to what
> > you get for myalignedint + int, or (myalignedint) int, or (int)
> > myalignedint, etc.
> >
> >> create a consistent view of the values passed into the back-end? It
> >> seems to me that at present the back-end has to be psychic as to what is
> >> really happening.
> >
> > No, the backend just shouldn't consider TYPE_ALIGN on the scalars, and it
> > seems only arm ever looks at that.
> >
>
> Nothing in the specification for TARGET_FUNCTION_ARG (or any of the
> related functions) makes any mention of this...
While this requirement isn't documented, it is clearly common sense or at
least something any kind of testing would reveal immediately.
And it is nothing broken recently (except that with the SRA changes it hits
much more often), looking e.g. at GCC 3.2, I'm seeing that expand_call is on
that testcase also called with pretty random TYPE_ALIGN on the argument
types; we didn't have GIMPLE then, so it is nothing that GIMPLE brought in.
Jakub
