From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33662 invoked by alias); 27 Jan 2019 00:25:02 -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 33653 invoked by uid 89); 27 Jan 2019 00:25:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=HX-HELO:sk:mail-oi X-HELO: mail-oi1-f179.google.com Received: from mail-oi1-f179.google.com (HELO mail-oi1-f179.google.com) (209.85.167.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Jan 2019 00:25:01 +0000 Received: by mail-oi1-f179.google.com with SMTP id u18so10380235oie.10 for ; Sat, 26 Jan 2019 16:25:01 -0800 (PST) MIME-Version: 1.0 References: <20190124191614.GG26714@redhat.com> <20190125170957.GL26714@redhat.com> <8fb80442-9bbc-38fa-5b87-3aa940284fad@redhat.com> <20190125232227.GQ26714@redhat.com> In-Reply-To: <20190125232227.GQ26714@redhat.com> From: Jason Merrill Date: Sun, 27 Jan 2019 04:22:00 -0000 Message-ID: Subject: Re: C++ PATCH for c++/89024 - ICE with incomplete enum type To: Marek Polacek Cc: Tim Song , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01560.txt.bz2 On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek wrote: > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > > On 1/25/19 12:09 PM, Marek Polacek wrote: > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote: > > > > > > > > > > On 1/24/19 2:16 PM, Marek Polacek wrote: > > > > > > This test ICEs since r159006 which added > > > > > > > > > > > > type = ENUM_UNDERLYING_TYPE (type); > > > > > > > > > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we > > > > > > haven't yet parsed '}' of the enum and the underlying type isn't fixed, and > > > > > > so checking TYPE_UNSIGNED crashed. > > > > > > > > > > > > I've added some checks to the test to see if the types seem to be OK; clang++ > > > > > > agrees. > > > > > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7? > > > > > > > > > > > > 2019-01-24 Marek Polacek > > > > > > > > > > > > PR c++/89024 - ICE with incomplete enum type. > > > > > > * cvt.c (type_promotes_to): Check if prom is non-null. > > > > > > > > > > 9.6/6: An enumeration whose underlying type is not fixed is an > > > > > incomplete type from its point of declaration to immediately after the > > > > > closing } of its enum-specifier, at which point it becomes a complete type. > > > > > > > > > > So the conversion is ill-formed. > > > > > > > > > > Jason > > > > > > > > But the conversion in the example (in > > > > decltype(__test_aux<_To1>(declval<_From1>()))) > > > > is in a SFINAE context, so shouldn't it gracefully fall back to the > > > > `(...)` overload? > > > > > > I think so, and clang++ and icc also compile the testcase fine (and we used to > > > too, before r159006). > > > > Absolutely, the conversion being ill-formed means substitution fails, and we > > reject that candidate. I meant that we shouldn't get as far as > > type_promotes_to for an incomplete type. > > Makes sense. So here's another attempt: > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2019-01-25 Marek Polacek > > PR c++/89024 - ICE with incomplete enum type. > * call.c (standard_conversion): When converting an > ARITHMETIC_TYPE_P to an incomplete type, return NULL. OK. Jason