Re: RFT: Please help testing the llvm/clang 3.5.0 import
This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. I know Andrew doesn’t have the right arm gear to do this test, and emulation environments that run FreeBSD have had poor big-endian support for arm. * PowerPC64 should mostly work, thanks to Justin Hibbits. * PowerPC32 might start working soon; it really needs some backporting of fixes to clang 3.4.1, which is now in head, so there is an easier upgrade path for PowerPC users. * Sparc64 still does not work, and I don't see any quick solutions to it for now. It should probably stay with gcc. * 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. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. * 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. Will users of our stable branch have code similar to the code that caused problems? One warning flag about your upgrade to the stable branch would be if there’s 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’s a good chance we won’t 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. 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. I think there’s 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’ll see if I can find a few minutes to pull the branch and send patches. 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 = 3.3 or later, or gcc = 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 = 4.8. 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. 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. 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. Can you make sure that the UPDATING entry you are writing for this contains explicit instructions. On 8.x an earlier, you need to upgrade to at least 9.x first, follow the previous instruction. 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). 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). Let’s see how it goes, and what the upgrade issues wind up being before doing this merge back. New “major” compilers on stable branches traditionally haven’t been done, but if clang is
Call for testing: elftoolchain tools
We have a rather outdated version of binutils in the base system. As part of a project to update our toolchain I've started working on using some of the tools from the elftoolchain project. There is now a build knob to enable the use of the following tools: * addr2line * elfcopy (strip) * nm * size * strings The knob (in /etc/src.conf) is: WITH_ELFTOOLCHAIN_TOOLS=yes The binutils version is still used for as, ld, objcopy, objdump and readelf; future projects will handle these. The option is being tested in ports exp-runs on amd64 and i386, and has had basic sanity testing on arm64 and mips64. I'm interested in test reports across a variety of hardware architectures and use cases. If everything works as expected you should see no difference -- the tools should be drop-in replacements. -Ed ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 12:01 PM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 15:47, Warner Losh i...@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. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. Yes, and it could even be one of the ports, if that is easier to use. * 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. Will users of our stable branch have code similar to the code that caused problems? 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 “similar code to what’s causing problems” 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’m more worried about what to tell our users that may be compiling their own code that we don’t 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’s 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’s a good chance we won’t 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. 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’t too worried about this aspect of things. The most encountered new warnings are, off the top of my head: -Wabsolute-value 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. -Wtautological-undefined-compare and -Wundefined-bool-conversion 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. 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. I
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Warner Losh wrote this message on Thu, Dec 18, 2014 at 07:47 -0700: This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. I know Andrew doesn???t have the right arm gear to do this test, and emulation environments that run FreeBSD have had poor big-endian support for arm. I have a board that I plan to test on shortly... If Andrew would like, I know Jim Thompson has a standing offer to send board(s) to people who will test it... He provided me w/ the board I will be testing on soon... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
armeb build of clang350-import
Thought I’d try to build armeb on clang350-import branch on my ad64 host, and
found it failed to build because of a dependency on a machine include that
doesn’t exist yet.
% make buildworld TARGET=arm TARGET_ARCH=armeb -DWITHOUT_GCC{,_BOOTSTRAP}
-DWITH_CLANG{,_BOOTSTRAP}
...
=== gnu/lib/libgcc (obj,depend,all,install)
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
tm.h)
TARGET_CPU_DEFAULT= HEADERS=options.h dbxelf.h elfos-undef.h elfos.h
freebsd-native.h freebsd-spec.h freebsd.h arm/elf.h arm/aout.h arm/bpabi.h
arm/freebsd.h arm/arm.h defaults.h DEFINES= /bin/sh
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh
tm.h
echo '#define EXTRA_MODES_FILE arm/arm-modes.def' tm.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
tconfig.h)
TARGET_CPU_DEFAULT= HEADERS=auto-host.h ansidecl.h
DEFINES=USED_FOR_TARGET /bin/sh
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh
tconfig.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
options.h)
LC_ALL=C awk -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/c.opt
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/common.opt
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config/arm/arm.opt
optionlist
LC_ALL=C awk -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk
-f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk
optionlist options.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
unwind.h)
ln -sf
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config/arm/unwind-arm.h
unwind.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
gthr-default.h)
ln -sf
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h
gthr-default.h
cc -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcclibs/include
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
-I.
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
-Dinhibit_libc -fno-inline -std=gnu99 -fheinous-gnu-extensions
-Qunused-arguments -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions
-D__GLIBC__=3 -DElfW=__ElfN -o unwind-arm.o
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config/arm/unwind-arm.c
cc -c -O -pipe -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcclibs/include
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
-I.
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Dimitry Andric wrote this message on Tue, Dec 16, 2014 at 20:36 +0100: * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. hmmm... I can't get it to compile... Maybe I'm missing something... I tried to do: # make buildworld TARGET_ARCH=armeb WITH_BOOTSTRAP_CLANG= WITH_CLANG= WITHOUT_GCC= WITHOUT_BOOTSTRAP_GCC= This is from an amd64 host, though it is a month or two out of date... But it ended w/: c++ -O -pipe -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\armeb-gnueabi-freebsd11.0\ -DLLVM_HOST_TRIPLE=\armeb-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -fno-exceptions -fno-rtti -static -o clang cc1_main.o cc1as_main.o driver.o /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangserializati on/libclangserialization.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangedit/libclangedit.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmoption/libllvmoption.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmlinker/libllvmlinker.a /usr/obj/arm.armeb/a/src/usr.bin /clang/clang/../../../lib/clang/libllvmirreader/libllvmirreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmvectorize/libllvmvectorize.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvminstrumentation/libllvminstrumentation.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/ar m.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdesc/libllvmarmdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdisassembler/libllvmmipsdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmparser/libllvmmipsasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdesc/libllvmmipsdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinstprinter/libllvmmipsinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmp owerpccodegen/libllvmpowerpccodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmparser/libllvmpowerpcasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcdesc/libllvmpowerpcdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a
