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 ada/25844] [4.9/5/6 regression] ICE on overloaded renames


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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #16 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 36536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36536&action=edit
Reduced testcase

Here's a reduced version of the testcase.  The problem seems to have to do with
the double vs single access for V, but oddly it doesn't occur if the initial
line, apparently unused, is removed.  The problem doesn't occur either if A is
not a private type, or if the packages are not subpackages of X, or if J is
removed from X.L, or if J and B are defined as non-generic packages.

When comparing D.F with F, Check_Conformance fails the test for equivalent
Directly_Designated_Type in Old_Formal_Base and New_Formal_base, so
Access_Type_Match is false (though AFAICT it should be true), but it is
Conforming_Types, called with these base types, that eventually crashes, as
Subtypes_Statically_Match gets an access to A in t1 and A in t2.  When it takes
the Directly_Designated_Type of the latter, it gets zero; predicates_match
passes it to get_rep_item, that calls first_rep_item and gets -1, that causes
nkind to crash.

Clearly we need some more smarts in handling this kind of situation, either
during generic substitution or when checking access types for conformance.


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