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.129.124]) by sourceware.org (Postfix) with ESMTPS id D3DC03888C4E for ; Sat, 19 Mar 2022 05:32:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3DC03888C4E Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-647-qon0Ll6tOjCXJNZhg1Lvrw-1; Sat, 19 Mar 2022 01:32:28 -0400 X-MC-Unique: qon0Ll6tOjCXJNZhg1Lvrw-1 Received: by mail-qv1-f72.google.com with SMTP id ba7-20020ad45527000000b0044105fb3d5fso1802156qvb.8 for ; Fri, 18 Mar 2022 22:32:28 -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=yWTDSi+yeHKuEeplamGPBcXug6guvNJibv/zrfLkqVc=; b=W07Rmg2WfvaLw6R1MAc4iwzZYxtUwakJIbpJcPzxPCShOXwCH3Cri5lx4MeIYnlWxC y7g7gr2kVTjxEM2Snmv84Z45YUs6MVsAptB0XDJBZdv4ulRee+a7/Qc/3uGWVH9vWW6T Wk26oFz8/2Hk8rennvuFjprf5YNXNPi7DynG4yv4HjWdNrZ1PWho8VFaCD5c6OEbuBGh oWHAHkTZNOZYXe5CvEnzbjCiU4WMRQ5KQQq8k3S7HTPaaJzN39ehSN3o398UK/UNdgTF c7c82mVsrFgGpCRFFzGwkHJh+b4jOK3hUbflgMhGJ9ZcOoDYJy4C+XoNZqZj8Omwa727 ULFw== X-Gm-Message-State: AOAM532Uu56XRInCzPD2040lftTjUf2F8e4+zA/ksu1ExhRzHKo2nteQ wkgsnRr8pj1OgPvmtNfeQRVEsQaINkYjgt0gjSBjT3yb8WPgErJOB7WWhhnTRBxestIQvOtxgPR RXzuKqvxRrK/noynL7w== X-Received: by 2002:a05:620a:2547:b0:67d:e21f:b512 with SMTP id s7-20020a05620a254700b0067de21fb512mr7837881qko.707.1647667947923; Fri, 18 Mar 2022 22:32:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCzshJlznH8nSdN+Q22qO/HZGndLk2Cdu5KarZaAdagIwWtRUp9SBhi2BFRfW+zC9+t5BZPw== X-Received: by 2002:a05:620a:2547:b0:67d:e21f:b512 with SMTP id s7-20020a05620a254700b0067de21fb512mr7837876qko.707.1647667947627; Fri, 18 Mar 2022 22:32:27 -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 o4-20020a05620a22c400b0067e02a697e0sm4994265qki.33.2022.03.18.22.32.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 22:32:26 -0700 (PDT) Message-ID: <8a44bb7b-c296-dec3-bc47-33387c8382e4@redhat.com> Date: Sat, 19 Mar 2022 01:32:25 -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: <319ad931-a975-e29c-7b8a-51534d657e01@redhat.com> <9B1729F5-964A-4A12-93B3-148BFE4D96F5@oracle.com> <01B0A297-CC89-4666-9684-BE04BE17E66E@oracle.com> <8fb4f228-16c7-9f3b-412c-bcea1a2020e7@redhat.com> <907b5cc5-8f80-11f7-8a2b-c2daffd6d6b1@redhat.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: 7bit X-Spam-Status: No, score=-7.2 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_H4, 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: Sat, 19 Mar 2022 05:32:32 -0000 On 3/18/22 14:47, Jakub Jelinek wrote: > On Fri, Mar 18, 2022 at 02:27:30PM -0400, Jason Merrill wrote: >>> That is also correct C++ expression, but user probably has no idea what is >>> present at offset 32 into the variable. >>> Of course if there is a type match and not any kind of type punning, >>> it will try to print much shorter and more readable expressions. >> >> One important point about the OP's testcase is that we're dealing with >> offset 0, which corresponds to both the PMF as a whole and its first >> element. Since we're looking for a RECORD_TYPE, choosing to interpret the >> desired object as the (RECORD_TYPE) PMF as a whole seems like the better >> choice; being more flexible probably does make sense at non-0 offsets. > > Even if we punt for 0 offsets in RECORD_TYPEs, we'd still run into > the ICE if we tried to access something overlapping the __delta member. Good point. Your patch is OK, then. > For 0 offsets and type puning, the question is what will help user more, > it is true we don't need to print those + offsetof(...) parts because it > is the start of it, on the other side the user might not know what is the > first member of the struct and printing that might sometimes help. Or it might not, as in this case. Going with the enclosing class if none of the types match seems like a better default to me, but I guess let's not worry about it now. Jason