From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31174 invoked by alias); 24 Jul 2014 22:35:59 -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 31161 invoked by uid 89); 24 Jul 2014 22:35:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f50.google.com Received: from mail-qa0-f50.google.com (HELO mail-qa0-f50.google.com) (209.85.216.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 24 Jul 2014 22:35:56 +0000 Received: by mail-qa0-f50.google.com with SMTP id s7so3675647qap.23 for ; Thu, 24 Jul 2014 15:35:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LawRUGDXujzeC7PsHLHJ2e4xaf6ztRrlmA7M7qriqUA=; b=C5olrztzIe/fHaQzAkTFJwjKRelPFMPhyB/Y9oN983sIotqDLCQuQ6PFxaN61uxGlE FDZNFTOUhkvwhK56XAFms13xusmZi2GwhQfY4EHFmBzVh37hyUWXusYnX+zYoHuOfuns mGxPHCcSKW4bQA7ODb68RivTwMrDAhLnTVTNeVkm9aTq3v71tX5Vp8yGWzEbkJhn0UdK hCB3QSRiMG9ZK6wYGn/kbnRT8K+QJ12njG9uKV1+LRS0EgDfUFSOAtxfaF7HJ9blBgLG 2Nf7AwXPDHUbBgGCzjXmO2x5SpAUWwnrfWhtOH38HC91aEXUjxtQfbvCGQzyYkZV0pF8 Qhgg== X-Gm-Message-State: ALoCoQnw+h5X18DdXZcqSPoE7YZ8oaxAYgwLesI2BMogcYLvlathlYIp1OwNliHwe8JqgGga0hHK MIME-Version: 1.0 X-Received: by 10.224.69.202 with SMTP id a10mr20625080qaj.100.1406241354372; Thu, 24 Jul 2014 15:35:54 -0700 (PDT) Received: by 10.140.85.113 with HTTP; Thu, 24 Jul 2014 15:35:54 -0700 (PDT) In-Reply-To: <538C7F4F.4050800@redhat.com> References: <1401191856-27585-1-git-send-email-palves@redhat.com> <1401191856-27585-3-git-send-email-palves@redhat.com> <538C7F4F.4050800@redhat.com> Date: Thu, 24 Jul 2014 22:44:00 -0000 Message-ID: Subject: Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters From: Cary Coutant To: Jason Merrill Cc: Pedro Alves , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg01699.txt.bz2 > It seems that the problem here is more general; a template argument list is > not in scope within that same template argument list. Can't we fix that > without special-casing conversion ops? I think conversion ops really are a special case. It's the only case where the template parameters refer to the template argument list from the cast operator's enclosing template. In a cast expression, like anywhere else you might have a template parameter, the template parameter refers to the template argument list of the immediately enclosing template. I think this note from Section 5.1.3 (Operator Encodings) of the ABI is what makes this a special case (it's an informative comment in the document, but seems to me to be normative): "For a user-defined conversion operator the result type (i.e., the type to which the operator converts) is part of the mangled name of the function. If the conversion operator is a member template, the result type will appear before the template parameters. There may be forward references in the result type to the template parameters." -cary