This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)

On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw <> 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
>>>>>> promotion and conversion rules (size < int => int, floats
>promoted to
>>>>>> double, etc).  What are those rules for GCC's overaligned types
>>>>>> where in the docs does it say what happens and how a back-end
>>>>>> interpret them)?  Shouldn't the mid-end be doing that work so as
>>>>> For the middle-end, the TYPE_ALIGN info on expression types is
>>>>> 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? 
>>>>>> 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

That just means that the code was the first that make this matter.

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?


>> 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
>>> types; we didn't have GIMPLE then, so it is nothing that GIMPLE
>brought in.
>>> 	Jakub

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]