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 C639F3858400 for ; Mon, 5 Sep 2022 16:10:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C639F3858400 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662394228; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=H5a0SSuniiFulaL7dXMwsosry6BZM67193PqwWdINXw=; b=Rm3E+RVjIR1cSNUtZgQEO9LUtq/19APlkTCdrX9W24NyBAcaKHcb+I1sMMLu/THffX7j1t Snr0jLtjKwffu1azMzBPrTVBJlQKbm+6kARCQi47h15Ho0iRmpYJIbgtlvzzI1y9Gq6Nem Yrw5Vzx2UbFPllQjEkyTYITdZJKJrHE= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-26-9dOUrdGBNw2baGwMiESf9w-1; Mon, 05 Sep 2022 12:10:27 -0400 X-MC-Unique: 9dOUrdGBNw2baGwMiESf9w-1 Received: by mail-qv1-f71.google.com with SMTP id ll5-20020a056214598500b0049905d71166so6125802qvb.14 for ; Mon, 05 Sep 2022 09:10:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:organization:subject:to :from:x-gm-message-state:from:to:cc:subject:date; bh=H5a0SSuniiFulaL7dXMwsosry6BZM67193PqwWdINXw=; b=Z1gQoBhXWDYg1U2xGFkB7tYDcuK+v2Pvu1Ge48MjLdhQlzUbV5JhgN1HonrBKtNbh9 fXKcux44JmfxaVEtNTHJc96TE0ZnELPZZz8zYhdVWEq2wDCO39LpqQlPrrqus3+tAjmE 6mmwsUdGXLlvZ13HtsJr9gF807Zh2U1/6c+MBMwtW1W+gNegyybscdPMbLmKxtsTOKfs IJKjUN/bOh5ZmOqiT+918P8gNS5E0Rz7bHK51Mlql3NKFbAcs4jvR+FKC6Pzn8fVLLhj 2g+d7ZRu8kBIxed8QbGT8xm1WDTd7Mp0uMxJ7/QrBINgzZi/yWwui4lD7k5Q1u76FkO3 uFkQ== X-Gm-Message-State: ACgBeo1E6YyHvSSKW7Bt+5OVbVP7/t8JjVivNOgEXPpqBZCuR2X+E9uG 5buroEXmfEbV0cDw9DYDb0Mu9ZvGRWfI4EPlB4FL4ayZSRvP6z8NtJKrG/06RW8vZF+Otju2Mlk i90LaIihE4o94UOL0ERizFxdIsLWHxGJwF+a1Z11pu51aO4RhE4I/GUJxVab7Lwo4PF1o X-Received: by 2002:a05:6214:c44:b0:499:d5c:2975 with SMTP id r4-20020a0562140c4400b004990d5c2975mr30257560qvj.73.1662394226855; Mon, 05 Sep 2022 09:10:26 -0700 (PDT) X-Google-Smtp-Source: AA6agR4S8M+MKADiZF5IZJGCahVFfhvof5yhnIH7Uqw6f76VKS0baTKdRUawqLd7R8eZdA0oSkSpZA== X-Received: by 2002:a05:6214:c44:b0:499:d5c:2975 with SMTP id r4-20020a0562140c4400b004990d5c2975mr30257545qvj.73.1662394226613; Mon, 05 Sep 2022 09:10:26 -0700 (PDT) Received: from localhost ([88.120.130.27]) by smtp.gmail.com with ESMTPSA id m23-20020ac86897000000b0034355bb11f2sm7204327qtq.10.2022.09.05.09.10.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Sep 2022 09:10:26 -0700 (PDT) Received: by localhost (Postfix, from userid 1000) id C5356581C2F; Mon, 5 Sep 2022 18:10:23 +0200 (CEST) From: Dodji Seketeli To: libabigail@sourceware.org Subject: [PATCH, applied] ir: Don't overdo canonical type propagation control when comparing classes Organization: Red Hat / France X-Operating-System: Fedora 38 X-URL: http://www.redhat.com Date: Mon, 05 Sep 2022 18:10:23 +0200 Message-ID: <87ilm1kdjk.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, While looking at something else, I stumbled upon this problem. When comparing a class, equals first calls the overload for class_or_union to compare data members. If we are in the process of type canonicalization, the right hand side operand might be "canonical-type-propagated", during that call to the overload. In other words, it can inherit the canonical type of the left-hand-side operand. The problem is that that canonical type propagation, if it happens, is too early because this equals function still needs to compare other things like virtual member functions etc. So, the original intend of the code was to erase the canonical type that might have been propagated. This is all and well. The problem however is that the code /always/ erases the canonical type of the right hand side operand, even if it was the result of the propagation optimization long before it entered this equals function. Oops. This patch fixes that issue. * src/abg-ir.cc (equals): In the overload for const class_decl&, do not cancel the propagated canonical type if the propagation is not the result of invoking the equals overload for class_or_union. Signed-off-by: Dodji Seketeli Applied to master. --- src/abg-ir.cc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/abg-ir.cc b/src/abg-ir.cc index a2eb8a02..7c8b6640 100644 --- a/src/abg-ir.cc +++ b/src/abg-ir.cc @@ -23587,6 +23587,7 @@ equals(const class_decl& l, const class_decl& r, change_kind* k) RETURN_TRUE_IF_COMPARISON_CYCLE_DETECTED(static_cast(l), static_cast(r)); + bool had_canonical_type = !!r.get_naked_canonical_type(); bool result = true; if (!equals(static_cast(l), static_cast(r), @@ -23609,7 +23610,8 @@ equals(const class_decl& l, const class_decl& r, change_kind* k) // canonical type propagation, then cancel that because it's too // early to do that at this point. We still need to compare bases // virtual members. - maybe_cancel_propagated_canonical_type(r); + if (!had_canonical_type) + maybe_cancel_propagated_canonical_type(r); // Compare bases. if (l.get_base_specifiers().size() != r.get_base_specifiers().size()) -- 2.37.2 -- Dodji