From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83505 invoked by alias); 20 Jun 2019 07:29:10 -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 83492 invoked by uid 89); 20 Jun 2019 07:29:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Jun 2019 07:29:09 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x5K7T7eL007547; Thu, 20 Jun 2019 02:29:07 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x5K7T6Ax007546; Thu, 20 Jun 2019 02:29:06 -0500 Date: Thu, 20 Jun 2019 07:29:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Florian Rommel , gcc@gcc.gnu.org Subject: Re: Confusion with labels as values Message-ID: <20190620072906.GT7313@gate.crashing.org> References: <40ec56cbc76fc1cc7331d8fc6e70b5f6cab4e847.camel@usrdev.de> <505d7a15-3cbe-a882-57f3-6ad0a4dde3a8@redhat.com> <20190619170917.GO7313@gate.crashing.org> <1c9dbf5a-a0e2-af77-2c06-ae567058b515@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c9dbf5a-a0e2-af77-2c06-ae567058b515@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00204.txt.bz2 On Wed, Jun 19, 2019 at 11:37:52AM -0600, Jeff Law wrote: > On 6/19/19 11:09 AM, Segher Boessenkool wrote: > > On Wed, Jun 19, 2019 at 09:39:01AM -0600, Jeff Law wrote: > >> A label used as a value, but which is not a jump target will have an > >> indeterminate value -- it'll end up somewhere in its containing > >> function, that's all we guarantee in that case. > > > > In gimple it was fine and expected, and expand *did* make a code_label, > > it was just immediately optimised away: > Yea, because it wasn't used as a jump target. That's why it gets turned > into a NOTE_INSN_DELETED_LABEL rather than just deleted. My point was, we could change that. But the more I look at it the worse plan that looks -- it's not as simple as it appears, and for what? :-) Segher