From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12730 invoked by alias); 11 Dec 2018 23:08:53 -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 12702 invoked by uid 89); 11 Dec 2018 23:08:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt1-f193.google.com Received: from mail-qt1-f193.google.com (HELO mail-qt1-f193.google.com) (209.85.160.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Dec 2018 23:08:48 +0000 Received: by mail-qt1-f193.google.com with SMTP id d19so18472002qtq.9 for ; Tue, 11 Dec 2018 15:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=d8KOe5Dr72Ad9yES6Aq50WMrTZo/J5rt8puaMOIaFmQ=; b=Sxzaa/0qkbqVBHnMwzwMm1gw2+qxSpLPSmaPr5Z1LHPeV91YFaL70mLb4GC3tk5gvL uleEsf6DUTYzm0FjjTXcvCH/JC60PoQvYOWCDEUV2pytzDtvdeV3k08lFuCjtyPhqTHR jU3KbhliNmIa1euMhiFv0bqOQko7KhfSJEOJbivoVhXOFU7cF8bw9Qrg+eX0IIyaJglj bWByXKnDXfgud9BULdeTb9g4RPbobuZ5UiaMkoYhOgeobtdcCaPh/xqzgNwgQHieXIIq zV1dqZVhK2VVOEVLnCMEnkShrQ0vXY+RXkt3NFXcHVs0YsOlItK8H1Qp4Li5t+TgH0sz 0MGA== Return-Path: Received: from localhost.localdomain (97-118-99-160.hlrn.qwest.net. [97.118.99.160]) by smtp.gmail.com with ESMTPSA id b75sm3713801qkh.4.2018.12.11.15.08.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 15:08:45 -0800 (PST) Subject: Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363) To: Marek Polacek Cc: Jakub Jelinek , "Joseph S. Myers" , Jason Merrill , 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> From: Martin Sebor Message-ID: <61c2ae91-d6c6-03fe-8ae2-a7f97b1d4151@gmail.com> Date: Tue, 11 Dec 2018 23:08: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: <20181211225228.GZ21364@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00752.txt.bz2 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. Martin