From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104105 invoked by alias); 8 Jan 2019 00:32:19 -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 104089 invoked by uid 89); 8 Jan 2019 00:32:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=involving, an, for, the X-HELO: mail-qt1-f171.google.com Received: from mail-qt1-f171.google.com (HELO mail-qt1-f171.google.com) (209.85.160.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Jan 2019 00:32:16 +0000 Received: by mail-qt1-f171.google.com with SMTP id d19so2607398qtq.9 for ; Mon, 07 Jan 2019 16:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PHMMC1T9PPf16YqqNYdv4XBE6M3PwBzGcqRcf0Xc2KA=; b=SU1aLsJ6Eebr/5Nh8Md9RQ2d8aQU16vgMIvock0v2uM9S0CqCbkdUzVaB0PKGJF+pR KR/fSnLEm4RYmG71PLr4+dGhdqjR2YoxNsoQJBmar2wvp0FOQmjGy8+RjtXqiC3kU43I O0H71OQxsmS33RYUR//JZpBNcRk3DiX98n+7eBXmhkSfgkPpvUd0p1ic+XFi4luPI7Q1 9PNnClKaMS6JLO22RL+x/GrS2yWydb8LAChPQ8UoQyVAS6NnzGU+Dnd3DkaZtOG4ER9L KWxTp+12vZJw4ZOMMcd7MoVG9kOE0lKPFFLPryKsHVqsq9gZXcUg3Z3OnvlNol4QJuX8 pLIw== Return-Path: Received: from [192.168.0.106] (174-16-101-177.hlrn.qwest.net. [174.16.101.177]) by smtp.gmail.com with ESMTPSA id e29sm8271251qtc.74.2019.01.07.16.32.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jan 2019 16:32:13 -0800 (PST) Subject: PING #2 [PATCH] handle expressions in __builtin_has_attribute (PR 88383) From: Martin Sebor To: Jeff Law , Gcc Patch List References: <6b1f15b6-1446-21a2-54aa-b92ec6b5541f@redhat.com> <5599edd4-61ad-24ce-d19e-376dd9398183@gmail.com> <688c62e2-966a-c950-ca63-b58003610c62@gmail.com> <96b8cb0a-bdfd-b122-ee31-4f156ae09922@gmail.com> <474b59cc-4322-cf8d-e316-9eebefcddcab@gmail.com> Message-ID: <00fda3b4-0cb2-f85e-b4d1-7676834d8303@gmail.com> Date: Tue, 08 Jan 2019 00:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <474b59cc-4322-cf8d-e316-9eebefcddcab@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00360.txt.bz2 Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html On 1/3/19 3:22 PM, Martin Sebor wrote: > Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html > > On 12/20/18 7:51 PM, Martin Sebor wrote: >> Jeff, did this and the rest of the discussion answer your question >> and if so, is the patch okay to commit? >> >>    https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html >> >> Martin >> >> On 12/13/18 12:48 PM, Martin Sebor wrote: >>> On 12/13/18 12:20 PM, Martin Sebor wrote: >>>> On 12/13/18 11:59 AM, Jeff Law wrote: >>>>> On 12/5/18 8:55 PM, Martin Sebor wrote: >>>>>> The __builtin_has_attribute function fails with an ICE when >>>>>> its first argument is an expression such as INDIRECT_REF, or >>>>>> many others.  The code simply assumes it's either a type or >>>>>> a decl.  The attached patch corrects this oversight. >>>>>> >>>>>> While testing the fix I also noticed the C++ front end expects >>>>>> the first operand to be a unary expression, which causes most >>>>>> other kinds of expressions to be rejected.  The patch fixes >>>>>> that as well. >>>>>> >>>>>> Finally, while testing the fix even more I realized that >>>>>> the built-in considers the underlying array itself in ARRAY_REF >>>>>> expressions rather than its type, which leads to inconsistent >>>>>> results for overaligned arrays (it's the array itself that's >>>>>> overaligned, not its elements).  So I fixed that too and >>>>>> adjusted the one test designed to verify this. >>>>>> >>>>>> Tested on x86_64-linux. >>>>>> >>>>>> Martin >>>>>> >>>>>> gcc-88383.diff >>>>>> >>>>>> PR c/88383 - ICE calling __builtin_has_attribute on a reference >>>>>> >>>>>> gcc/c-family/ChangeLog: >>>>>> >>>>>>     PR c/88383 >>>>>>     * c-attribs.c (validate_attribute): Handle expressions. >>>>>>     (has_attribute): Handle types referenced by expressions. >>>>>>     Avoid considering array attributes in ARRAY_REF expressions . >>>>>> >>>>>> gcc/cp/ChangeLog: >>>>>> >>>>>>     PR c/88383 >>>>>>     * parser.c (cp_parser_has_attribute_expression): Handle >>>>>> assignment >>>>>>     expressions. >>>>>> >>>>>> gcc/testsuite/ChangeLog: >>>>>> >>>>>>     PR c/88383 >>>>>>     * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. >>>>>>     * c-c++-common/builtin-has-attribute-6.c: New test. >>>>> Well, the high level question here is do we want to support this >>>>> builtin >>>>> on expressions at all.  Generally attributes apply to types and decls, >>>>> not expressions. >>>>> >>>>> Clearly we shouldn't fault, but my first inclination is that the >>>>> attribute applies to types or decls, not expressions.  In that case we >>>>> should just be issuing an error. >>>>> >>>>> I could be convinced otherwise, so if you think we should support >>>>> passing expressions to this builtin, make your case. >>>> >>>> The support is necessary in order to determine the attributes >>>> in expressions such as: >>>> >>>>    struct S { __attribute__ ((packed)) int a[32]; }; >>>> >>>>    extern struct S s; >>>> >>>>    _Static_assert (__builtin_has_attribute (s.a, packed)); >>> >>> An example involving types might be a better one: >>> >>>    typedef __attribute__ ((may_alias)) int* BadInt; >>> >>>    void f (BadInt *p) >>>    { >>>      _Static_assert (__builtin_has_attribute (*p, may_alias)); >>>    } >>> >>> Martin >> >