From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47717 invoked by alias); 3 Jan 2019 22:12:03 -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 47701 invoked by uid 89); 3 Jan 2019 22:12:02 -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=polacek, Polacek, sense X-HELO: mail-qt1-f176.google.com Received: from mail-qt1-f176.google.com (HELO mail-qt1-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 22:12:00 +0000 Received: by mail-qt1-f176.google.com with SMTP id y20so38541943qtm.13 for ; Thu, 03 Jan 2019 14:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bLZqerX/RL1q9U+G6EDkG6oCt+E8UcnTAuDftlq8fi4=; b=bECVJpX/SGDBdd/WgZ+JK6mFJLgl6Zs5qtKtoCYtgGEiqbwW8kdpWnMXacWg1M38v7 +MK3lCRoHhDJGe7YU/mjGAHfrhWh0bwQh+xk/HCCy3yQ3Dp+xStDSa4VWATKJs0aQT55 qmfy+nt6xr47Zo7dLXT5/lTnq2+yGP6WSmA+dL4HWgYMcmTxbxpYeHncPVCQu9ngk5s9 lX8mTDyqfPbbej+u8aEly74eJo9FDJFyosvFXC8PxI+/drOUtb2z66tfSMpJnYo6RJuQ xF+s3HZoRwCgcJPW1l0ldwktkF/Z0KKVEJeHPWBJdr5BDqKzli1aR+JebbqyQhKGsUYH shxg== 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 w184sm27438652qkw.90.2019.01.03.14.11.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jan 2019 14:11:57 -0800 (PST) Subject: PING #2 [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363) From: Martin Sebor To: Jason Merrill , Marek Polacek Cc: Jakub Jelinek , "Joseph S. Myers" , Nathan Sidwell , Gcc Patch List References: <0f3f1395-adac-8b5f-82e4-e656bf1207fb@gmail.com> <20181211071726.GI12380@tucnak> <20181211204745.GB12380@tucnak> <2b1b9cf1-9e24-7705-aaa8-83d336a53a75@gmail.com> <20181211225228.GZ21364@redhat.com> <61c2ae91-d6c6-03fe-8ae2-a7f97b1d4151@gmail.com> Message-ID: <74651cd3-c7be-fdb4-1e52-3d2e7d7ee3d5@gmail.com> Date: Thu, 03 Jan 2019 22:12: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00125.txt.bz2 Ping: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00740.html On 12/18/18 2:42 PM, Martin Sebor wrote: > On 12/11/18 4:19 PM, Jason Merrill wrote: >> On 12/11/18 6:08 PM, Martin Sebor wrote: >>> On 12/11/18 3:52 PM, Marek Polacek wrote: >>>> On Tue, Dec 11, 2018 at 03:46:37PM -0700, Martin Sebor wrote: >>>>> On 12/11/18 1:47 PM, Jakub Jelinek wrote: >>>>>> On Tue, Dec 11, 2018 at 01:36:58PM -0700, Martin Sebor wrote: >>>>>>> Attached is an updated version of the patch that restores >>>>>>> the original behavior for the positional argument validation >>>>>>> (i.e., prior to r266195) for integral types except bool as >>>>>>> discussed. >>>>>> >>>>>> I thought Jason wanted to also warn for scoped enums in C++. >>>>> >>>>> I missed that.  It seems needlessly restrictive to me to reject >>>>> the preferred kind of an enum when ordinary enums are accepted. >>>>> Jason, can you confirm that you really want a warning for B >>>>> below when there is none for A (GCC 8 doesn't complain about >>>>> either, Clang complains about both, ICC about neither when >>>>> using alloc_size -- it doesn't understand alloc_align): >>>>> >>>>>    enum A { /* ... */ }; >>>>>    __attribute__ ((alloc_align (1))) void* f (A); >>>>> >>>>>    enum class B { /* ... */ }; >>>>>    __attribute__ ((alloc_align (1))) void* g (B); >>>>> >>>>> The only use case I can think of for enums is in APIs that try >>>>> to restrict the available choices of alignment to those of >>>>> the enumerators.  In that use case, I would expect it to make >>>>> no difference whether the enum is ordinary or the scoped kind. >>>> >>>> The reason was that C++ scoped enumerations don't implicitly convert to >>>> integral types. >>> >>> I'm not sure we're talking about the same thing.  There is no >>> conversion in the use case I described, the attribute argument >>> just refers to the function parameter, and the function is called >>> with an argument of the enumerated type of the parameter.  Like >>> this: >>> >>>    enum class Alignment { a4 = 4, a8 = 8 }; >>> >>>    __attribute__ ((alloc_align (1))) void* >>>    aligned_alloc (Alignment, size_t); >>> >>>    void *p = aligned_alloc (Alignment::a8, 32); >>> >>> My question is: if we think it makes sense to accept this use >>> case with ordinary enums why would we not want to make it possible >>> with scoped enums?  People tend to think of the latter as preferable >>> over the former. >> >> OK, I suppose it's reasonable to allow scoped enums as well. > > Are there any other suggestions for changes or should I take > this as an approval to commit the updated patch? > > https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00740.html > > Martin