https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Richard Biener from comment #3)
> > GC only supports POD-like data structures, esp. proper inheritance is not
> > supported so supporting virtual functions looks useless.
>
> Hmmm, in that case I'll remove the GTY handling from irange. At least for
> SSA_NAME_RANGE_INFO this shouldn't be a problem, because we don't stream out
> irange, but an irange_storage_allocator (with trailing_wide_ints).
>
> OTOH, I see:
>
> struct GTY (()) ipa_jump_func
> {
> ...
> ...
> /* Information about value range, containing valid data only when vr_known
> is
> true. The pointed to structure is shared betweed different jump
> functions. Use ipa_set_jfunc_vr to set this field. */
> value_range *m_vr;
>
> Will this be a problem?
Well, the GTY annotation is so GC can properly compute reachability of
GC allocated memory (and release unreachable portions). You can't simply
exempt stuff here - LTO streaming is completely unrelated to GC (but PCH
streaming is not).
> BTW, it'd be nice if the gengtype parser would error with an appropriate
> message for attempted uses of GTY with non POD-like structures, etc.
gengtype unfortunately isn't a complete C++ parser (not even close), so
C++ and GC doesn't mix well.
