From patchwork Fri Nov 30 22:32:15 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 203065 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 BA46B2C007D for ; Sat, 1 Dec 2012 09:36:33 +1100 (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=1354919794; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version: Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=Z5cA9PiBV6lL1IV0LReUHVkg3zs=; b=pdOlBJau+KVO0TD gDGHqQAyKzm/U6E65jRxUP+uDgHbtzKDzAeuvfGpTMZgJsY+uy6Enau1gzSEJUuS DlxlIVTts8ORrnIw7/QP18hUbu7jfg7P6c6F7tXTFe8HLz+wffZ3fboXURAFUr5O 6P5dD4Vsesw9quPah0ge18R99VhA= 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:Message-ID:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=w8myh9Z/zghGiKCZE1lVVXlpVMJsLUIgz0Q5zY0xDTwxWw4YT0wg+pabgE8D46 YjxCqmna1bNNqYd9V+CMzq1F2TrdcZcSyzyWZ7djLLf6NwQvc4ec6A8/5/KsgYww Lfx8cDov+k2aWj9tU2yia5lpT723ItEIWAieuIbtxDpIM=; Received: (qmail 14244 invoked by alias); 30 Nov 2012 22:36:29 -0000 Received: (qmail 13998 invoked by uid 22791); 30 Nov 2012 22:36:28 -0000 X-SWARE-Spam-Status: No, hits=-2.2 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; Fri, 30 Nov 2012 22:36:22 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 31DB1CB2962 for ; Fri, 30 Nov 2012 23:36:26 +0100 (CET) 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 rzRTlg1Qr7CQ for ; Fri, 30 Nov 2012 23:36:26 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id EC426CB2105 for ; Fri, 30 Nov 2012 23:36:25 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: Fix segfault on degenerate bitfield case Date: Fri, 30 Nov 2012 23:32:15 +0100 Message-ID: <2334390.fbpLepaxAm@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.16-desktop; KDE/4.7.2; x86_64; ; ) MIME-Version: 1.0 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 segfault on a degenerate bitfield case introduced by the rewrite of the bitfield machinery. In Ada, we have bitfields of size zero and we ask the middle-end to generate accesses to them. This doesn't work anymore because get_best_mode now returns VOIDmode instead of QImode in this case, which wreaks havoc later. The patchlet just restores the previous behaviour. It also makes the comment describing the computation of bitregion_end_ more explicit, as the original formulation is a bit terse on second reading, even for the reviewer. :-) Bootstrapped/regtested on x86-64/Linux, applied on the mainline as obvious. 2012-11-30 Eric Botcazou * stor-layout.c (bit_field_mode_iterator::bit_field_mode_iterator): Deal with degenerate cases where the bitsize isn't positive. Rework comment. 2012-11-30 Eric Botcazou * gnat.dg/specs/pack9.ads: New test. Index: stor-layout.c =================================================================== --- stor-layout.c (revision 193985) +++ stor-layout.c (working copy) @@ -2648,10 +2648,14 @@ bit_field_mode_iterator { if (!bitregion_end_) { - /* We can assume that any aligned chunk of UNITS bits that overlaps - the bitfield is mapped and won't trap. */ - unsigned HOST_WIDE_INT units = MIN (align, MAX (BIGGEST_ALIGNMENT, - BITS_PER_WORD)); + /* We can assume that any aligned chunk of ALIGN bits that overlaps + the bitfield is mapped and won't trap, provided that ALIGN isn't + too large. The cap is the biggest required alignment for data, + or at least the word size. And force one such chunk at least. */ + unsigned HOST_WIDE_INT units + = MIN (align, MAX (BIGGEST_ALIGNMENT, BITS_PER_WORD)); + if (bitsize <= 0) + bitsize = 1; bitregion_end_ = bitpos + bitsize + units - 1; bitregion_end_ -= bitregion_end_ % units + 1; }