Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference

[Sandra Loosemore <sandra at codesourcery dot com>]

On 02/19/2015 03:09 PM, Jakub Jelinek wrote:
> If you have hw where NULL is mapped and you know your code violates the
> C/C++ standards by placing objects at that address, simply do use
> the option that is designed for that purpose.

As I pointed out earlier, though, that won't help you if your program 
(perhaps implicitly) uses library code that's been built without the 
magic option.

I thought that declaring an object explicitly placed at address 0 as 
"volatile" ought to be sufficient to prevent writes to it from being 
optimized away and replaced with traps, but alas, that is not the case. 
 Also, a structure copy to such a volatile object is implicitly 
invoking the regular memcpy function without complaining about casting 
away volatile-ness, as an explicit call would do.  I've attached a 
couple quick test cases and .s output from arm-none-eabi-gcc -O2, using 
a mainline build from last night.

-Sandra

static int * const x0 = (int *) 0x00000000;
static volatile int * const xv = (int *) 0x00000000;
static int * const xn = (int *) 0x10000000;

void f0 (int *data)
{
  *x0 = *data;
}

void fv (int *data)
{
  *xv = *data;
}

void fn (int *data)
{
  *xn = *data;
}

Attachment: test.s
Description: Text document

struct big {
  int a, b;
  char c [100];
};

static struct big * const x0 = (struct big *) 0x00000000;
static volatile struct big * const xv = (struct big *) 0x00000000;
static struct big * const xn = (struct big *) 0x10000000;

void f0 (struct big *data)
{
  *x0 = *data;
}

void fv (struct big *data)
{
  *xv = *data;
}

void fn (struct big *data)
{
  *xn = *data;
}

Attachment: test2.s
Description: Text document