From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33589 invoked by alias); 5 Oct 2017 11:04:04 -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 33393 invoked by uid 89); 5 Oct 2017 11:04:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2249 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Oct 2017 11:03:58 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B66DA5AFC8; Thu, 5 Oct 2017 11:03:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B66DA5AFC8 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub@redhat.com Received: from tucnak.zalov.cz (ovpn-116-223.ams2.redhat.com [10.36.116.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5A587600C4; Thu, 5 Oct 2017 11:03:56 +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 v95B3rW1017316; Thu, 5 Oct 2017 13:03:53 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v95B3pc6017315; Thu, 5 Oct 2017 13:03:51 +0200 Date: Thu, 05 Oct 2017 11:04:00 -0000 From: Jakub Jelinek To: Martin =?utf-8?B?TGnFoWth?= Cc: gcc-patches@gcc.gnu.org, Jonathan Wakely Subject: Re: [PATCH][RFC] Instrument function exit with __builtin_unreachable in C++. Message-ID: <20171005110351.GH18588@tucnak> Reply-To: Jakub Jelinek References: <31ddd79e-1152-9dd9-663b-acd8d1bcd4ab@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31ddd79e-1152-9dd9-663b-acd8d1bcd4ab@suse.cz> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00236.txt.bz2 On Thu, Oct 05, 2017 at 12:31:23PM +0200, Martin Liška wrote: > As discussed 2 days ago on IRC with Jakub and Jonathan, C++ standard says that having a non-return > function with missing return statement is undefined behavior. We've got -fsanitize=return check for > that and we can in such case instrument __builtin_unreachable(). This patch does that. It produces quite > some fallout in test-suite. > > And there's still some fallout: > > FAIL: g++.dg/cpp0x/constexpr-diag3.C -std=c++11 (test for errors, line 7) > FAIL: g++.dg/cpp0x/constexpr-neg3.C -std=c++11 (test for errors, line 12) > FAIL: g++.dg/cpp1y/constexpr-return2.C -std=c++14 (test for errors, line 7) > FAIL: g++.dg/cpp1y/constexpr-return2.C -std=c++14 (test for excess errors) > FAIL: g++.dg/cpp1y/pr63996.C -std=c++14 (test for errors, line 9) > FAIL: g++.dg/cpp1y/pr63996.C -std=c++14 (test for excess errors) > > 1) there are causing: > > ./xg++ -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/pr63996.C > /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/pr63996.C:9:23: in constexpr expansion of ‘foo(1)’ > /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/pr63996.C:4:1: error: ‘__builtin_unreachable()’ is not a constant expression > foo (int i) > ^~~ > > Where we probably should not emit the built-in call. Am I right? The problem is that I think we save the constexpr function bodies after folding and genericization. We shouldn't be doing that, if we save it before, in addition to fixing quite a few bugs it would fix this as well. If looking for a hack instead of proper fix here, allowing __builtin_unreachable () in constant expressions would be probably undesirable, because then people adding it themselves in their source code would get it accepted. So, either we need some way how to differentiate between user written __builtin_unreachable and one we've added ourselves (doesn't -fsanitize=return fail the similar way though?), either as internal-fn instead, or just by using UNKNOWN_LOCATION or BUILTINS_LOCATION or something similar to find out it is artificial; and of course if we reach it during constexpr evaluation error some way. Jakub