From patchwork Wed Jul 21 07:48:23 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 59408 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 D635EB70BD for ; Wed, 21 Jul 2010 17:48:37 +1000 (EST) Received: (qmail 7484 invoked by alias); 21 Jul 2010 07:48:34 -0000 Received: (qmail 7465 invoked by uid 22791); 21 Jul 2010 07:48:32 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jul 2010 07:48:28 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6L7mQQO012250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Jul 2010 03:48:26 -0400 Received: from Gift.redhat.com (vpn1-5-180.ams2.redhat.com [10.36.5.180]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6L7mOiS024330 for ; Wed, 21 Jul 2010 03:48:25 -0400 From: Nick Clifton To: gcc-patches@gcc.gnu.org Subject: RFA; Fix DW_AT_bit_offset generation for types with size > alignment Date: Wed, 21 Jul 2010 08:48:23 +0100 Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes 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 Hi Guys, A customer recently uncovered a problem with the XStormy16 port whereby the DWARF debug information being generated for bitfields was incorrect. The issue was bogus DW_AT_bit_offset fields, and it turns out to happen when the size of the type of the bitfield is larger than the alignment of the type of the bitfield. Eg: unsigned long a : 8; For the XStormy16 this bitfield has an alignment of 16-bits (the maximum for this target), but a type size of 32-bits. The problem is the code in dwarf2out.c:field_byte_offset() which assumes that the alignment will always be at least as big as the size. Fixed with the patch below. Tested with no regressions on an i686-pc-linux-gnu target as well as an xstormy16-elf target. OK to apply ? Cheers Nick gcc/ChangeLog 2010-07-21 Nick Clifton * dwarf2out.c (field_byte_offset): Handle the situation where a bit field's type alignment is less than the size of the type. Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 162327) +++ gcc/dwarf2out.c (working copy) @@ -15704,6 +15704,12 @@ type_size_in_bits = double_int_type_size_in_bits (type); type_align_in_bits = simple_type_align_in_bits (type); + /* If the type is bigger than its alignment, the computation to round + up object_offset_in_bits will in fact *reduce* the object offset. + Catch this here by setting the alignment to the size. */ + if (((unsigned HOST_WIDE_INT) type_align_in_bits) < double_int_to_uhwi (type_size_in_bits)) + type_align_in_bits = (unsigned int) double_int_to_uhwi (type_size_in_bits); + field_size_tree = DECL_SIZE (decl); /* The size could be unspecified if there was an error, or for