Re: c++/7135: Faulty Operator Precedence

[Nathan Sidwell <nathan at codesourcery dot com>]

The following reply was made to PR c++/7135; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: Brian Lindahl <lindahlb@hotmail.com>
Cc: nathan@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, unifex@yuidesigns.net, gcc-gnats@gcc.gnu.org
Subject: Re: c++/7135: Faulty Operator Precedence
Date: Sun, 30 Jun 2002 10:47:40 +0100

 Brian Lindahl wrote:
 > 
 > First of all, I disagree with your analysis. One fact alone should
 > contradict the analysis:
 > Inlining the methods changes the compiler output, and thus, the output
 > displayed on the screen.
 > 
 > I believe that, according to C++ semantics, inlining a function should not
 > change compiler output.
 all compiler optimizations are invariant on the abstract machined described
 by the std for well formed programs. But, I contend that your program
 is not well-formed, so a compiler assumption is broken, and hence optimizations
 may do anything.
 
 
 
 > In fact, I should have stated that the code should be equivalent to:
 > operator<<(
 >    operator<<(
 >       cout,
 >       A::get(
 >          &A::set(5, &a)
 >       )
 >    ),
 >    A::get(
 >       &A::set(30, &a)
 >    )
 > );
 > 
 > (Note the method, set, returns '*this' as a 'const A &')
 > 
 > >     There are 4 sequence points in that, each between
 > >     evaluating the parameters to a call, and the call itself.
 > >     These sequence points are partially ordered, but not
 > >     completely ordered. In particular there is no ordering
 > 
 > As shown above, there are more than 4 sequence points, in evaluating the
 > parameters of the parameters of the call. Furthermore, the existance of
 > parenthesis creates a need, I believe, for complete ordering, not the
 > partial ordering you suggest.
 no it does not. function parameters may be evaluated in any order. 
 the inner operator << call may be performed before or after the second
 a::get (a::set (30)) call. Hence the a::get (a::set ()) sequences
 are unordered wrt eachother.
 
 > Correct, in particular. But because they are contained in different layers
 > of parenthesis, there is a complete ordering in the code.
 no, you are incorrect. You cannot enforce evaluation ordering by
 adding parentheses. Anyway these parentheses are part of the function
 call syntax, and not the same as expression grouping parenthsese (and,
 more importantly), neither are those ','s comma operators.
 
 I am closing the PR.
 
 nathan
 
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org