From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124260 invoked by alias); 9 Aug 2016 20:48:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 123705 invoked by uid 89); 9 Aug 2016 20:48:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:734, bit_field_ref, BIT_FIELD_REF, punts X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Aug 2016 20:48:19 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 351BE812EC; Tue, 9 Aug 2016 22:48:10 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRTOnXUINsbZ; Tue, 9 Aug 2016 22:48:10 +0200 (CEST) Received: from arcturus.home (ADijon-653-1-242-83.w83-196.abo.wanadoo.fr [83.196.17.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 1510F812E5; Tue, 9 Aug 2016 22:48:09 +0200 (CEST) From: Eric Botcazou To: Bernd Edlinger Cc: Richard Biener , "gcc-patches@gcc.gnu.org" , Jeff Law , Jakub Jelinek Subject: Re: [PATCH] Fix unaligned access when predictive commoning (PR 71083) Date: Tue, 09 Aug 2016 20:48:00 -0000 Message-ID: <7783559.v48Yu3xPbD@arcturus.home> User-Agent: KMail/4.14.10 (Linux/3.16.7-35-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2016-08/txt/msg00757.txt.bz2 > I think from Eric's comment in get_inner_ref it can be possible > in Ada that the outer object is accidentally byte-aligned > but the inner reference is not. In that case I think it is > better to generate a BIT_FIELD_REF instead of a COMPONENT_REF. The patch says get_bit_range instead... The comment therein means that bitfields can be nested in Ada: you can have a bitfield in a record which is itself a bitfield in another record. > Eric do you agree? Are there any Ada test cases where the > pcom optimization jumps in? According to the comment, data-ref analysis punts on bit offsets so I'm not sure how boff can be not byte-aligned. -- Eric Botcazou