On 05/05/15 19:07, Richard Biener wrote: > On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw > <richard.earns...@foss.arm.com> wrote: >> On 05/05/15 15:33, Richard Earnshaw wrote: >>> On 05/05/15 15:29, Jakub Jelinek wrote: >>>> 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. >>> >>> Then clearly no such tests exist in the testsuite :-( >>> >> >> Or, more precisely, no such tests existed in 2008, when the code went >> in. > > That just means that the code was the first that make this matter. >
Exactly. The comment was in response to the suggestion the code wasn't tested. > BTW, what do other compilers do (I suppose llvm supports the gcc extensions > for alignment)? Can llvm and gcc interoperate properly here? Do the cited > testcases work with llvm? > We're looking into it. I'm talking to our LLVM team and we'll make sure we have a consistent set of rules. R. > Richard. > >> >> R. >> >>> R. >>> >>>> 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 >>>> >>> > >
