Hi all, (Daniel, now that SoC is over, I guess this is the last my email with CC: to you, unless you prefer otherwise :)
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. I see following options how to fix it: 1) Change the big array of function pointers to the linked list of linked lists, just like GC roots are currently stored. I don't like this solution at all, because marker function lookup has to be fast. Included for completeness only. 2) Instead of a single global enum of type tags and corresponding array of markers, generate one for every frontend. Does GCC have a long-term plan to have several frontends linked into a single executable? In this case this solution would need some further tweaking. 3) Leave single enum and array, but instead of initializing it with addresses of frontend-specific routines, put placeholders there and have frontend specific setup routine which would set those pointers to correct values. 4) Pull all data types from all front ends into gtype-desc.*. Again, included for completeness, even if this is technically possible. For me option 2) looks much better than the rest. Are there any reasons not to implement it? -- Thanks, Laurynas
