From patchwork Mon Nov 26 15:42:36 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 201712 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]) by ozlabs.org (Postfix) with SMTP id 4BF102C008C for ; Tue, 27 Nov 2012 02:42:54 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1354549375; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=3nOXn/BkvgxWAIhnzmk8zvfev2s=; b=Yo5ZD/gXz6UpKcl u/lplRBNgoUyxnHfnNyl7iAutIoPyLGLD1e4+Rc0akgPgdxX+ol8+blpWxswC5pY 2cU8NWKiJWtzBEZK3pC1hHy8IIXRnqnafTCLHpvqb8Ojz5aObzpLL3Bdco01kNHl F5j2OklRwItnqdBbnxrVTf9zlp5Y= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=gt+B3rv1HdC3IWAeqheTwmdmc7NGK4GN6H1uRn2oIzLrIlb8hJesDaNg55OzKQ iylwfeoNrrFrkJzwvX6sKSTFUEA7B5T8Zjqlh/Oy+yp00vLBfJFtTtxMBBeyoxzK x6oKZcjVwO2EzX5CrZY/jlEZVv70oXBax8rUZO/ljsIEs=; Received: (qmail 25160 invoked by alias); 26 Nov 2012 15:42:47 -0000 Received: (qmail 25076 invoked by uid 22791); 26 Nov 2012 15:42:46 -0000 X-SWARE-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL, BAYES_00, FSL_NEW_HELO_USER, RCVD_IN_HOSTKARMA_NO, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 15:42:41 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qAQFgcuX014814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Nov 2012 15:42:39 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qAQFgcv0008656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2012 15:42:38 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qAQFgckw026367; Mon, 26 Nov 2012 09:42:38 -0600 Received: from [192.168.1.4] (/79.47.193.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Nov 2012 07:42:38 -0800 Message-ID: <50B38DEC.8090004@oracle.com> Date: Mon, 26 Nov 2012 16:42:36 +0100 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: "gcc-patches@gcc.gnu.org" CC: Jason Merrill Subject: [C++ Patch / RFC] PR 51242 X-IsSubscribed: yes 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 Hi, this PR is about the rejection (in C++11 mode of course) of: enum class MyEnum { A = 1 }; struct MyClass { MyEnum Field1 : 3; }; whereas the corresponding unscoped enum case already works. As noticed by Jon, it seems that the below straightforward patchlet is enough to solve the problem but then we have a warning issue: 51242.C:5:19: warning: ‘MyClass::Field1’ is too small to hold all values of ‘enum class MyEnum’ [enabled by default] which is easily explained: the underlying type is fixed (to an implicit int type), thus in finish_enum_value_list, fixed_underlying_type_p is true and the code "restricting" the ENUM_UNDERLYING_TYPE for diagnostic purposes doesn't run. In other terms, we warn for the same reason we for example -Wnarrowing warn (before erroring out) for: enum class Code { SUCCESS = 0 }; Code a; short r[] = {a}; That seems intended, but especially annoying in the bitfield case. An idea could be giving a name to the "too small to hold all values" warning and making possible disabling it. What do you suggest? Thanks! Paolo. Index: decl2.c =================================================================== --- decl2.c (revision 193814) +++ decl2.c (working copy) @@ -1030,7 +1030,7 @@ grokbitfield (const cp_declarator *declarator, if (TREE_CODE (value) == VOID_TYPE) return void_type_node; - if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (value)) + if (!INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (value)) && (POINTER_TYPE_P (value) || !dependent_type_p (TREE_TYPE (value)))) {