From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17786 invoked by alias); 17 Dec 2009 19:52:11 -0000 Received: (qmail 17401 invoked by uid 48); 17 Dec 2009 19:51:51 -0000 Date: Thu, 17 Dec 2009 19:52:00 -0000 Subject: [Bug ada/42412] New: Illegal program accepted, RM 8.5.1(3), renames of classwide object X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ludovic at ludovic-brenta dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg01746.txt.bz2 package pak1 is type T1 is tagged null record; x1: T1; x2: T1'class := x1; x3: T1'class renames x1; --ERROR: (detected) T1'class vs T1 x4: T1 renames x2; --ERROR: (missed) T1 vs T1'class end pak1; $ gnatmake pak1 gcc-4.3 -c pak1.ads pak1.ads:5:25: expected type "T1'class" defined at line 2 pak1.ads:5:25: found type "T1" defined at line 2 gnatmake: "pak1.ads" compilation error RM 8.5.1(3) says "The type of the object_name shall resolve to the type determined by the subtype_mark." T and T'class are considered to be different types, and shouldn't match. There is flexibility in RM 8.6(23) for T'class to sometimes match T, but only when the rules provide an "expected type". But this flexibility doesn't apply when the rules say "shall resolve to", as in this case, without giving an expected type. This subtle wording distinction can also be seen in other places in the RM, such as 12.4(4) vs. 12.4(5). -- Summary: Illegal program accepted, RM 8.5.1(3), renames of classwide object Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42412