From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5609D3858D20 for ; Tue, 15 Mar 2022 15:57:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5609D3858D20 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-648-BnH-hgjRO7Wwaif3js1Vng-1; Tue, 15 Mar 2022 11:57:24 -0400 X-MC-Unique: BnH-hgjRO7Wwaif3js1Vng-1 Received: by mail-qv1-f69.google.com with SMTP id bh20-20020ad44914000000b00440be590fa7so3025277qvb.8 for ; Tue, 15 Mar 2022 08:57:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=tRc7uY6q/sQ2XKn59Gb7AJqmnU2xRuHFLtJxN54k1s0=; b=eQmVmrwl6x5lXj24BVNo5SM6+Wtk32uwQ6QFcsmF/QljCZiAgAYf5H9NzFOp49AK5L cyOaPDbMsYFmRfqt3Mkr9GrQhuBpCIAURhe9JdmvODsASbe0kupegoQoI5Ln4o7LeW/B bacMqK/9Mfrer7JNKAzK6uy4saH72tdH7h5cGba5uLceFHxYYcP/XcJy3YEKawOe9lJl CeYhogYeCGcAATIkARRkGBVaSND/E9gr0R6guAzVhiY4P8cmhuv0Jay2Kb/hYbZSLWIX ldRxD960k2nDsXbWqQCbfUdrbu1J7X2fnIbsa8ej6G+UKaNGHaTb3x8mAqdsOhKE/2iW 17FA== X-Gm-Message-State: AOAM5327EPUVmgRAcCXiArt9TkW08luGMyu2WzM3s8LVUVhNCp3erMxd /qcvgKMaFquTSlTbvD4Qz+LNZZSphz4QUzfMAVxz47o3UQ2s0Q1Fftgj+H8mLsK2BVAdiDLFybB evmgDMgIL8YYisHZbuA== X-Received: by 2002:a05:620a:f:b0:60d:ed9c:6203 with SMTP id j15-20020a05620a000f00b0060ded9c6203mr17825602qki.172.1647359844334; Tue, 15 Mar 2022 08:57:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyew79viPHpHzAEK+IHqLKhy5h7SMONnYrEq14LoW/SOBSIweu5Q+ZHpiuOeV3SONBOpRHefw== X-Received: by 2002:a05:620a:f:b0:60d:ed9c:6203 with SMTP id j15-20020a05620a000f00b0060ded9c6203mr17825589qki.172.1647359843960; Tue, 15 Mar 2022 08:57:23 -0700 (PDT) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id t19-20020ac85893000000b002e1afa26591sm11648315qta.52.2022.03.15.08.57.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Mar 2022 08:57:23 -0700 (PDT) Message-ID: <8fb4f228-16c7-9f3b-412c-bcea1a2020e7@redhat.com> Date: Tue, 15 Mar 2022 11:57:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) To: Jakub Jelinek Cc: Qing Zhao , gcc-patches Paul A Clarke via References: <946D3718-32CD-45B6-8EF5-C41DDC3CA06E@oracle.com> <87823a36-93f3-5541-dc76-5a8c32e51c03@redhat.com> <319ad931-a975-e29c-7b8a-51534d657e01@redhat.com> <9B1729F5-964A-4A12-93B3-148BFE4D96F5@oracle.com> <01B0A297-CC89-4666-9684-BE04BE17E66E@oracle.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2022 15:57:27 -0000 On 3/15/22 08:32, Jakub Jelinek wrote: > On Fri, Feb 11, 2022 at 12:27:49PM -0500, Jason Merrill wrote: >> Yes, that's what the above code would correctly do if TYPE were the >> pointer-to-method type. It's wrong for this case because TYPE is unrelated >> to TREE_TYPE (field). >> >> I think the problem is just this line: >> >>> if (tree ret = c_fold_indirect_ref_for_warn (loc, type, cop, >>> off)) >>> return ret; >>> return cop; >> ^^^^^^^^^^ >> >> The recursive call does the proper type checking, but then the "return cop" >> line returns the COMPONENT_REF even though the type check failed. The >> parallel code in cxx_fold_indirect_ref_1 doesn't have this line, and >> removing it fixes the testcase, so I see >> >> warning: ‘*(ptrmemfunc*)&x.ptrmemfunc::ptr’ is used uninitialized > > The intent of r11-6729 is that it prints something that helps user to figure > out what exactly is being accessed. > When we find a unique non-static data member that is being accessed, even > when we can't fold it nicely, IMNSHO it is better to print > ((sometype *)&var)->field > or > (*(sometype *)&var).field > instead of > *(fieldtype *)((char *)&var + 56) > because the user doesn't know what is at offset 56, we shouldn't ask user > to decipher structure layout etc. The problem is that the reference is *not* to any non-static data member, it's to the PMF as a whole. But c_fold_indirect_ref_for_warn wrongly turns it into a reference to the first non-static data member. We asked c_fold_indirect_ref_warn to fold a MEM_REF with RECORD_TYPE, and it gave us back a COMPONENT_REF with POINTER_TYPE. That seems clearly wrong. > One question is if we could return something better for the TYPE_PTRMEMFUNC_FLAG > RECORD_TYPE members here (something that would print it more naturally/readably > in a C++ way), though the fact that the routine is in c-family makes it > harder. > > Another one is whether we shouldn't punt for FIELD_DECLs that don't have > nicely printable name of its containing scope, something like: > if (tree scope = get_containing_scope (field)) > if (TYPE_P (scope) && TYPE_NAME (scope) == NULL_TREE) > break; > return cop; > or so. > Note the returned cop is a COMPONENT_REF where the first argument has a > nicely printable type name (x with type sp), but sp's TYPE_MAIN_VARIANT > is the unnamed TYPE_PTRMEMFUNC_FLAG. So another possibility would be if > we see such a problem for the FIELD_DECL's scope, check if TYPE_MAIN_VARIANT > of the first COMPONENT_REF's argument is equal to that scope and in that > case use TREE_TYPE of the first COMPONENT_REF's argument as the scope > instead. > > Jakub >