| Summary: | Aliasing problem with IMI with structs | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Andrew Pinski <pinskia> |
| Component: | c | Assignee: | Andrew Pinski <pinskia> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs, geoffk |
| Priority: | P2 | Keywords: | wrong-code |
| Version: | 3.4.0 | ||
| Target Milestone: | 4.0.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2004-03-16 03:32:27 | |
I am going to look into more but I might need help. Subject: Re: Aliasing problem with IMI with structs
This is probably a missing part of the IMI implementation. When
compiling a single source file, each structure definition defines a
different type that's not compatible with any other structure
definition in that file. However, when two structures are defined in
two different source files, they can be compatible with each other.
As a bonus, the rules for when this can happen differ between C99 and
C89. They're implemented in tagged_types_tu_compatible_p in
c-typeck.c.
I couldn't reproduce the reported bug, but it's probably a
manifestation of a non-IMI problem. Consider the following:
static void g (void * x_p)
{
struct h { int i; } * x = (struct h *) x_p;
x->i = 2;
}
int f (void * x_p, void *x2)
{
struct h { int i; } * x = (struct h *) x_p;
g (x2);
return x->i;
}
You can make this into a real program by putting, in another file,
extern int f (void *);
int main(void)
{
struct h { int i; } xx;
f (&xx, &xx);
}
and the whole program doesn't violate any aliasing rules.
Waiting on the reorg of c-decl.c from Zack. Should be fixed on the tree-ssa by patches by Dale. Suspending as fixed on the tree-ssa but I cannot test as IMA/IMI is broken by Zack's rewrite. Fixed for 3.5.0 by the merge of the tree-ssa. I was wrong, this is still broken. The issue is more complex than I had thought. Actually the status here it was fixed on the tree-ssa but Dale's patch but broke with Zack's rewrite to c- decl, me and Dale think we have a fix for this problem now with the mainline and a simple one line patch which updates the use of current_file_decl which is no longer used in the C front-end. Fixed by: 2004-08-03 Dale Johannesen <dalej@apple.com> * c-common.c: Include opts.h. (c_common_get_alias_set): Fix check for a single input file. * toplev.c: Remove current_file_decl. * tree.h: Ditto. And I have a small (large in some cases) speedup for c_common_get_alias_set because it does not record the aliasing set for the types. |
Even though this sample testcase does not show the problem in the asm (at least on powerpc- apple-darwin), when debuging a much larger problem (like --enable-intermodule or vpr in SPEC) I noticed an aliasing problem. You can see that there is an aliasing problem by breaking on get_alias_set and having gdb display debug_tree(t) and watch to see if you have a type and one called "h" and see that you get one and then another (but in reallity they are the same type) and also the aliasing sets are set two different values (for this case 3 and 6). What should happen is that the aliasing set should be the same. test.i: struct h { int i; }; void g(struct h *j1) { j1->i = 1; } test1.i: struct h { int i; }; void g(struct h*); int f(struct h *j) { g(j); return j->i; }