Bug 13228 - Aliasing problem with IMI with structs
Summary: Aliasing problem with IMI with structs
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Andrew Pinski
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2003-11-29 04:17 UTC by Andrew Pinski
Modified: 2004-08-03 21:41 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-03-16 03:32:27


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2003-11-29 04:17:30 UTC
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;
}
Comment 1 Andrew Pinski 2003-11-29 04:19:37 UTC
I am going to look into more but I might need help.
Comment 2 Geoff Keating 2003-11-29 23:35:20 UTC
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.

Comment 3 Andrew Pinski 2003-12-16 18:55:33 UTC
Waiting on the reorg of c-decl.c from Zack.
Comment 4 Andrew Pinski 2004-04-05 00:55:14 UTC
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.
Comment 5 Andrew Pinski 2004-05-13 11:47:07 UTC
Fixed for 3.5.0 by the merge of the tree-ssa.
Comment 6 Andrew Pinski 2004-08-02 03:01:07 UTC
I was wrong, this is still broken.  The issue is more complex than I had thought.
Comment 7 Andrew Pinski 2004-08-02 21:47:10 UTC
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.
Comment 8 Andrew Pinski 2004-08-03 21:41:21 UTC
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.