[Bug c/50975] New: Logical operators evaluated in wrong order if no side effects

[Bug c/50975] New: Logical operators evaluated in wrong order if no side effects

[gcc.hall at gmail dot com]

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

             Bug #: 50975
           Summary: Logical operators evaluated in wrong order if no side
                    effects
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gcc.hall@gmail.com


gcc 4.6.2  -Os 

If the expressions either side of a logical operator (|| or &&) have no
side effects, gcc sometimes evaluates them in the wrong order.    See
the example below.  Of course the code works, but the standard is clear,
logical operators GUARANTEE left to right evaluation.  In this case 
people use the feature as a micro optimization, putting the most likely to
succeed case first with || or vice-versa with &&.

-----------------------------------
#include <stdio.h>
int
main( int argc, char *argv[] )
{
  char *last = argv[1];

  if( *last == 10 || *last == 13 )
    --last;

  printf("last = %p\n", last );
  return 0;
}
---------------------------------------------
    movb    (%eax), %dl # *last_3, D.2517
    cmpb    $13, %dl    #, D.2517
    je  .L4 #,
    cmpb    $10, %dl    #, D.2517
    jne .L2 #,
.L4:
    decl    %eax    # last
.L2:
--------------------------------------------

[Bug c/50975] Logical operators evaluated in wrong order if no side effects

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-03 08:26:33 UTC ---
But ... you can't tell the difference.  So this is a valid optimization.

[Bug c/50975] Logical operators evaluated in wrong order if no side effects

[gcc.hall at gmail dot com]

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

--- Comment #2 from Jeremy <gcc.hall at gmail dot com> 2011-11-03 12:37:41 UTC ---
(In reply to comment #1)
> But ... you can't tell the difference.  So this is a valid optimization.

You can tell the difference in execution time.

And why is this an "optimization"?  In this case, I cant see how it can improve
the code other than to lose any input from the programmer, who knows when the
data is biased.  I guess it might help in a more complex expression.

I think this is different from the controversy over the handling of signed
integer overflow.  There is no undefined behavior here.  The language standard
from K&R to the present day explicitly states the evaluation order is
guaranteed left to right with these operators.

[Bug c/50975] Logical operators evaluated in wrong order if no side effects

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
         Resolution|                            |INVALID

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-11-03 21:08:43 UTC ---
> You can tell the difference in execution time.

Execution time isn't a side effect of the abstract machine as defined by the
ISO C standard.  5.1.2.3 reads:

1 The semantic descriptions in this International Standard describe the
behavior
  of an abstract machine in which issues of optimization are irrelevant.

As long as the side-effects are preserved ("as if" rule), this is valid.

> I think this is different from the controversy over the handling of signed
> integer overflow.  There is no undefined behavior here.  The language standard
> from K&R to the present day explicitly states the evaluation order is
> guaranteed left to right with these operators.

Only if there are side-effects, otherwise the "as if" rule can be applied.