------- Comment #5 from contact at philipashmore dot com 2010-08-07 02:01
-------
In my projects I add "-isystem ${top_srcdir}", the top source directory being
v3c.
This way, the examples can
#include <v3c/avl.h>
Just like code you might develop yourself using treedb.
I do a lot of
gcc -E -c a.c ... -o a.cc
followed by
gcc -x c -c a.cc -o a.o ...
to track down problems in the code generated by macro expansion, and as a
last ditch effort, I decided to try to compile an object file from the
"cc" file, and debug the resulting program.
There they were - the aliasing violations!
It turns out that using -isystem for local include files was effectively
telling gcc not to report problems in header files included in this way.
You can check this yourself with these "snippets"
1: my-alias.c
#include <alias-header.h>
2: alias-header.h
#include <stdio.h>
void test()
{
short a[2];
a[0]=0x1111;
a[1]=0x1111;
*(int *)a = 0x22222222;
printf("%x %x\n", a[0], a[1]);
}
Run this:
$ gcc -c -isystem. -fstrict-aliasing -Wstrict-aliasing my-alias.c
and you will get no warnings or errors.
3: my-alias.cc
#include <stdio.h>
void test()
{
short a[2];
a[0]=0x1111;
a[1]=0x1111;
*(int *)a = 0x22222222;
printf("%x %x\n", a[0], a[1]);
}
Run this:
$ gcc -x c -c -isystem. -fstrict-aliasing -Wstrict-aliasing my-alias.cc
and you will get
my-alias.cc: In function âtestâ:
my-alias.cc:7: warning: dereferencing type-punned pointer will break
strict-aliasing rules
--
contact at philipashmore dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
