From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22206 invoked by alias); 13 Aug 2016 00:23:58 -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 22194 invoked by uid 89); 13 Aug 2016 00:23:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Writing, UD:dir.go, UD:match.sh, dirgo X-HELO: mail-io0-f177.google.com Received: from mail-io0-f177.google.com (HELO mail-io0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 13 Aug 2016 00:23:47 +0000 Received: by mail-io0-f177.google.com with SMTP id q83so38808098iod.1 for ; Fri, 12 Aug 2016 17:23:47 -0700 (PDT) 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:content-transfer-encoding; bh=VxWd1ZpN3Zbu5N380kLffPV99c1qYiTsiurjUHJ/JFo=; b=Eb0dqmGtldo3YX33OYDb3BFCDzjbD9yqOCGQg/Zc1LcQR5gNe8rnrAbxUKJ0QCE418 fedLy7rAHvuFs6k10igXbTlzrgNTLoM15C4l4KE9Gb4LHMux2oe8lWb0gxzPzapcPFEP UzhlgCkB7vfsmPu3kNFqZ7xlpfDAzLJoGlfeaomBxKyS7NK05i8EyQKHMa83jid8iKrP bbiwifbdtL40XPW9ycdbqLTMXQndedmYSIHSUC2Q/rLPDDhNUZNX7AOsM/MWbHxhHIXo 4jnJXLywOT256OUVqwpCC11PX7AiEVn0fzR4rw8Xly0tsay+U4beruDurMt/pIaqFIGw 95cg== X-Gm-Message-State: AEkoousezRaBhngyhNqFdq12Os4KAT/5+RRgu7nxmDKdeODdm6R+Nsc0PkV9l5JKwFx4AiHBNLNvuwDDw4tkLQ== X-Received: by 10.107.181.13 with SMTP id e13mr23910702iof.88.1471047825549; Fri, 12 Aug 2016 17:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.199 with HTTP; Fri, 12 Aug 2016 17:23:45 -0700 (PDT) In-Reply-To: <6e128c9e-8f4d-8222-f3cc-2425b88275e3@linux.vnet.ibm.com> References: <6e128c9e-8f4d-8222-f3cc-2425b88275e3@linux.vnet.ibm.com> From: Ian Lance Taylor Date: Sat, 13 Aug 2016 00:23:00 -0000 Message-ID: Subject: Re: libgo patch committed: Change build procedure to use build tags To: Andreas Krebbel Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-08/txt/msg01064.txt.bz2 On Fri, Aug 12, 2016 at 4:19 AM, Andreas Krebbel wrote: > On 08/06/2016 02:36 AM, Ian Lance Taylor wrote: >> Go packages use build tags (see the section on Build Constraints at >> https://golang.org/pkg/go/build/) to select which files to build on >> specific systems. >> >> Previously the libgo Makefile explicitly listed the set of files to >> compile for each package. For packages that use build tags, this >> required a lot of awkward automake conditionals in the Makefile. >> >> This patch changes the build to look at the build tags in the files. >> The new shell script libgo/match.sh does the matching. This required >> adjusting a lot of build tags, and removing some files that are never >> used. I verified that the exact same sets of files are compiled on >> x86_64-pc-linux-gnu. I also tested the build on i386-sun-solaris >> (building for both 32-bit and 64-bit). >> >> Writing match.sh revealed some bugs in the build tag handling that >> already exists, in a slightly different form, in the gotest shell >> script. This patch fixes those problems as well. >> >> The old code used automake conditionals to handle systems that were >> missing strerror_r and wait4. Rather than deal with those in Go, >> those functions are now implemented in runtime/go-nosys.c when >> necessary, so the Go code can simply assume that they exist. >> >> The os testsuite looked for dir_unix.go, which was never built for >> gccgo and has now been removed. I changed the testsuite to look for >> dir.go instead. >> >> Note that if you have an existing build directory, you will have to >> remove all the .dep files in TARGET/libgo after updating to this >> patch. There isn't anything that will force them to update >> automatically. >> >> Bootstrapped on x86_64-pc-linux-gnu and i386-sun-solaris. Ran Go >> testsuite on x86_64-pc-linux-gnu. Committed to mainline. >> >> Ian > > This appears to break libgo build on s390x: > > libtool: compile: /home3/andreas/clean/gcc-7.0.0-64-clean-build/./gcc/gc= cgo > -B/home3/andreas/clean/gcc-7.0.0-64-clean-build/./gcc/ > -B/home3/andreas/clean/gcc-7.0.0-64-clean-install/s390x-ibm-linux-gnu/bin= / -B/h > ome3/andreas/clean/gcc-7.0.0-64-clean-install/s390x-ibm-linux-gnu/lib/ -i= system > /home3/andreas/clean/gcc-7.0.0-64-clean-install/s390x-ibm-linux-gnu/inclu= de -isystem > /home3/andreas/clean/gcc-7.0.0-64-clean-instal > l/s390x-ibm-linux-gnu/sys-include -O2 -g -I . -c -fgo-pkgpath=3Dhash/crc32 > /home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32.go > /home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_generic.go /home3/a= ndreas/c > lean/../gcc/libgo/go/hash/crc32/crc32_s390x.go -fPIC -o hash/.libs/crc32= .o > /home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_s390x.go:56:1: erro= r: redefinition of > =E2=80=98updateCastagnoli=E2=80=99 > func updateCastagnoli(crc uint32, p []byte) uint32 { > ^ > /home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_generic.go:12:1: no= te: previous definition of > =E2=80=98updateCastagnoli=E2=80=99 was here > func updateCastagnoli(crc uint32, p []byte) uint32 { > ^ > /home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_s390x.go:81:1: erro= r: redefinition of =E2=80=98updateIEEE=E2=80=99 > func updateIEEE(crc uint32, p []byte) uint32 { > ^ > /home3/andreas/clean/../gcc/libgo/go/hash/crc32/crc32_generic.go:20:1: no= te: previous definition of > =E2=80=98updateIEEE=E2=80=99 was here > func updateIEEE(crc uint32, p []byte) uint32 { > ^ > make[4]: *** [hash/crc32.lo] Error 1 > make[4]: *** Waiting for unfinished jobs.... > > > Adding more "build ignore"s does fix the build for me. Thanks for the patch. Committed. (FYI, you shouldn't make changes directly to libgo in the GCC repository--the files there are copied from a separate repository. See libgo/README.) > However, I'm wondering why we have to disable the asm tuned files for gcc= go? For s390 I really would > like to enable them since they make a huge difference. I would like to enable them also. They are not enabled today because the assembler code is written in the syntax accepted by https://golang.org/cmd/asm. The files in question are https://tip.golang.org/src/crypto/aes/asm_s390x.s https://tip.golang.org/src/hash/crc32/crc32_s390x.s If someone could rewrite those into gas syntax, we could use them in gccgo. > The same is probably also required in ./hash/crc32/crc32_amd64p32.go > I could add this as well. It is not needed there, because GOARCH will never match amd64p32. That is only used for NaCL, which gccgo does not support. Ian