From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26376 invoked by alias); 1 Dec 2016 12:43:30 -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 26363 invoked by uid 89); 1 Dec 2016 12:43:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=parms, sk:pratham, U*prathamesh.kulkarni, prathameshkulkarnilinaroorg X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Dec 2016 12:43:19 +0000 Received: by mail-wm0-f50.google.com with SMTP id t79so246402226wmt.0 for ; Thu, 01 Dec 2016 04:43:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j8Ca4cwMybEMLWkGLA2DBMA+cxo5KeOS1Am/NTpTWEo=; b=aG7nRTKrpxvnk4ktjXxgOBLnRgGocLERJx0TolmgCkOhcFctQj4B4n7fjO4DHT7yzv gDIVxAr5GS5xUf2pC1FT4SGxe18I/p4XL4ImGq/t9yMbpvC7SKEUU4LQCPTfycScIB1N O0X2fMJntCEnmRu8/B5QsgV5KyXjZNfh+uuyq9QyxIo0rJ07QBTrlYY2nCCYnhywbFgE 2w2/In9wtDVx1Jd1XmrcwYhMnyoGPMxR3Z1tOKxJqRFw4h1j6dWFFY9m2GWXqV8RR/gz LMa2uwCvyTK0lMKOG4IIzv2mvp/JhgnDOUI+zLBeapLlYotlX+KdTdk02pkB1qf67poL n96g== X-Gm-Message-State: AKaTC01PpvblyoRckrr2d54eEhkODUnOoYiQ1GOSwqTvi3PUwj0U5hOYOR1PUgUybClOk/eJCZO6q/W7DuHclg== X-Received: by 10.28.93.74 with SMTP id r71mr31734848wmb.67.1480596197260; Thu, 01 Dec 2016 04:43:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.137.2 with HTTP; Thu, 1 Dec 2016 04:43:16 -0800 (PST) In-Reply-To: References: From: Richard Biener Date: Thu, 01 Dec 2016 12:43:00 -0000 Message-ID: Subject: Re: PR78599 To: Prathamesh Kulkarni Cc: gcc Patches , Jan Hubicka , Martin Jambor Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00062.txt.bz2 On Thu, Dec 1, 2016 at 11:07 AM, Prathamesh Kulkarni wrote: > Hi, > As mentioned in PR, the issue seems to be that in > propagate_bits_accross_jump_functions(), > ipa_get_type() returns record_type during WPA and hence we pass > invalid precision to > ipcp_bits_lattice::meet_with (value, mask, precision) which eventually > leads to runtime error. > The attached patch tries to fix that, by bailing out if type of param > is not integral or pointer type. > This happens for the edge from deque_test -> _Z4copyIPd1BEvT_S2_T0_.isra.0/9. Feels more like a DECL_BY_REFERENCE mishandling and should be fixed elsewhere. > However I am not sure how ipcp_bits_lattice::meet_with (value, mask, > precision) gets called for this case. In > ipa_compute_jump_functions_for_edge(), we set jfunc->bits.known to > true only > if parm's type satisfies INTEGRAL_TYPE_P or POINTER_TYPE_P. > And ipcp_bits_lattice::meet_with (value, mask, precision) is called > only if jfunc->bits.known > is set to true. So I suppose it shouldn't really happen that > ipcp_bits_lattice::meet_with(value, mask, precision) gets called when > callee parameter's type is record_type, since the corresponding > argument's type would also need to be record_type and > jfunc->bits.known would be set to false. > > Without -flto, parm_type is reference_type so that satisfies POINTER_TYPE_P, > but with -flto it's appearing to be record_type. Is this possibly the > same issue of TYPE_ARG_TYPES returning bogus types during WPA ? > > I verified the attached patch fixes the runtime error with ubsan-built gcc. > Bootstrap+tested on x86_64-unknown-linux-gnu. > Cross-tested on arm*-*-*, aarch64*-*-*. > LTO bootstrap on x86_64-unknown-linux-gnu in progress. > Is it OK to commit if it succeeds ? > > Thanks, > Prathamesh