Re: is this valid c or a compiler bug?

From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 02/27/04 

Date: 27 Feb 2004 13:55:09 GMT

In <b811ab79.0402261225.51c1430d@posting.google.com> keithv@clover.net (Keith Vetter) writes:

>After a long debugging session I tracked down a
>bug to the following line of code:
>
> np = &nl[alloc_memory()]; /* nl & np are NODE * */
>
>The problem is that nl is volatile--alloc_memory() may
>change it (via realloc). The AIX compiler fails--it grabs
>the value of nl before the call to alloc_memory(). The
>Windows VC 6.0 compiler handles it correctly.
>
>So is this a compiler bug, programmer error or ambiguous c?

Programmer error, if the function call was supposed to be evaluated
before nl. When the language doesn't specify an evaluation order
(and it seldom does), it is programmer's responsibility to enforce the
desired evaluation order, by decomposing the expression into
subexpressions:

    tmp = alloc_memory();
    np = nl + tmp;

Now, you are guaranteed that the alloc_memory function call will be
evaluated before nl, because the end of the first expression acts as a
sequence point.

The volatility of nl just doesn't make any difference to this discussion:
it means that nl *must* be evaluated (instead of reusing an old copy of
it that might still be available in a register), but the exact moment nl
is evaluated is still unspecified (both before and after the alloc_memory
function calls are valid options for the compiler).

Dan 

-- 
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

Relevant Pages

  • Re: Wrong optimisation in Visual C++.net Release Build
    ... It's not a compiler bug; it's bad code that relies on undefined behavior. ... evaluation of arguments for a function call. ...
    (microsoft.public.vc.language)
  • 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: subroutine stack and C machine model
    ... On a typical system the stack on entry to the function looks like this ... balance to specify the order of evaluation). ... compiler developer to find out when code can be moved around. ... I think the Standards people used compiler optimization as an excuse ...
    (comp.lang.c)
Loading