On Thu, 18 Nov 2010, Joern Rennecke wrote:
> You could do this with:
> typedef struct { int arch; void *p; } cumulative_args_t;
> or
> typedef struct { int arch; void *p; } *cumulative_args_t;
>
> with regards to the conversion function, that could be provided in
> target-def.h
>
> static inline
Quoting "Joseph S. Myers" :
struct cumulative_args could always be defined (automatically) to contain
a union between the target structures
This assumes
- every target uses a structure, and
- the names of all target's structures are unambigous, and
- the full definition of all the targets stru
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
>
> > You can perfectly well do type safety without using void *.
> >
> > struct cumulative_args;
> > type hook(struct cumulative_args *arg);
> >
> >
> > static inline struct x86_cumulative_args *
> > x86_get_cumulative_a
Quoting "Joseph S. Myers" :
You can perfectly well do type safety without using void *.
struct cumulative_args;
type hook(struct cumulative_args *arg);
static inline struct x86_cumulative_args *
x86_get_cumulative_args (struct cumulative_args *arg)
{struct cumulative_args *
return (struct x
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> Maybe you should talk more with your colleagues. I had protested when the
> CUMULATIVE_ARGS taking vectors were added to targetm, and I was told they'd
> be changed to taking void *, thus eliminating the problem.
> Now people don't want void * because
Quoting "Joseph S. Myers" :
On Thu, 18 Nov 2010, Joern Rennecke wrote:
1: At the end, target-def.h initalizes targetm, and whatever vectors we
might want to split out of it nor or in the future.
Disapprove, in the form in which you describe it. A key point of
splitting vectors is that dif
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> 1: At the end, target-def.h initalizes targetm, and whatever vectors we
> might want to split out of it nor or in the future.
Disapprove, in the form in which you describe it. A key point of
splitting vectors is that different vectors are linked in
What is annoying in the implementation of this patch:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01810.html
is, that for what is essentially only a minor re-arranging of the
hook vectors, I had to create such a huge patch because all the
call sites of the moved hooks are affected, and also every
