Date: Thu, 18 Dec 2014 14:29:49 -0700 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@freebsd.org> Cc: FreeBSD ARM <freebsd-arm@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org>, portmgr@FreeBSD.org, FreeBSD ports <freebsd-ports@freebsd.org>, FreeBSD toolchain <freebsd-toolchain@freebsd.org> Subject: Re: RFT: Please help testing the llvm/clang 3.5.0 import Message-ID: <8C5EFF7C-9CA0-43A4-89A3-C6BFF518E83E@bsdimp.com> In-Reply-To: <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org> References: <8598B1D4-5485-426F-B6D6-22BF26AC5FE1@FreeBSD.org> <9A1A4235-3189-4A29-9942-64BF58A703F8@FreeBSD.org> <EF805BD1-34FA-433A-A149-9498A9B3A159@bsdimp.com> <7C679CB0-A17A-4463-ABF2-E3E456397F5E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <dim@freebsd.org> wrote: >=20 > On 18 Dec 2014, at 15:47, Warner Losh <imp@bsdimp.com> 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<mumble> then we = don=E2=80=99t support it. I=E2=80=99ll add something that says if the host is < = 9<mumble> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C5EFF7C-9CA0-43A4-89A3-C6BFF518E83E>