[Bug tree-optimization/55970] New: [x86] Avoid reverse order of function argument gimplifying

[Bug tree-optimization/55970] New: [x86] Avoid reverse order of function argument gimplifying

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

             Bug #: 55970
           Summary: [x86] Avoid reverse order of function argument
                    gimplifying
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ysrumyan@gmail.com


One important customer met with this problem in a process of porting app from
ARN to IA. The issue can be illustrated by attached example and essential for
x86 platform since only it defines 'PUSH_ARGS_REVERSED' macros. Note also that
attached code is not compliant with C99 standard since it assume definite order
of argument calculation.

gcc -O3 t.c t_main.c
./a.out
Test Failed
gcc -O3 t.c t_main_fix.c              
./a.out 
Test Passed

diff t_main.c t_main_fix.c
13c13,14
<   if (foo (foo1(), foo1()))
---
>   int x1 = foo1(), x2 = foo1();
>   if (foo (x1, x2))

You can see that gimplifying of function arguments (gimplify.c,
dimplify_call_expr) uses reverse order of arguments:

  /* Finally, gimplify the function arguments.  */
  if (nargs > 0)
    {
      for (i = (PUSH_ARGS_REVERSED ? nargs - 1 : 0);
           PUSH_ARGS_REVERSED ? i >= 0 : i < nargs;
           PUSH_ARGS_REVERSED ? i-- : i++)
        {
...

I assume that we must no use reverse order in this place, i.e. loop header must
look like
      for (i = 0; i < nargs; i++)

[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

--- Comment #1 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-01-14 14:46:48 UTC ---
Created attachment 29162
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29162
testcase

[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-14 14:56:23 UTC ---
It's done that way to push to the stack in optimal order.  Depending on
function
arg oder of evaluation is wrong.

[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

--- Comment #3 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-01-14 15:15:52 UTC ---
I pointed out that this code is not C standard compliant but it occurred in
customer application that should be ported to x86 platform. This bug is not
issued by gcc and very hard detected. Customer has more then 2000 such patterns
in its application and he is not sure that all such patterns were found. So I
still assume that we should fix it for x86 platform. Note also that icc does
not have such issue.

[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-14 17:34:28 UTC ---
(In reply to comment #3)

Maybe we should warn about these cases just like we warn for the other
unspecified behavior which causes undefined behavior (aka a+=a+1).

[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying

[ysrumyan at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

--- Comment #5 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-02-01 13:34:20 UTC ---
I sent for review a simple fix that can be considered as workaround for this
issue - I simply change macros

#define PUSH_ARGS_REVERSED TARGET_PUSH_ARGS

that allows user to preserve an order of function arguments evaluation if
"-mno-push-args" option was added to compile.

I also checked that adding that option will not affect on performance for
Corei7 and Atom platforms.

With modified gcc attached test is passed:

gcc -O2 t.c t_main.c -mno-push-args
./a.out
Test Passed

[Bug tree-optimization/55970] [x86] Avoid reverse order of function argument gimplifying

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55970

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-02-04 11:15:15 UTC ---
You could use a wrapper function to guarantee order of evaluation. The one here
seems a bit too complex:

http://stackoverflow.com/questions/14058592/how-to-guarantee-order-of-argument-evaluation-when-calling-a-function-object

Or you could build a gcc plugin that adds a wrapper around each function call
in order to evaluate arguments left-to-right.

GCC should definitely warn about this, isn't there a bug open?

Another testcase is:

void f(int, int);

void test() {
  int i = 0;
  int v[1] = {0};
  f(v[i], i++); // warn
}

This one doesn't involve function calls in the arguments.