How do I know if gcc agrees that something is volatile?

Consider the following:

volatile uint32_t i;

How do I know if gcc did or did not treat i as volatile? It would be declared as such because no nearby code is going to modify it, and modification of it is likely due to some interrupt.

I am not the world's worst assembly programmer, but I play one on TV. Can someone help me to understand how it would differ?

If you take the following stupid code:

#include <stdio.h>
#include <inttypes.h>

volatile uint32_t i;

int main(void)
{
        if (i == 64738)
                return 0;
        else
                return 1;
}

Compile it to object format and disassemble it via objdump, then do the same after removing 'volatile', there is no difference (according to diff). Is the volatile declaration just too close to where its checked or modified or should I just always use some atomic type when declaring something volatile? Do some optimization flags influence this?

Note, my stupid sample does not fully match my question, I realize this. I'm only trying to find out if gcc did or did not treat the variable as volatile, so I'm studying small dumps to try to find the difference.

Solution

Many compilers in some situations don't treat volatile the way they should. See this paper if you deal much with volatiles to avoid nasty surprises: Volatiles are Miscompiled, and What to Do about It. It also contains the pretty good description of the volatile backed with the quotations from the standard.

To be 100% sure, and for such a simple example check out the assembly output. (With optimization enabled of course, otherwise no variables are kept in registers across statements.)

In your example, the global is only read once so there's no room for optimization even when it's not volatile. It's global not static so the compiler can't assume it still has its initial value (0) by the time execution reaches main; shared-library init hooks could reference it.