------- 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
