Re: GCC warnings for unused global variables

[<tm_gccmail at mail dot kloo dot net>]

On 2 May 2003, Gabriel Dos Reis wrote:

> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> 
> | On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | > prj@po.cwru.edu (Paul Jarc) writes:
> | > 
> | > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | > | > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> | > | >| I don't think the committee ever intended to allow implementations
> | > | >| to optimize away volatile variables,
> | > | >
> | > | > Why not?  The C standard clearly says:
> | > | >
> | > | >        [#3] In the abstract machine, all expressions are  evaluated
> | > | >        as  specified  by  the  semantics.  An actual implementation
> | > | >        need not evaluate part of an expression  if  it  can  deduce
> | > | >        that  its  value is not used and that no needed side effects
> | >                                                  ^^^^^^^^^
> | > | >        are produced (including any caused by calling a function  or
> | > | >        accessing a volatile object).
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> | > | 
> | > | Accessing a volatile object includes writing, and writing includes
> | > | initializing.  So the initialization cannot be optimized out.
> | > 
> | > Why? the last part of the paragraph quoted above does specifically
> | > permit that optimization where applicable.
> | 
> | In the case of accesses to volatile objects, it is never applicable.
> 
> Even when the standard writes it?  Hugh. 

Seemingly meaningless read/writes from/to volatile variables usually have
a programmer-intended side effect.

On the SH series, the interrupt controller requires a write to reset
level-triggered interrupts. We don't care about the value of the write; it
just needs a write to a certain address. So we do:

	*clear_trigger = 0;

On the SH, we need three reads in the reset code to initialize the SDRAM
burst mode. The value read doesn't matter; we just need to trigger reads
on the hardware bus. So we do:

	c = *magic_pointer1;
	c = *magic_pointer2;
	c = *magic_pointer3;

When we fill a serial FIFO with data, we do:

	for (i=0; i<4; i++)
		*data_reg = *c++;

I do not want this optimized to:

	*data_reg = c[3];

Do not touch the happy fun volatile values, or all the hardware drivers in
the world will break, including the ones in Linux, FreeBSD, NetBSD,
OpenBSD, QNX, VxWorks, RTEMS, etc.

Toshi