Re: Optimizing Away


jaysome wrote:
Suppose I have something like this on a free-standing
environment (where void main(void) is documented and well-defined):

static int G_num_loops = 0;

void main (void)
{
/* set up interrupts */
/* ... */
for ( ; ; )
{
G_num_loops++;
}
}

Further suppose that I have the (non-standard) means to "read" the value
of G_num_loops via a link map and other techniques :)

Is there anything in the C standard that allows the compiler to
optimize away and NOT allocate storage for G_num_loops and thus prevent me
from "viewing" its value? If so, does defining G_num_loops as volatile
prevent this? (or put in a more standard kind of way, does the C standard
require the statement:

G_num_loops++;

to be executed.

My compiler seems to be optimizing that statement away when defined as
static and not volatile. So instead, I change the definition to have
external linkage:

int G_num_loops = 0;

and it works for my purpose.

The only *potential* problem is that if I define variables with the
same name (mostly arrays) with external linkage in another translation
unit (more likely the name would be G_debug_buf), then the linker issues
an error about multiply defined symbols.

I can deal with that--I've learned to "work" with the compiler and
linker and just name such variables with prefixes that are specific to the
module, e.g., G_fir_debug_buf or G_serial_debug_buf. Maybe I'm just facing
the reality of embedded debugging, but I'd like to hear the opinions of
others who have similar experience in this area.

BTW, the compiler I'm working with does not conform to the C standard in
that it does not initialize the following file scope definition to 0:

static int G_num_loops;

I have to explicitly initialize it to 0:

static int G_num_loops = 0;

Thanks
--
jay

Defining G_num_loops as volatile will prevent it from being optimized
out. In embedded applications, you should use the volatile keyword to
describe any variables that you are mapping to a hardware register.

.

Relevant Pages

  • Re: Share .cpp and .h along projects
    ... You asked me to show how a volatile pointer could be used to ... volatile void* or a cast could be used). ... As you stated "A compiler that can see into all these functions will ...
    (microsoft.public.vc.language)
  • Re: Boolean Buyers Beware ... AIX compiler bug --- PMR 26241,756
    ... and thus the compiler is fine. ... the standard says nothing about that. ... Everyone knows how volatile is supposed to work in C; ... It is true that the only way you can observe such optimizations ...
    (comp.programming.threads)
  • Re: A basic question question about volatile use
    ... compiler would not be able to prevent all bytes being aed. ... But it shows some of the limitations the C Standard has ... chips, ... with a volatile bitfield member of a struct). ...
    (comp.lang.c)
  • Re: volatile Keyword Question
    ... I thought the compiler was required to read the ... volatile because it was volatile? ... the behaviour of the code may be a grey area as ... The standard is quite explicit that ...
    (comp.lang.c)
  • Re: Question regarding UB
    ... More practically, though, Standard C is all about *observable* ... void f{ ... int i = 0; ... a compiler is allowed to *assume* that undefined ...
    (comp.lang.c)