From patchwork Thu Apr 11 12:59:19 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnaud Charlet X-Patchwork-Id: 235734 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id D434E2C0092 for ; Thu, 11 Apr 2013 22:59:38 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=E6ha5wU8ZCXUj0VY57xg/8qEOLu0ejtJWF6wctiOyySeKFuY9J hJlerqYF5Pw2MW+siyRk3p0NnVksT5KREdzqfWeZsUXLlVA88Z5I9sGFXxIeyaDW Kb86qfTIvd0ZNmwLUt9il3TjlxkRNheUeY7Pys9uhLme32DpJ8HQ+HArs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=hLN/I6lbNNl+UrfOL0nHdJNZ3rY=; b=jf6Je4Rs+Yr11tfGkFeH Jn58/6aU7PzL/BLvEUA9V8nG7rNVgEnd2tGanxsb6Prv5zNzdVVNLAX4DcOLGH9y 5pdVpdiRYNCUlK5JVSmR//9ge44gZPK0ijcwPeHzAWOuee/WLd/1sqP3hMLv6xKU hdbomtH0YktIqersmQSWC58= Received: (qmail 8563 invoked by alias); 11 Apr 2013 12:59:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 8547 invoked by uid 89); 11 Apr 2013 12:59:22 -0000 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_HOSTKARMA_NO autolearn=ham version=3.3.1 Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 11 Apr 2013 12:59:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1461C2EC11; Thu, 11 Apr 2013 08:59:20 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q9Q8pL0lm69o; Thu, 11 Apr 2013 08:59:20 -0400 (EDT) Received: from kwai.gnat.com (kwai.gnat.com [205.232.38.4]) by rock.gnat.com (Postfix) with ESMTP id DF74C2E123; Thu, 11 Apr 2013 08:59:19 -0400 (EDT) Received: by kwai.gnat.com (Postfix, from userid 4192) id DEBFD3FF09; Thu, 11 Apr 2013 08:59:19 -0400 (EDT) Date: Thu, 11 Apr 2013 08:59:19 -0400 From: Arnaud Charlet To: gcc-patches@gcc.gnu.org Cc: Thomas Quinot Subject: [Ada] Incorrect handling of type conversion with endianness change Message-ID: <20130411125919.GA9683@adacore.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Found: No This change fixes an oversight in the predicate that determines whether two composite types have the same representation (difference of scalar storage order was ignored, causing the compiler to incorrectly omit a per-component assignment in this case). The following test case must compile and execute as shown: $ gnatmake conv_endianness $ ./conv_endianness X_L = (S => 12345, C => 'a') X_H = (S => 23456, C => 'b') X_H = (S => 12345, C => 'a') with System; use System; with Ada.Text_IO; use Ada.Text_IO; procedure Conv_Endianness is type Short is mod 2**16; type R_L is record S : Short; C : Character; end record; for R_L'Bit_Order use Low_Order_First; for R_L'Scalar_Storage_Order use Low_Order_First; for R_L use record S at 0 range 0 .. 15; C at 2 range 0 .. 7; end record; type R_H is new R_L; for R_H'Bit_Order use High_Order_First; for R_H'Scalar_Storage_Order use High_Order_First; for R_H use record S at 0 range 0 .. 15; C at 2 range 0 .. 7; end record; procedure Dump (Name : String; S : Short; C : Character) is begin Put_Line (Name & " = (S =>" & S'Img & ", C => '" & C & "')"); end Dump; X_L : R_L; X_H : R_H; begin X_L.S := 12345; X_L.C := 'a'; Dump ("X_L", X_L.S, X_L.C); X_H.S := 23456; X_H.C := 'b'; Dump ("X_H", X_H.S, X_H.C); X_H := R_H (X_L); Dump ("X_H", X_H.S, X_H.C); end Conv_Endianness; Tested on x86_64-pc-linux-gnu, committed on trunk 2013-04-11 Thomas Quinot * sem_ch13.adb (Same_Representation): Two types with different scalar storage order never have the same representation. Index: sem_ch13.adb =================================================================== --- sem_ch13.adb (revision 197781) +++ sem_ch13.adb (working copy) @@ -9448,12 +9448,16 @@ return False; end if; - -- Representations are different if component alignments differ + -- Representations are different if component alignments or scalar + -- storage orders differ. if (Is_Record_Type (T1) or else Is_Array_Type (T1)) and then (Is_Record_Type (T2) or else Is_Array_Type (T2)) - and then Component_Alignment (T1) /= Component_Alignment (T2) + and then + (Component_Alignment (T1) /= Component_Alignment (T2) + or else + Reverse_Storage_Order (T1) /= Reverse_Storage_Order (T2)) then return False; end if; @@ -9530,7 +9534,7 @@ function Same_Rep return Boolean; -- CD1 and CD2 are either components or discriminants. This - -- function tests whether the two have the same representation + -- function tests whether they have the same representation. -------------- -- Same_Rep -- @@ -9540,8 +9544,11 @@ begin if No (Component_Clause (CD1)) then return No (Component_Clause (CD2)); + else + -- Note: at this point, component clauses have been + -- normalized to the default bit order, so that the + -- comparison of Component_Bit_Offsets is meaningful. - else return Present (Component_Clause (CD2)) and then