[Bug other/106314] New: GTY fails on virtual int but not virtual void

[Bug other/106314] New: GTY fails on virtual int but not virtual void

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314

            Bug ID: 106314
           Summary: GTY fails on virtual int but not virtual void
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldyh at gcc dot gnu.org
                CC: amacleod at redhat dot com
  Target Milestone: ---

GTY markers for a struct having virtual int/bool/etc fails, but interestingly
void works:

struct GTY(()) foobar
{
  virtual void foo();
  virtual int bar();
  virtual bool none();
};

build/gengtype  \
                    -S /home/aldyh/src/gcc/gcc -I gtyp-input.list -w
tmp-gtype.state
/home/aldyh/src/gcc/gcc/value-range.h:260: parse error: expected '(', ')',
'GTY', or an identifier, have 'int'
/home/aldyh/src/gcc/gcc/value-range.h:261: parse error: expected '(', ')',
'GTY', or an identifier, have 'bool'

I would prefer not to have to mark trivial structures containing virtuals
manually with GTY((user)).

Any hints from the gengtype experts?

[Bug middle-end/106314] GTY fails on virtual int but not virtual void

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Why do you need these structures to be in GC memory anyways?

[Bug middle-end/106314] GTY fails on virtual int but not virtual void

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
The upcoming floating point ranges (frange) are small enough (one or two words)
that I thought we could get away with streaming them as is to GC for global
ranges (SSA_NAME_RANGE_INFO).

We have a mechanism in place to stream out whatever we want for each range
type, so if this is really a problem I can just stream out exactly what I need
instead of having the entire frange in GC memory.  However, if this is really a
problem, perhaps we should fail in gengtype when we see the virtual with some
more meaningful parse error?

[Bug middle-end/106314] GTY fails on virtual int but not virtual void

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
GC only supports POD-like data structures, esp. proper inheritance is not
supported so supporting virtual functions looks useless.

[Bug middle-end/106314] GTY fails on virtual int but not virtual void

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106314

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(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?

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.

Thanks.

[Bug middle-end/106314] GTY fails on virtual int but not virtual void

[rguenth at gcc dot gnu.org]

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.