Re: Wrong optimisation in Visual C++.net Release Build

From: Larry Brasfield (donotspam_larry_brasfield_at_hotmail.com)
Date: 02/04/05 

Date: Fri, 4 Feb 2005 13:47:41 -0800

Above views may belong only to me.
"Michael K. O'Neill" <MikeAThon2000@nospam.hotmail.com> wrote
 in message news:uGubn%23vCFHA.3376@TK2MSFTNGP12.phx.gbl...
> It's not a compiler bug; it's bad code that relies on undefined behavior.

The program in question does not invoke undefined behavior.
Furthermore, as I claimed and proved with generated assembler,
the bug is in a function that occurs whether the function is called
once per statement or multiple times between sequence points.
So saying "It's not a compiler bug." requires one to be blind to
the generation of incorrect code. Hypertechnically, one could
claim that, if that code is called in an undefined manner, any
result is "correct", but as of today, functions compiled into a
standalone form (as opposed to inlined) do not somehow
change because of how they are called. However, since the
calling sequence does not invoke undefined behavior, even
that hypertechnical point does not apply here.

> The C++ standard is very clear in not specifying any particular order for
> evaluation of arguments for a function call. In fact, function arguments
> may generally be evaluated in any order, including interleaved.

The C++ standard is very clear that evaluation order is not
defined. Your statement is needlessly weak on this issue.

> That's one
> reason why you see things like __stdcall and __cdecl (which are attempts to
> define ordering).

No, they are not attempts to define order of evaluation.
Those calling conventions purport to (and do) define the
order of arguments on the stack during a call. Stack
order does not constrain evaluation order.

> So, your code is relying on behavior that's simply undefined. You can't
> blame the compiler.

The OP rightly blaims the compiler and so do I.

> See this "Got-cha of the Week" for one of nearly countless articles that
> explain this: http://www.gotw.ca/gotw/056.htm

None of those articles apply here.

The code you claim invokes undefined behavior is
something like:
     print(getvalue(), getvalue(), getvalue());
While it is true that the order of evaluation is undefined,
each call to getvalue defines sequence points that border
the call. Therefore, the language about multiple side-effects
upon a single object between sequence points does not
apply to this case. This code has the well defined result
that getvalue will be called 3 times.

The OP was not complaining that the ordering of values
passed to print() was incorrect. He was complaining about
those values being all the same when a correct evaluation
of getvalue() would result in varying values.

> Mike 

-- 
--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com

Relevant Pages

  • Re: Question about compilation/evaluation environments
    ... >> This can't be done if the compilation and evaluation environments ... >> evaluation environment. ... All evaluations initiated by the compiler ... is being run in at macroexpand time, and if it is the compiler encountering ...
    (comp.lang.lisp)
  • Re: Atomic operations in 32 and 64 bit platforms
    ... a compiler to evaluate functions with fixed parameters in any order ... evaluation can involve loading values from memory, ... appear on the x86 stack, that is not defined by the C ...
    (comp.lang.asm.x86)
  • Re: Benefit of not defining the order of execution
    ... Even with a strict order of evaluation, the Rationale's "as if" rule would ... still give the compiler such provisions for optimization. ...
    (comp.lang.c)
  • Re: Is a[i] = i++ correct?
    ... What the loose order of evaluation buys you is the ability to optimize ... The compiler still can change the order of actual ... undefinedness of the behavior if p and q are aliased, ... Loose evaluation order is merely an optimization crutch which was ...
    (comp.lang.c)
  • Re: pointer components and memory leaks
    ... that's the same thing as what Paul said. ... Let's not suggest compiler bug every time one finds a problem. ... leak memory, though even there, user bugs in other parts of the code can ...
    (comp.lang.fortran)