This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Possible Chill bug, prototypes, ch/satisfy.c:safe_satisfy_decl()
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: Possible Chill bug, prototypes, ch/satisfy.c:safe_satisfy_decl()
- From: Dave Brolley <brolley at cygnus dot com>
- Date: Wed, 18 Aug 1999 15:17:41 -0400
- CC: egcs-bugs at egcs dot cygnus dot com
- Organization: Cygnus Solutions Canada Ltd
- References: <199908161637.MAA04089@caip.rutgers.edu>
Kaveh R. Ghazi wrote:
> When prototyping in the ch/ directory, I came across a
> conflict brought to light by the addition of prototypes for
> satisfy.c:safe_satisfy_decl():
>
> > satisfy.c: In function `safe_satisfy_decl':
> > satisfy.c:208: warning: passing arg 1 of `safe_satisfy_decl' from
> > incompatible pointer type
> > satisfy.c:219: warning: passing arg 1 of `safe_satisfy_decl' from
> > incompatible pointer type
>
> Here's what both calls look like.
>
> > safe_satisfy_decl (DECL_TASKING_CODE_DECL (decl),
> > prev_chain);
>
> safe_satisfy_decl() expects a `tree' as its first arg and I think by
> calling DECL_TASKING_CODE_DECL() it gets a `struct lang_type *' so
> this is probably a bug.
>
> What's the best way to fix this?
It appears that the convention is to declare struct lang_type to contain
a union of the possible types representing the possible uses of the field
and then to cast it as appropriate when it's used. In this case, the code
is not really broken because the only member of the union is a tree, so
you do always get a pointer to a tree, in an obscure and indirect sort of
way.
Other places that reference DECL_TASKING_CODE_DECL cast it as
(tree)DECL_TASKING_CODE_DECL(decl). See gcc/ch/tasking.c.
Dave