This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/70594] [6 Regression] -fcompare-debug failure


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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #7)
> copy_node_stat allocates  a new  UID for decls.  so despite its name
> 'copy_decl_no_change' does cause a change.
> 
> That decl never escapes out of the const-expr machinery, but of cause causes
> later decls to have different numberings.  (which is what we're observing).
> 
> I suppose the constexpr machinery could restore the next_decl_uid (and
> perhaps others?) after copy_fn -- or somewhere in that call chain.  But that
> does seem rather icky.

Yeah, that is not really the right thing.

> Alternatively copy_decl_no_change could not allocate new UIDs?

copy_fn is used solely by the constexpr stuff, so the primary question is if we
really need to duplicate any decls for those or not.  Changing
copy_decl_no_change is undesirable, it is used for plenty of other cases.
But, to avoid any decl remapping one could just use another function for that,
or could abuse
  id->prevent_decl_creation_for_types = true;
  id->remapping_type_depth = 1;
etc.  The thing is, what is copy_fn copying the fn from (constexpr function
with just parsed body, or parsed and already genericized, or parsed,
genericized and gimplified, or even after some GIMPLE optimizations) and what
undesirable effects not copying the decl might have (e.g. during GIMPLE phases
perhaps DECL_VALUE_EXPR could be set for various decls, or their alignment
could be changed, whatever other changes are done) and what exactly Patrick's
patch did (did we in the past always copy_fn just once each constexpr, but now
we do it multiple times, if we GC in between)?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]