This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to tag frontend-specific types?
Hey, just cause SoC is over doesn't mean i'm not happy to answer your
questions to the degree I can, so please, keep cc'ing me.
That's great, thanks :)
> I'd like to get your feedback about design of frontend-specific type
> tag infrastructure in gengtype.
>
> First of all, how things are done currently in WIP version:
> 1) A big enum is created for all the gengtype-recognized types in
> gtype-desc.h, regardless of the frontend they belong to.
> 2) A big array of function pointers is declared for the same set of
> types in gtype-desc.h and initialized in gtype-desc.c with
> automatically generated names for marker functions.
> 3) A new set of marker functions is generated. They are dispatched to
> the output files using the common old
> get_output_file_with_visibility() logic, i.e. frontend-specific
> functions go to the frontend-specific generated files, not
> gtype-desc.*.
>
> This setup is flawed: the array in gtype-dec.c is initialized using
> function pointers that do not resolve at compilation time.
It's not clear to me why this is true, if the array is initialized with
auto-generated marker-names.
What functions do not resolve, exactly?
For example, when cc1-dummy is linked:
libbackend.a(gtype-desc.o):(.rodata+0x588): undefined reference to
`gt_tggc_mx_prod_token_parm_item'
This is a name of my marker procedure for struct prod_token_parm_item,
which is defined in treelang/treelang.h. The prototype for this
function is written to the global gtype-desc.h file, and
implementation to gtype-treelang.h, which is included by
treelang/tree1.c, which is naturally not linked in to cc1-dummy. Note
how including prototypes to the global gtype-desc.h moves this error
from compilation to link time.
--
Thanks,
Laurynas