From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47831 invoked by alias); 12 Apr 2019 18:29:24 -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 47571 invoked by uid 89); 12 Apr 2019 18:29:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=*SW*, errorrecovery, parm, ARGUMENT_PACK_P X-HELO: mail-qt1-f182.google.com Received: from mail-qt1-f182.google.com (HELO mail-qt1-f182.google.com) (209.85.160.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Apr 2019 18:29:21 +0000 Received: by mail-qt1-f182.google.com with SMTP id p20so12329151qtc.9 for ; Fri, 12 Apr 2019 11:29:21 -0700 (PDT) Return-Path: Received: from [192.168.1.115] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id t30sm26462298qkj.56.2019.04.12.11.29.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 11:29:18 -0700 (PDT) Subject: Re: [C++ Patch/RFC] PR 89900 ("[9 Regression] ICE: Segmentation fault (in check_instantiated_arg)") To: Paolo Carlini , "gcc-patches@gcc.gnu.org" References: <71f91c87-d690-89d8-4275-798214c86df4@oracle.com> From: Jason Merrill Message-ID: Date: Fri, 12 Apr 2019 18:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <71f91c87-d690-89d8-4275-798214c86df4@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00526.txt.bz2 On 4/11/19 11:20 AM, Paolo Carlini wrote: > Hi, > > over the last few days I spent some time on this regression, which at > first seemed just a minor error-recovery issue, but then I noticed that > very slightly tweeking the original testcase uncovered a pretty serious > ICE on valid: > > template void > fk (XE..., int/*SW*/); > > void > w9 (void) > { >   fk (0); > } > > The regression has to do with the changes committed by Jason for > c++/86932, in particular with the condition in coerce_template_parms: > >    if (template_parameter_pack_p (TREE_VALUE (parm)) >       && (arg || !(complain & tf_partial)) >       && !(arg && ARGUMENT_PACK_P (arg))) > > which has the additional (arg || !complain & tf_partial)) false for the > present testcase, thus the null arg is not changed into an empty pack, > thus later  instantiate_template calls check_instantiated_args which > finds it still null and crashes. Now, likely some additional analysis is > in order, but for sure there is an important difference between the > testcase which came with c++/86932 and the above: non-type vs type > template parameter pack. It seems to me that the kind of problem fixed > in c++/86932 cannot occur with type packs, because it boils down to a > reference to a previous parm (full disclosure: the comments and logic in > fixed_parameter_pack_p helped me a lot here). Thus I had the idea of > simply restricting the scope of the new condition above by adding an || > TREE_CODE (TREE_VALUE (parm)) == TYPE_DECL, which definitely leads to a > clean testsuite and a proper behavior on the new testcases, AFAICS. I'm > attaching what I tested on x86_64-linux. I think the important property here is that it's non-terminal, not that it's a type pack. We can't deduce anything for a non-terminal pack, so we should go ahead and make an empty pack. Jason