From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104801 invoked by alias); 5 Dec 2019 12:08:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 104792 invoked by uid 89); 5 Dec 2019 12:08:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=Greetings, H*i:sk:39c7716, H*f:sk:39c7716, H*MI:sk:39c7716 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Dec 2019 12:08:54 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A5D66AB87; Thu, 5 Dec 2019 12:08:51 +0000 (UTC) Subject: Re: Possible Bugs in cgraphunit.c To: Nicholas Krause , gcc Mailing List References: <39c77161-074b-c424-af0a-a17351658622@gmail.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Thu, 05 Dec 2019 12:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <39c77161-074b-c424-af0a-a17351658622@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00059.txt.bz2 On 12/5/19 9:00 AM, Nicholas Krause wrote: > Greetings, > Seems that the extend_trucks return values are not returned when called in both, > cnode::assemble_thunks_and_aliases and cnode::create_wrapper. I'm not sure > if this is a set of edge case bugs or there was a reason for this. Seems not as its > checked in the third function caller in the file, cgraph_node::analyze. Hello. You are right that the return value of expand_thunk is not checked (except one place). The code is quite old, so I guess it's not causing issues. Martin > > Not sure if my assumptions are correct so I'm asking if there isn't another reason > for this as the code seems to have at least directly no reason for it, > > Nick