From patchwork Tue Mar 27 08:49:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 891425 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-475484-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="kz5do5Sk"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 409PpN12WCz9s1P for ; Tue, 27 Mar 2018 19:49:46 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=UjVQcWg2RZcBhKLOzCio1XKopObRq jfcLDyQDhheU8G2Nx6qCwB9Avj0gESGn3yaKaX97lVgdzHNBidQgUSm2KMYu7mo5 ZPCRcG/qJS78FpfTMosDrr6KR3cRmXBOAZIwUoTWYj+wi/OAAjjBn0YSXdVlTfZT UpAUUxURrHLfeI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=2xGePpXISeql9l55jVydUjeqoAc=; b=kz5 do5Skky+ECOtNRo1s7/nvUkD0KiNjJ18Xp0nu7EC0GIlJnxc4qZOJOxJBTuujzLJ v4SiD/A36lThpohU6wiHrAfN01Sy2qeDeOorNiWaI9XJN+3zkImHtDHLZOyrLaSP /Wz+q5LyynSG2YJiHw46tiPNDJu51rULLDMdGM1U= Received: (qmail 72919 invoked by alias); 27 Mar 2018 08:49:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 72909 invoked by uid 89); 27 Mar 2018 08:49:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=diagnosed, i686-linux, i686linux X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Mar 2018 08:49:36 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2361540201A8; Tue, 27 Mar 2018 08:49:31 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.36.118.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 589D563532; Tue, 27 Mar 2018 08:49:27 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w2R8nO6q014245; Tue, 27 Mar 2018 10:49:25 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w2R8nNib014244; Tue, 27 Mar 2018 10:49:23 +0200 Date: Tue, 27 Mar 2018 10:49:23 +0200 From: Jakub Jelinek To: Nathan Sidwell , Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: [C++ PATCH] Fix invalid covariant return error-recovery (PR c++/85068) Message-ID: <20180327084923.GT8577@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes Hi! As the comment says, in a valid program we wals find thunk_binfo, but if the covariancy is invalid, we've already diagnosed error and we might not find it. We have case to handle thunk_binfo NULL or not finding it in the chain, but on the following testcase base_binfo is NULL and we ICE when we try to access BINFO_TYPE on it. Fixed thusly, furthermore to match the comment I've added an assertion that if we don't find thunk_binfo we've indeed already diagnosed an error. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-03-27 Jakub Jelinek PR c++/85068 * class.c (update_vtable_entry_for_fn): Don't ICE if base_binfo is NULL. Assert if thunk_binfo is NULL then errorcount is non-zero. * g++.dg/inherit/covariant22.C: New test. Jakub --- gcc/cp/class.c.jj 2018-03-21 21:18:31.691351383 +0100 +++ gcc/cp/class.c 2018-03-26 10:48:02.648053297 +0200 @@ -2479,19 +2479,20 @@ update_vtable_entry_for_fn (tree t, tree order. Of course it is lame that we have to repeat the search here anyway -- we should really be caching pieces of the vtable and avoiding this repeated work. */ - tree thunk_binfo, base_binfo; + tree thunk_binfo = NULL_TREE; + tree base_binfo = TYPE_BINFO (base_return); /* Find the base binfo within the overriding function's return type. We will always find a thunk_binfo, except when the covariancy is invalid (which we will have already diagnosed). */ - for (base_binfo = TYPE_BINFO (base_return), - thunk_binfo = TYPE_BINFO (over_return); - thunk_binfo; - thunk_binfo = TREE_CHAIN (thunk_binfo)) - if (SAME_BINFO_TYPE_P (BINFO_TYPE (thunk_binfo), - BINFO_TYPE (base_binfo))) - break; + if (base_binfo) + for (thunk_binfo = TYPE_BINFO (over_return); thunk_binfo; + thunk_binfo = TREE_CHAIN (thunk_binfo)) + if (SAME_BINFO_TYPE_P (BINFO_TYPE (thunk_binfo), + BINFO_TYPE (base_binfo))) + break; + gcc_assert (thunk_binfo || errorcount); /* See if virtual inheritance is involved. */ for (virtual_offset = thunk_binfo; --- gcc/testsuite/g++.dg/inherit/covariant22.C.jj 2018-03-26 10:51:59.580172775 +0200 +++ gcc/testsuite/g++.dg/inherit/covariant22.C 2018-03-26 10:49:21.038092826 +0200 @@ -0,0 +1,19 @@ +// PR c++/85068 +// { dg-do compile } + +struct A; + +struct B +{ + virtual A *foo (); // { dg-error "overriding" } +}; + +struct C : virtual B +{ + virtual C *foo (); // { dg-error "invalid covariant return type for" } +}; + +struct D : C +{ + virtual C *foo (); +};