From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43971 invoked by alias); 11 Dec 2018 22:46:45 -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 43952 invoked by uid 89); 11 Dec 2018 22:46:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2589, Established, ICC 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 22:46:42 +0000 Received: by mail-qt1-f193.google.com with SMTP id i7so18406034qtj.10 for ; Tue, 11 Dec 2018 14:46:41 -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=Dj9zXxC+171Z4Blz4clTKQ5jSomyzzbJ+s6t8+q1lEU=; b=gu1LWFIO+3aoGwBidltfvUQRQyNEZr0FyKGhtCF3sZ6Bx4gVeY1UCDRqggGEQc+jF3 juR2xto3WtACph03TrF3QBoqyKRZeXQw749Fn9lBB5lcTXstX3Cjo1vvvyewTjB1TTuC kfPLaVT98pIgiSjt/MNibJe5+nhm8/I/rlv7ixqVJ9kc/iEWEACDRdMZVSXs1uNS84CI nTBmREM9skaUT3JAuwAk/PhwijBQaaZJi7LzdH3d4X3FfEBIjvCQcBChW++HCShvWMhp x7/kK9WN44aQ9prfe2tZaDTo1J25u6cI5Jzuaw0Xy4qI7oJmFpGPmQlzHwZA0Yv+KB68 MpDw== Return-Path: Received: from localhost.localdomain (97-118-99-160.hlrn.qwest.net. [97.118.99.160]) by smtp.gmail.com with ESMTPSA id 64sm8003014qke.39.2018.12.11.14.46.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 14:46:39 -0800 (PST) Subject: Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363) To: Jakub Jelinek Cc: "Joseph S. Myers" , Marek Polacek , Jason Merrill , Nathan Sidwell , Gcc Patch List References: <0f3f1395-adac-8b5f-82e4-e656bf1207fb@gmail.com> <20181211071726.GI12380@tucnak> <20181211204745.GB12380@tucnak> From: Martin Sebor Message-ID: <2b1b9cf1-9e24-7705-aaa8-83d336a53a75@gmail.com> Date: Tue, 11 Dec 2018 22:46: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: <20181211204745.GB12380@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00747.txt.bz2 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. > >> + else if (code == INTEGER_TYPE) >> + /* For integers, accept enums, wide characters and other types >> + that match INTEGRAL_TYPE_P except for bool. */ >> + type_match = (INTEGRAL_TYPE_P (argtype) >> + && TREE_CODE (argtype) != BOOLEAN_TYPE); > > So it would better be: > type_match = (TREE_CODE (argtype) == INTEGER_TYPE > || (TREE_CODE (argtype) == ENUMERAL_TYPE > && !ENUM_IS_SCOPED (argtype))); > >> --- gcc/doc/extend.texi (revision 266966) >> +++ gcc/doc/extend.texi (working copy) >> @@ -2471,7 +2471,9 @@ The @code{aligned} attribute can also be used for >> @item alloc_align (@var{position}) >> @cindex @code{alloc_align} function attribute >> The @code{alloc_align} attribute may be applied to a function that >> -returns a pointer and takes at least one argument of an integer type. >> +returns a pointer and takes at least one argument of an integer or >> +enumerated type, but not @code{bool}. Arguments of other types are >> +diagnosed. > > The keyword is _Bool in C, so wouldn't it be better to say but not Boolean > type or but not @code{bool} or @code{_Bool}? It makes little difference. Established practice in the manual is @code{bool} (14 occurrences). There are just three instances of @code{_Bool} in prose in doc/*.texi. It's simpler to refer to @code{bool} unless we are specifically talking about the C keyword/type. Martin