[Bug c/33949] gcc-4.2.2 generates bad code on ARM

[zero at colonel-panic dot org]

------- Comment #2 from zero at colonel-panic dot org  2007-10-30 15:31 -------
Subject: Re:  gcc-4.2.2 generates bad code on ARM

rguenth at gcc dot gnu dot org wrote:
> ------- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-30 14:31 -------
> huh?  you initialize DMA_ADDR_REG to the address of param (which is on the
> stack).
> The initialization of the contents of param is unused and as such dropped
> (but due to -fno-strict-aliasing the compiler assumes it escapes to panic()).
> 

No, the initialisation of param is not unused. The address of param is 
stored in a DMA controller register which then uses this address to 
access the values in param[] (obviously in the original code param[] is 
a much larger array and there is code that follows the assignment to 
DMA_ADDR_REG that kicks off a DMA engine which copies the values out of 
param[] and to a peripheral and then waits for the DMA engine to 
complete - I reduced the code to the minimum that exhibits the fault).

Surely the assignment of the address of a variable through a "volatile" 
pointer should guarantee that the initialisation of the variable is 
complete?

I can make the code look more practical by fleshing it out with the 
following. The compiler still does the initialisation before the panic() 
rather than before the assigment to DMA_ADDR_REG.

#define DMA_COUNT_REG (*(unsigned volatile *) 0xffff1004)

static void inner_func(void *data, unsigned size)
{
        if (!size)
                panic();
        else {
                DMA_COUNT_REG = 1;
                DMA_ADDR_REG = (unsigned long) data;
                while (DMA_COUNT_REG)
                        ;
        }
}

PS - recompiling the original test case with -fstrict-aliasing does not 
affect the compiler output.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33949