From patchwork Thu Jul 19 21:05:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 172061 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]) by ozlabs.org (Postfix) with SMTP id 36A712C0125 for ; Fri, 20 Jul 2012 07:17:39 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1343337459; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Subject:Date:User-Agent:MIME-Version: Content-Type:Message-Id:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=hqsX3B80iSbUcPBhmTpNYJtU5gc=; b=Nfv6w0kv/CwJZFi IZNHWF/D90HNo9ltJg1ZaxVHKRZR5ZooAA10CE1PK1SRIqPnkZ6TN2djuNynhSnu UWO7W1ti8lqS7E24U5RqFzBG/pkhx4BTilbr1DmveXfSUG7q7RqVErEqoTijHgLI GUR+Rc41KlPvd+OgFYt+kBh4Hg5I= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:From:To:Subject:Date:User-Agent:MIME-Version:Content-Type:Message-Id:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ryo767PxApUsRWYnRRNxGJ6yLHYu+6mKjuVmhRT9xCFHU58H8Wztx4EgVRRVO/ bSAm/h7h/xxW4WA2Rgf9d/KHlkrGfgQu1amJ3B42hP/6k4Em4M2Eo4VwiDGngKS4 XPTX/bAeqha+A6NXTDRE6nf1h7BrDB1vJTtEaT7FD9yZ8=; Received: (qmail 9193 invoked by alias); 19 Jul 2012 21:17:36 -0000 Received: (qmail 9184 invoked by uid 22791); 19 Jul 2012 21:17:35 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Jul 2012 21:17:22 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 17A49290069 for ; Thu, 19 Jul 2012 23:17:27 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVkLd1PY5P+L for ; Thu, 19 Jul 2012 23:17:27 +0200 (CEST) Received: from hermes.site (ADijon-552-1-101-157.w90-33.abo.wanadoo.fr [90.33.60.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id DD3D3290020 for ; Thu, 19 Jul 2012 23:17:26 +0200 (CEST) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [Ada] Work around issue with overaligned derived types Date: Thu, 19 Jul 2012 23:05:41 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.34.10-0.6-desktop; KDE/4.4.4; x86_64; ; ) MIME-Version: 1.0 Message-Id: <201207192305.41588.ebotcazou@adacore.com> 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 This is a regression present on the mainline and 4.7 branch and visible on SPARC/Solaris, although it is latent everywhere. When a derived type is more aligned than its base type, things can go wrong when an object of the class- wide type is initialized with a value whose type is the derived type and is later used for dispatching, because the primitive operations (methods) of the derived type expect the larger alignment. Tested on x86_64-suse-linux, applied on the mainline and 4.7 branch. 2012-07-19 Eric Botcazou * gcc-interface/decl.c (gnat_to_gnu_entity) : Try to ensure that an object of CW type initialized to a value is sufficiently aligned for this value. 2012-07-19 Eric Botcazou * gnat.dg/derived_type3.adb: New test. * gnat.dg/derived_type3_pkg.ad[sb]: New helper. Index: ada/gcc-interface/decl.c =================================================================== --- ada/gcc-interface/decl.c (revision 189666) +++ ada/gcc-interface/decl.c (working copy) @@ -895,6 +895,16 @@ gnat_to_gnu_entity (Entity_Id gnat_entit debug_info_p); } + /* ??? If this is an object of CW type initialized to a value, try to + ensure that the object is sufficient aligned for this value, but + without pessimizing the allocation. This is a kludge necessary + because we don't support dynamic alignment. */ + if (align == 0 + && Ekind (Etype (gnat_entity)) == E_Class_Wide_Subtype + && No (Renamed_Object (gnat_entity)) + && No (Address_Clause (gnat_entity))) + align = get_target_system_allocator_alignment () * BITS_PER_UNIT; + #ifdef MINIMUM_ATOMIC_ALIGNMENT /* If the size is a constant and no alignment is specified, force the alignment to be the minimum valid atomic alignment. The @@ -904,7 +914,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entit necessary and can interfere with constant replacement. Finally, do not do it for Out parameters since that creates an size inconsistency with In parameters. */ - if (align == 0 && MINIMUM_ATOMIC_ALIGNMENT > TYPE_ALIGN (gnu_type) + if (align == 0 + && MINIMUM_ATOMIC_ALIGNMENT > TYPE_ALIGN (gnu_type) && !FLOAT_TYPE_P (gnu_type) && !const_flag && No (Renamed_Object (gnat_entity)) && !imported_p && No (Address_Clause (gnat_entity))