From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98675 invoked by alias); 25 Feb 2015 16:28:29 -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 98586 invoked by uid 89); 25 Feb 2015 16:28:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Feb 2015 16:28:28 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1PGSQAF002929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Feb 2015 11:28:26 -0500 Received: from tucnak.zalov.cz (ovpn-116-28.ams2.redhat.com [10.36.116.28]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1PGSOHc021221 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Feb 2015 11:28:25 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t1PGSNCw007678; Wed, 25 Feb 2015 17:28:23 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t1PGSL6N007677; Wed, 25 Feb 2015 17:28:21 +0100 Date: Wed, 25 Feb 2015 16:51:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: Patch ping Message-ID: <20150225162821.GU1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <5454CAB9.3040907@codesourcery.com> <20150204113817.GO1746@tucnak.redhat.com> <20150216210812.GO1746@tucnak.redhat.com> <5388429A-DE44-4C08-8A19-D42B6E00C0A6@gmail.com> <20150216214349.GR1746@tucnak.redhat.com> <20150218100035.GF1746@tucnak.redhat.com> <20150225070010.GS1746@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg01518.txt.bz2 On Wed, Feb 25, 2015 at 10:10:52AM +0100, Richard Biener wrote: > Oops, totally forgot about this one. > > Shouldn't > > + default: > + error ("unsupported mode %s\n", mname); > > be a fatal_error ()? After all if we hit this but continue we'll Ok, I'll change it. > stream random crap. I also think we should be a bit more user-centric > here and maybe report "for host / offload target combination". Eventually, sure, we should be able (based on options) either turn all the errors from the offloading compiler into warnings that just disable the offloading for some particular offloading target. > +static GTY(()) const unsigned char *lto_mode_identity_table; > > why in GC memory? The reason for that is that it is referenced from GC structure, and in the offloading path they should be GC allocated, so that they can be released when the corresponding GC structure holding pointer to that goes away. In the non-offloading LTO, all those GC structures will contain the same value, lto_mode_identity_table, but if that would be heap allocated, GC would be upset. Jakub