public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "aoliva at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/25844] [4.9/5/6 regression] ICE on overloaded renames Date: Sun, 18 Oct 2015 04:57:00 -0000 [thread overview] Message-ID: <bug-25844-4-1rya20uhsB@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-25844-4@http.gcc.gnu.org/bugzilla/> 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.
prev parent reply other threads:[~2015-10-18 4:57 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-25844-4@http.gcc.gnu.org/bugzilla/> 2011-06-27 15:11 ` [Bug ada/25844] [4.3/4.4/4.5/4.6/4.7 " rguenth at gcc dot gnu.org 2012-03-13 15:33 ` [Bug ada/25844] [4.5/4.6/4.7/4.8 " jakub at gcc dot gnu.org 2012-07-02 13:52 ` [Bug ada/25844] [4.6/4.7/4.8 " rguenth at gcc dot gnu.org 2013-04-12 15:18 ` [Bug ada/25844] [4.7/4.8/4.9 " jakub at gcc dot gnu.org 2014-06-12 13:49 ` [Bug ada/25844] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org 2014-12-19 13:44 ` [Bug ada/25844] [4.8/4.9/5 " jakub at gcc dot gnu.org 2015-06-23 8:27 ` [Bug ada/25844] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org 2015-06-26 20:19 ` [Bug ada/25844] [4.9/5/6 " jakub at gcc dot gnu.org 2015-06-26 20:39 ` jakub at gcc dot gnu.org 2015-10-18 4:57 ` aoliva at gcc dot gnu.org [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-25844-4-1rya20uhsB@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).