From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 725 invoked by alias); 22 Oct 2014 07:57: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 713 invoked by uid 89); 22 Oct 2014 07:57:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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, 22 Oct 2014 07:57:27 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9M7vOb1015882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 03:57:24 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9M7vLhZ030373 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Oct 2014 03:57:23 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9M7vJhV014490; Wed, 22 Oct 2014 09:57:20 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9M7vHvP014489; Wed, 22 Oct 2014 09:57:17 +0200 Date: Wed, 22 Oct 2014 07:59:00 -0000 From: Jakub Jelinek To: Ilya Verbin Cc: "Joseph S. Myers" , gcc , Kirill Yukhin , Andrey Turetskiy Subject: Re: [PATCH 1/4] Add mkoffload for Intel MIC Message-ID: <20141022075717.GF10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20141021171323.GA47586@msticlxl57.ims.intel.com> <20141021171602.GB47586@msticlxl57.ims.intel.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: 2014-10/txt/msg02206.txt.bz2 On Wed, Oct 22, 2014 at 02:30:44AM +0400, Ilya Verbin wrote: > > I don't see anything restricting this program to being built for GNU > > *hosts*. Thus, it needs to be portable (to different hosts; obviously > > it's target-architecture-specific) rather than relying on glibc > > interfaces. (Providing appropriate functions in libiberty is of course an > > option; thus, freely using obstacks is fine because they're in libiberty.) > > This mkoffload is expected to be built only with the offload compiler, > which is expected to be configured with > '--enable-as-accelerator-for=... --host=x86_64-*-linux-gnu > --target=x86_64-*-linux-gnu'. > Without $enable_as_accelerator it wouldn't be built. I will add more > restrictions to config.gcc. But why the --host=x86_64-*-linux-gnu restriction? mkoffload looks to me like a typical host tool, but I don't understand why it would require native compilation, it is a tool that arranges that the offloading target compiler is invoked, and results linked back, but it doesn't need to execute anything on the target, you don't need access to the acceleration device for that and I don't see any reason why it couldn't be run on s390-linux, or say mingw. Both the primary compiler and offloading target compilers obviously have to be configured for the same (or similar?) host, the target (for what they generate code for) is given for both too (unless we start supporting say powerpc64-linux primary compiler offloading to Intel MIC etc.) and build irrelevant (e.g. you could build offloading compiler using canadian cross with --enable-as-accelerator-for=x86_64-pc-linux --build=aarch64-linux \ --host=s390-linux --target=x86_64-intelmicemul-linux and primary compiler with --enable-offload-targets=x86_64-intelmicemul-linux-gnu=/some/path/ \ --build=armv7tel-linux-gnueabi --host=s390-linux --target=x86_64-pc-linux ). Or do you see any substantial reasons why this can't work? > >> + nextval = strchrnul (curval, ':'); > > > > I don't think strchrnul is portable (unless added to libiberty). > > It seems that there is no need to make this mkoffload so portable. I disagree, see above. I think this isn't so performance critical code that you can't just use portable: nextval = strchr (curval, ':'); if (nextval == NULL) nextval = strchr (curval, '\0'); Jakub