{PATCH,x86] Workarond for 55970

Yuri Rumyantsev ysrumyan@gmail.com
Mon Feb 4 11:43:00 GMT 2013

Hi Richard,

We wrote:

> Your patch changes behavior
> in multiple places of the compiler, which is not acceptable.

I don't change behavior of compiler since option "-mpush-args" is
passed to compiler by default. We do change compiler behavior if only
option "-mno-push-args" was passed to compiler explicitly.

Best regards.

2013/2/4 Richard Biener <richard.guenther@gmail.com>:
> On Mon, Feb 4, 2013 at 10:31 AM, Yuri Rumyantsev <ysrumyan@gmail.com> wrote:
>> 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.
> Even though I agree with Ian let me suggest sth.  The order of side-effects
> when evaluating function call arguments is currently determined by the
> order we gimplify, thus solely by gimplify.c.  Your patch changes behavior
> in multiple places of the compiler, which is not acceptable.  Instead
> of changing the default order with a switch the only thing I would view
> as possibly acceptable is to have a
> -ffunction-call-argument-evaluation-order={left-to-right,right-to-left,undefined}
> where 'undefined' would be the default.  I'm not sure if we can guarantee
> the order of evaluation of side-effects in that simple manner though.
> Richard.
>> 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

More information about the Gcc-patches mailing list