From patchwork Wed Jun 29 19:06:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 642185 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rfsbM6Knfz9snl for ; Thu, 30 Jun 2016 05:06:21 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=D/Aza8VR; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=h7ITrMkmv3j6myf65KuILRJNLZdNNmAH4tNWPoggh5SIWV9ZVP v+i4skEGdNbYxsST27PnKQ9FWbigbSeQQkRRD8f5p6CAXpQCKjUoHiCqbsOGdQZM qIA5VbdntkdSI5n0sxrzDFcg4Q+4l9qC6l6Uk+fme436H39qPPvf5jr8M= 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:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=yBC96+j39AL76EVMTeLnYEP87Rc=; b=D/Aza8VRSYKsO3vNOizG 87DD8HnQ37jzXaAecKYi7xqrO47UHlPBvGWTyLqRqm4/GArMdOaiB1NyaX7iL9Dv wTAscZvRfYaPrLT2Pb0vhRPB1B38gVjDGvUlgVr1Iwr+NQCXrU89ioPVq0kQrREy xkR2VYNlCT1AeCIliAxatpk= Received: (qmail 3306 invoked by alias); 29 Jun 2016 19:06:13 -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 3296 invoked by uid 89); 29 Jun 2016 19:06:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=TYPE_ALIGN, type_align, fundamental, HTo:U*dodji X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 29 Jun 2016 19:06:11 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1A0C77DCD6 for ; Wed, 29 Jun 2016 19:06:10 +0000 (UTC) Received: from localhost.localdomain (vpn1-5-37.ams2.redhat.com [10.36.5.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5TJ68dM025407; Wed, 29 Jun 2016 15:06:09 -0400 To: GCC Patches , Dodji Seketeli From: Bernd Schmidt Subject: Problem in cxx_fundamental_alignment_p? Message-ID: <98900257-b106-63b6-6579-be0873a61587@redhat.com> Date: Wed, 29 Jun 2016 21:06:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 X-IsSubscribed: yes I came across what I think is a bug in cxx_fundamental_alignment_p. User alignments are specified in units of bytes. This is documented, and we can also see the following in handle_aligned_attribute, for the case when we have no args: align_expr = size_int (ATTRIBUTE_ALIGNED_VALUE / BITS_PER_UNIT); Then, we compute the log of that alignment in check_user_alignment: i = check_user_alignment (align_expr, true) That's the log of the alignment in bytes, as we can see a little further down: SET_TYPE_ALIGN (*type, (1U << i) * BITS_PER_UNIT); Then, we call check_cxx_fundamental_alignment_constraints, which recomputes the alignment (in bytes) from that log: unsigned requested_alignment = 1U << align_log; It then calls cxx_fundamental_alignment_p, where we compare it to TYPE_ALIGN values, which are specified in bits. So I think we have a mismatch there. Does that sound right? The patch below was bootstrapped and tested on x86_64-linux, without issues, but I'm not convinced this code is covered by any testcase. Dodji? Bernd * c-common.c (cxx_fundamental_alignment_p): Use TYPE_ALIGN_UNIT, not TYPE_ALIGN. Index: gcc/c-family/c-common.c =================================================================== --- gcc/c-family/c-common.c (revision 237797) +++ gcc/c-family/c-common.c (working copy) @@ -7668,10 +7668,10 @@ fail: return NULL_TREE; } -/* Check whether ALIGN is a valid user-specified alignment. If so, - return its base-2 log; if not, output an error and return -1. If - ALLOW_ZERO then 0 is valid and should result in a return of -1 with - no error. */ +/* Check whether ALIGN is a valid user-specified alignment, specified + in bytes. If so, return its base-2 log; if not, output an error + and return -1. If ALLOW_ZERO then 0 is valid and should result in + a return of -1 with no error. */ int check_user_alignment (const_tree align, bool allow_zero) { @@ -12700,9 +12700,9 @@ scalar_to_vector (location_t loc, enum t return stv_nothing; } -/* Return true iff ALIGN is an integral constant that is a fundamental - alignment, as defined by [basic.align] in the c++-11 - specifications. +/* Return true iff ALIGN, which is specified in bytes, is an integral + constant that is a fundamental alignment, as defined by + [basic.align] in the c++-11 specifications. That is: @@ -12712,10 +12712,11 @@ scalar_to_vector (location_t loc, enum t alignof(max_align_t)]. */ bool -cxx_fundamental_alignment_p (unsigned align) +cxx_fundamental_alignment_p (unsigned align) { - return (align <= MAX (TYPE_ALIGN (long_long_integer_type_node), - TYPE_ALIGN (long_double_type_node))); + unsigned limit = MAX (TYPE_ALIGN_UNIT (long_long_integer_type_node), + TYPE_ALIGN_UNIT (long_double_type_node)); + return align <= limit; } /* Return true if T is a pointer to a zero-sized aggregate. */