Re: {PATCH,x86] Workarond for 55970

[Yuri Rumyantsev <ysrumyan at gmail dot com>]

Hi Ian,

It looks that i had to formulate my notes more precisely - the issue
with which one our customer met is that there are plenty calls of C++
functions with member class function arguments for which an order of
call is essential (see e.g. attached testy-case on C that emulates it.
So I only care about an order of calls in incoming arguments.

Yuri.

2013/2/1 Ian Lance Taylor <iant@google.com>:
> On Fri, Feb 1, 2013 at 5:10 AM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
>>
>> This is simple fix that is aimed to help users in porting their
>> applications to x86 platforms which rely on an order of function
>> argument evaluation. To preserve direct order of argument evaluation
>> they need to be added additional option '-mno-push-args' to compile
>> that looks reasonable price for non-C/C++ Standard conformance.
>> I checked that adding this option does not affect on performance on
>> Corei7 and Atom platforms. Note also that option "-push-args" is
>> passed by default on all x86 platforms and it means that changing this
>> macros will not likely affect on almost all gcc users.
>
> If your goal is to preserve the order in which function arguments are
> evaluated, this patch is not going to be reliable.  It only affects
> the conversion from GIMPLE to RTL.  The GIMPLE optimizers will have
> already had plenty of opportunity to change the function argument
> evaluation order.
>
> I don't think we should change the compiler to generate less efficient
> code in order to help non-standard-conforming programs when the change
> won't work reliably anyhow.
>
> Ian