This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Allow cgraph nodes to change name


> X-Original-To: geoffk@foam.wonderslug.com
> From: "Zack Weinberg" <zack@codesourcery.com>
> Cc: hubicka@ucw.cz, gcc-patches@gcc.gnu.org
> Date: Wed, 20 Aug 2003 16:44:27 -0700
> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
> X-OriginalArrivalTime: 20 Aug 2003 23:43:24.0984 (UTC) FILETIME=[D8EDDB80:01C36774]
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> >> From: "Zack Weinberg" <zack@codesourcery.com>
> >> Cc: Geoff Keating <geoffk@geoffk.org>, gcc-patches@gcc.gnu.org
> >> Date: Wed, 20 Aug 2003 12:25:06 -0700
> >
> >> Jan Hubicka <hubicka@ucw.cz> writes:
> >> 
> >> > Another alternative is that in fact I don't need the hashtables.
> >> > Only what I use it for is to convert DECL nodes into cgraph nodes.  The
> >> > problem is that cgraph nodes are unique for function while DECL nodes
> >> > are not, but perhaps frontends already have some capability of tracking
> >> > this down.  Do you think it would be possible to add a direct pointer
> >> > into the nodes and track it down using it?
> >> 
> >> Er, DECL nodes are supposed to be unique for each function, aren't they?
> >
> > Not really, I believe:
> [...]
> 
> Currently true, yes.  But this causes problems in other areas, notably
> targets where external symbol references have to be called out as such
> in assembly... hence my "supposed to be."
> 
> I am still working, slowly, on changes to C identifier binding that
> will eventually get rid of the need to copy the DECL for that example.

I think that in general you'll still need multiple DECLs because the
types can be different.

Consider

int foo(void) {
   struct s;
   extern void x (struct s *);
   struct s { int f; };
   ...
}
int bar(void) {
   struct s;   // note, different 'struct s' to the one in 'foo'
   extern void x (struct s *);  // not an error
   struct s { int f; };  /* still not an error (there might be a 'x'
       in some other translation unit which has a type compatible with
       both the declaration in 'foo' and 'bar') */
}
int baz(void) {
   struct s { int x; };
   extern void x (struct s *);   /* error, whatever the type is it
      can't be compatible with the type here and the types declared
      earlier */
}
struct s;
void x (struct s *p)// error, type incompatible with all previous declarations
{
   ...
}

and of course this sort of thing happens much more often with
multiple modules and intermodule analysis.

In C89, it's also possible for some of the structures to have
different tags, which makes it possible to write even more interesting
test cases.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]