On Sat, Mar 21, 2009 at 1:17 PM, Basile STARYNKEVITCH
<[email protected]> wrote:
> Hello All,
>
> What is the politically correct way of having an ignored function pointer
> inside a GTY-ed struct?
>
> Of course, the function pointer is obviously GTY ((skip))-ed.
>
> In the MELT branch (file gcc/basilys.h rev144985) I have
> // notice that FLEXIBLE_DIM is a macro expanding to empty
>
> #define BASILYS_ROUTDESCR_LEN 96
> #define BASILYS_ROUTADDR_LEN (1 + (2*sizeof (basilysroutfun_t *))/ sizeof
> (long))
>
> struct basilysroutine_st
> GTY (())
> {
> basilysobject_ptr_t discr;
> char routdescr[BASILYS_ROUTDESCR_LEN];
> long GTY ((skip)) routaddr[BASILYS_ROUTADDR_LEN];
> basilys_ptr_t routdata;
> unsigned nbval;
> basilys_ptr_t GTY ((length ("%h.nbval"))) tabval[FLEXIBLE_DIM];
> };
>
> /* unsafely set inside the basilysroutine_st pointed by Rptr the
> routine function pointer to Rout */
> #define BASILYS_ROUTINE_SET_ROUTCODE(Rptr,Rout) do { \
> (*(basilysroutfun_t**)((struct basilysroutine_st*)(Rptr))->routaddr) \
> = (Rout); \
This violates C aliasing rules. As it is a macro I have no idea what Rptr and
Rout point to and thus cannot provide any advice. Please consider
making such *_SET macros inline functions instead (not that this would
fix this particular bug).
Richard.
> } while(0)
>
>
> However, all invocations of the BASILYS_ROUTINE_SET_ROUTCODE macro gives
> still tons of warnings
> warmelt-first-0.c:50068: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> warmelt-first-0.c:50422: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> warmelt-first-0.c:50434: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> warmelt-first-0.c:50446: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> warmelt-first-0.c:50458: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> warmelt-first-0.c:50470: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
>
>
> Ideally, I would like to code
>
> /* the signature of all MELT generated functions */
> typedef basilys_ptr_t basilysroutfun_t (basilysclosure_ptr_t closp_,
> basilys_ptr_t firstargp_,
> const char xargdescr_[],
> union basilysparam_un *xargtab_,
> const char xresdescr_[],
> union basilysparam_un *xrestab_);
>
> #define BASILYS_ROUTDESCR_LEN 96
>
> struct basilysroutine_st
> GTY (())
> {
> basilysobject_ptr_t discr;
> char routdescr[BASILYS_ROUTDESCR_LEN];
> basilysroutfun_t* GTY ((skip)) routfun;
> basilys_ptr_t routdata;
> unsigned nbval;
> basilys_ptr_t GTY ((length ("%h.nbval"))) tabval[FLEXIBLE_DIM];
> };
>
> /* unsafely set inside the basilysroutine_st pointed by Rptr the
> routine function pointer to Rout */
> #define BASILYS_ROUTINE_SET_ROUTCODE(Rptr,Rout) do { \
> ((struct basilysroutine_st*)(Rptr))->routfun) \
> = (Rout); \
> } while(0)
>
> But last time I tried (more than a year ago) that didn't work because
> gengtype is unhappy with GTY((skip))-ed fields of a type it does not
> understand.
>
> I could imagine that once plugin-s are politically correct (maybe in 2011?
> but I still hope before) they also would like to have function pointers
> inside GTY-ed struct. So I believe my concern is potentially not only inside
> the MELT branch.
>
> Regards.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
>
