From owner-freebsd-arm@FreeBSD.ORG Thu Dec 18 21:29:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F174EFB for ; Thu, 18 Dec 2014 21:29:59 +0000 (UTC) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED2C02830 for ; Thu, 18 Dec 2014 21:29:58 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id fp1so2184733pdb.24 for ; Thu, 18 Dec 2014 13:29:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=8xMcoKdxkZ0OSGQ9A3Uh7Kv6tWCSy2ty83F8QmuIcGY=; b=eEOfW0xE55YjUsg97bRWvOGBq57D4ZP715VIMWVpVPdMtry/DSDHe6ILSYY1X5Sb5E dHLDdLfGR4+g8e9D7aI9Bt9VOO5FsJJotMsIJnea6V5CGfufoLeBfaeMVYaPycTG5juq elSFdsIarskNvByLC5Xc+szRgcWO5o3RiQzX8sddYkX4+6Hf0iWrGBS6FnQzzSOnYKP8 +4YUaTtCcpwCHdrFtUO1ddq+5u113NHQmn3hjy00UCQfXmcrI1Ewbq4UXqr2WuE+ck+e 10cm0BfdCSQZyG124EhhfATF8BLZ6i8/EblkezfW+iz1n5fY4FcvLBGKv1lPTlBPqsyC qbuw== X-Gm-Message-State: ALoCoQlnM6h4Q5yRAiw8pVnt4PF1XHYuIdFX9FlNp5TMvN0fD8df7gSRo5wmSYs+zpZDNcSNO15E X-Received: by 10.70.27.225 with SMTP id w1mr7073622pdg.40.1418938192638; Thu, 18 Dec 2014 13:29:52 -0800 (PST) Received: from [10.64.25.114] ([69.53.236.236]) by mx.google.com with ESMTPSA id eo4sm7558138pbb.87.2014.12.18.13.29.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 13:29:51 -0800 (PST) Sender: Warner Losh Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> Date: Thu, 18 Dec 2014 14:29:49 -0700 Message-Id: <8C5EFF7C-9CA0-43A4-89A3-C6BFF518E83E@bsdimp.com> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1993) Cc: FreeBSD ARM , FreeBSD-Current , portmgr@FreeBSD.org, FreeBSD ports , FreeBSD toolchain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 21:29:59 -0000 --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 18, 2014, at 12:01 PM, Dimitry Andric wrote: >=20 > On 18 Dec 2014, at 15:47, Warner Losh wrote: > ... >>> * Mips will only have a chance with the upcoming clang 3.6.0, but = that >>> is way too late for this import. It will probably require external >>> toolchain support to get it working. >>=20 >> For native builds yes. For cross builds, clang 3.6 can be built on an >> x86 host. >=20 > Yes, and it could even be one of the ports, if that is easier to use. >=20 >=20 >> * Another ports exp-run was done [3], after fixing the problem with >>> lang/gcc, which lead to many skipped dependent ports. >>> * The second exp-run had much better results: the failure with the >>> highest number of dependencies is devel/mingw32-gcc, but this seems >>> to be due to a problem with makeinfo, not clang. The next highest = on >>> the list is java/openjdk6, for which ports r374780 [4] was very >>> recently committed. >>=20 >> Will users of our stable branch have code similar to the code that = caused >> problems? >=20 > I'm not sure which code you are referring to here, the openjdk6 code? > The code itself is basically fine, but for reasons unknown to me, the > port is compiled with -Werror (which is not the case for the other > openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings > for shaky C++ constructions, these appear during the openjdk6 build, = but > they are easily suppressed, if upstream does not fix them, or does not > care to fix them. I meant =E2=80=9Csimilar code to what=E2=80=99s causing problems=E2=80=9D = with the build run in their code they build on FreeBSD. If it is a few new warnings for obscure = things, we can advice to the release notes about what to avoid and how to = mitigate things. > I already sent Jung-uk an alternative fix for openjkd6, similar to the > one used for www/squid, where warnings are suppressed based on the > COMPILER_VERSION variable provided the ports infrastructure. In my > opinion it would still be easier to just to turn off -Werror for any > third-party code, if we don't feel like modifying it (with all the = risks > involved). Yea, we can sort out the code in src and ports. I=E2=80=99m more worried = about what to tell our users that may be compiling their own code that we = don=E2=80=99t control. If these new warnings are ubiquitous, then that could be a = problem for adoption (since many shops mandate -Werror as much as possible, and to comply with that mandate would require additional resources when = trying to upgrade). If there are a few, then we could just document them and = move on. >> One warning flag about your upgrade to the stable branch >> would be if there=E2=80=99s a significant number of user-written = programs that >> suddenly become uncompilable with the new clang using the environment >> that they have today. We know of some items that are issues, so = careful >> attention here is needed. Unless we go proactively looking for these, >> there=E2=80=99s a good chance we won=E2=80=99t find them until users = hit them and start >> to complain (by which point it is likely too late). Could you post a = summary >> of the issues that ports have hit and the fixes necessary? We may = need >> to have that in the release notes and/or UPDATING file to help = prepare >> our users for the bumps and give them solutions over them. >=20 > The base system is already completely free of warnings, as far as I = know > of, so no action is needed there. For ports, the number of failures > introduced by new warnings are quite small, as far as I can see, and > mostly for ports that are compiled with -Werror. Yea, I wasn=E2=80=99t too worried about this aspect of things. > The most encountered new warnings are, off the top of my head: >=20 > -Wabsolute-value >=20 > This warns in two cases, for both C and C++: > * When the code is trying to take the absolute value of an unsigned > quantity, which is effectively a no-op, and almost never what was > intended. The code should be fixed, if at all possible. > * When the code is trying to take the absolute value, but the called > abs() variant is of the wrong type, which may lead to truncation. > If the warning is turned off, better make sure any truncation does > not lead to unwanted side-effects. >=20 > -Wtautological-undefined-compare and > -Wundefined-bool-conversion >=20 > These warn when C++ code is trying to compare 'this' against NULL, = while > 'this' should never be NULL in well-defined C++ code. However, there = is > some legacy (pre C++11) code out there, which actively abuses this > feature, which was less strictly defined in previous C++ versions. >=20 > Squid does this, and apparently openjdk too. The warning can be = turned > off for C++98 and earlier, but compiling the code in C++11 mode might > result in unexpected behavior, for example the unreachable parts of = the > program could be optimized away. This is the kind of information I was talking about. Do we have a = process to make sure this gets into the release notes? >> I would really like to merge this branch to head in about a week, >>> pending portmgr approvall; I don't expect the base system (outside = of >>> llvm/clang) to need any further updates. >>=20 >> I think there=E2=80=99s good reason to do this, but we should chat = about the >> build issues below before doing it. They are minor, but an important >> detail. I=E2=80=99ll see if I can find a few minutes to pull the = branch and send >> patches. >>=20 >>> Lastly, to clear things up about the requirements for this branch = (and >>> thus for head, in a while); to build it, you need to have: >>> * A C++11 capable "host" compiler, e.g. clang >=3D 3.3 or later, or = gcc >>>> =3D 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) >>> * A C++11 standard library, e.g. libc++, or libstdc++ from gcc >=3D = 4.8. >>>=20 >>> So from any earlier standard 10.x or 11.x installation, you should = be >>> good, unless you explicitly disabled clang or libc++. In that case, >>> you must build and install both of those first. >>=20 >> This is true only on i386, amd64, and arm hosts. Given that some = people >> do try to do weird things, tightening up how you present this will = get the >> word out a little better. >>=20 >>> On a 9.x installation, you will have clang by default, but not = libc++, >>> so libc++ should be built and installed first, before attempting to >>> build the clang350-import branch. >>=20 >> Can you make sure that the UPDATING entry you are writing for this >> contains explicit instructions. >=20 > I'm quite bad at writing UPDATING entries, so any help there is much > appreciated. :-) I=E2=80=99m happy to help with this, but I work best from a rough draft = ... >> On 8.x an earlier, you need to upgrade to at least 9.x first, follow >>> the previous instruction. >>=20 >> We should remove building on 8 support then, unless there external >> toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, = etc). >=20 > The problem with 8.x is that it still has the old binutils 2.15, and > neither clang nor libc++. It would really require some externally > supplied parts. Maybe this could be done with ports, but I'm not sure > how long ports still supports the 8.x branch? If we can=E2=80=99t bootstrap from an 8.x system and have it work, we = need to remove support for doing that from Makefile.inc1 and friends. If we = think we can still support it with the external tool chain stuff, or with the = =E2=80=98end goal=E2=80=99 for the external toolchain stuff, we should leave it in. = At this point, I think it would be best to add a .warning for 8.x saying this isn=E2=80=99= t supported without an external toolchain, and then a month out from the branch = point we can decide what to do. 8.x is supported through the summer, iirc, on ports. Right now, for example, we say if the host is < 8.0 then we = don=E2=80=99t support it. I=E2=80=99ll add something that says if the host is < = 9 then bootstrapping clang won=E2=80=99t work, but I won=E2=80=99t make it an error just yet = and send it to you for your branch. >>> As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while >>> (roughly a month), but this will cause upgrades from 9.x to 10.x to >>> start requiring the build of libc++, as described above. I don't = think >>> we can merge clang 3.5.x to 9.x, unless clang becomes the default >>> compiler there (but that is very unlikely). >>=20 >> Let=E2=80=99s see how it goes, and what the upgrade issues wind up = being >> before doing this merge back. New =E2=80=9Cmajor=E2=80=9D compilers = on stable branches >> traditionally haven=E2=80=99t been done, but if clang is better about = being ABIly >> identical to prior releases than gcc was, it might not have the same = issues >> associated with it. >=20 > We don't really use llvm or clang's own ABI for anything at the = moment, > just the resulting compiler executable, which is actually one big = binary > (and it is even statically linked, by default). Right, this isn=E2=80=99t what I=E2=80=99m worried about... > The code output by clang 3.4.1 or 3.5.0 is not different in any "ABI" > sense of the word. Of course it will be different in absolute sense, > since optimizations were improved, and so on. This is what I=E2=80=99m worried about given our past experiences with = updating compilers. If we believe there=E2=80=99s no issues here, we can tick = that box but it was traumatic enough the last time we tried this (admittedly with gcc) that I have to ask. Similar representations were made, though it turned out people forgot to ask =E2=80=9Cincluding C++=E2=80=9D until = people noticed that it failed in some cases and started asking=E2=80=A6 > The only real issue is how to bootstrap the compiler itself, since it > requires working C++11 support. In 10.x, we provide that by default, > but not in earlier releases. Yea, that=E2=80=99s something we can document with release notes. Cool! Thanks for taking the time to address my concerns. Warner --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUk0dNAAoJEGwc0Sh9sBEAmUwP/jomM0zYSx9Pn+idgoLi8od8 l/e3bSMwuQcG8jZK+O7XkH+HFPMeDHRJUbFnr3TbnkHhxJIra5x7dOr0BArwzSDW vA1XwBNYcYsUQcgIlLNZ6KLOWmJoyTc8MVoEZPveVqVIyQwCHxHockm1Sl/jdkay fQMtnjES9ToBtpp4tqEFz/kb2hD4V1jJi90CXBdnAvzb2sFAQGZroSpIATo1n+0I XCUo8v1D/28T5xpapD4KUO3hqLc/UOeuozcEi/gBltix5e8xOCkVHyg9pGkiwJ9h 44J2o7k75LWPMZ9T52sCPFtc0F8RAKLcw1pSjRwfN9chCLirx1qnOBJwUmRH863Z X3Im4zDstU5rJhD4Dejsbals308oqyvjyLwS1nvdhReRbXajrj8O3F0UazWTB3cl oOEByTILaN5yrNdw5Y0WF8rPhP4cNQTKAyPv6BFolWW8fbPe8N573DbLbaZpQuX+ 41ppg/dkuV0FEQSVXFL70qZpKA1dRvnE2gBVxNaY5UTLr2urMDpR1ncvmqEVB65y E4qtgCPA9bSx0FPbajPHH8cO2KfK7T/DpHZlTmFLQ8ELWaPu1Vb6sY6mFTJ/es6V y5F4UzwwLsPZdxL/zedpK5J3DtU2tz+mM404267T7lRNOIFupGpZM4iSS0owXcQ+ yoxSQXZj5E1Z+/SMvK+S =ZvMz -----END PGP SIGNATURE----- --Apple-Mail=_1EA3A6F9-3440-4F1A-8A0B-18DF4D7401D4--