Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Mark Linimon wrote: On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. Let's remember that the entire toolchain is important here, and not just the compiler. Some of the problems can be attributed to our old binutils. For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error How did you obtain gcc4-errors? We're not alone here: some major GNU/Linux distributions, NetBSD, and DragonFlyBSD are using newer versions of binutils and/or gcc, so we can look at their patches and error logs to fix some problems. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Fri, Jun 04, 2010 at 08:13:55AM +, b. f. wrote: How did you obtain gcc4-errors? bzgrep -q See URL:http://gcc.gnu.org/bugs.html for instructions. Part of ports/Tools/portbuild/scripts/processonelog . mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
on 04/06/2010 11:13 b. f. said the following: Mark Linimon wrote: On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. Let's remember that the entire toolchain is important here, and not just the compiler. Some of the problems can be attributed to our old binutils. For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error How did you obtain gcc4-errors? We're not alone here: some major GNU/Linux distributions, NetBSD, and DragonFlyBSD are using newer versions of binutils and/or gcc, so we can look at their patches and error logs to fix some problems. DragonFlyBSD and NetBSD use newer GCC? This is the first time I hear about that. No doubt about major Linux distributions, though. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 6/4/10, Andriy Gapon a...@icyb.net.ua wrote: on 04/06/2010 11:13 b. f. said the following: Mark Linimon wrote: On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. Let's remember that the entire toolchain is important here, and not just the compiler. Some of the problems can be attributed to our old binutils. For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error How did you obtain gcc4-errors? We're not alone here: some major GNU/Linux distributions, NetBSD, and DragonFlyBSD are using newer versions of binutils and/or gcc, so we can look at their patches and error logs to fix some problems. DragonFlyBSD and NetBSD use newer GCC? This is the first time I hear about that. No doubt about major Linux distributions, though. DragonFlyBSD imported gcc 4.4 into their development branch in August 2009, binutils 2.20 in Oct. 2009, and switched to binutils 2.20 and gcc 4.4.2 in their 2.6.1 release: http://www.dragonflybsd.org/release26/ http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/gnu/lib/gcc44 http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/gnu/usr.bin/binutils220 NetBSD allows one to set HAVE_BINUTILS=2.19 and use http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/?only_with_tag=MAIN See the README there for their policy statement. I think they decided to bite the bullet and allow optional use of the later version because it was becoming increasingly hard to support some of their many architectures with the old stuff. But no doubt their mailing lists have more information. b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 4 June 2010 12:52, Andriy Gapon a...@icyb.net.ua wrote: on 04/06/2010 11:13 b. f. said the following: Mark Linimon wrote: On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. Let's remember that the entire toolchain is important here, and not just the compiler. Some of the problems can be attributed to our old binutils. For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error How did you obtain gcc4-errors? We're not alone here: some major GNU/Linux distributions, NetBSD, and DragonFlyBSD are using newer versions of binutils and/or gcc, so we can look at their patches and error logs to fix some problems. DragonFlyBSD and NetBSD use newer GCC? This is the first time I hear about that. No doubt about major Linux distributions, though. AFAIK, NetBSD does it for quite a while since they have a different pov on this. http://www.thejemreport.com/content/view/317 -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
DragonFlyBSD and NetBSD use newer GCC? This is the first time I hear about that. No doubt about major Linux distributions, though. AFAIK, NetBSD does it for quite a while since they have a different pov on this. http://www.thejemreport.com/content/view/317 That piece of journalism is utter garbage. As some have said on this thread - no-one forces anyone else to use GPL licensed software. If you don't want to use it then fine, but stop whining about the terms of the license if you do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 6/4/10, Mark Linimon lini...@lonesome.com wrote: On Fri, Jun 04, 2010 at 08:13:55AM +, b. f. wrote: How did you obtain gcc4-errors? bzgrep -q See URL:http://gcc.gnu.org/bugs.html for instructions. Part of ports/Tools/portbuild/scripts/processonelog . But are you actually building with lang/gcc4* and devel/binutils when these advisories are generated? If so, what added configuration settings are you using? b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Thursday 03 June 2010 8:52:36 pm Mark Linimon wrote: On Mon, May 31, 2010 at 01:22:05PM +0100, Bruce Cran wrote: From previous messages I don't think sparc64 is currently supported by clang very well, if at all, so I think we'll still need gcc in the base system for some time. I'll put on my tier-2 package builder hat for a moment. IMHO it helps FreeBSD's robustness to have our other architectures. In particular, fixing bugs in sparc64 may be helping us fix bugs that would affect arm/mips/powerpc, which are key for our embedded userbase. Perhaps I'm just invested in this from having spent time on sparc64 ... But a counter-argument is that if the two archs that llvm currently does not support well (sparc64 and ia64) start holding back major progress on amd64/i386, then we should give the most weight to what 90%+ of our userbase is on, and act accordingly. Hopefully that just means keep gcc as the default for our tier-2 archs. I've been finding it intellectually interesting to work on these, but really, they shouldn't be allowed to hold up the parade. Final note: there is indeed active kernel work on sparc64, ia64, and powerpc, so things are not stalled. I actually think that a realistic future may be that some archs use clang/llvm and some other archs still use gcc (probably with an option to use a gplv3 toolchain even, just not shipped by default perhaps). I even think it would be useful to have the option to use the latest gplv3 toolchain for amd64/i386 for folks who want to use it. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 6/4/10, b. f. bf1...@googlemail.com wrote: On 6/4/10, Andriy Gapon a...@icyb.net.ua wrote: on 04/06/2010 11:13 b. f. said the following: Mark Linimon wrote: On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: NetBSD allows one to set HAVE_BINUTILS=2.19 and use http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/?only_with_tag=MAIN See the README there for their policy statement. I think they decided to bite the bullet and allow optional use of the later version because it was becoming increasingly hard to support some of their many architectures with the old stuff. But no doubt their mailing lists have more information. I should say that, with reference to the NetBSD changes I mentioned earlier, and John Baldwin's comments about having a GPLv3 toolchain option in our own tree, that despite NetBSD's cautious policy statement regarding GPLv3-licensed software in their base system, and their requirement that such software should be optional, it appears that use of such software is now their _default_ since Nov. 2009: http://cvsweb.netbsd.org/bsdweb.cgi/src/share/mk/bsd.own.mk.diff?r1=1.593r2=1.594only_with_tag=MAINf=h b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
100% agreement with Mark here. On 06/03/10 17:19, Mark Linimon wrote: I'm just catching up with this thread, so apologies if this has already been pointed out elsewhere. One of the things that has been discussed w/rt compilers for a while (not just at the devsummit) was bending our minds around separating the concept of base system compiler from default ports compiler. In -stable branches, we must and shall not do large compiler updates. But ports probably need a more recent compiler (of whatever flavor) just to keep as many of them building as possible. (As upstream authors switch to newer compilers, their ports often don't build on whatever is in our base). Despite my enthusiasm for the future of llvm, the reality is that even in the medium-term there are so many ports with hardwired assumptions that they are running on gcc (not to mention on linux on i386) that it will never be possible to fix them all. The current paradigm is that as ports stop building with both base gcc, unless they are switched to depending on a newer gcc from ports, they'll be marked 'broken' and go through the deprecation cycle. Further, I remind people that compile and run and run equally as well through all code-paths are three completely separate levels of effort, possibly having an order of magnitude more work between each. We're looking at a multi-year process here, and not every single port is going to survive. But again -- not all of them currently do, anwyays. mcl -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
I'm just catching up with this thread, so apologies if this has already been pointed out elsewhere. One of the things that has been discussed w/rt compilers for a while (not just at the devsummit) was bending our minds around separating the concept of base system compiler from default ports compiler. In -stable branches, we must and shall not do large compiler updates. But ports probably need a more recent compiler (of whatever flavor) just to keep as many of them building as possible. (As upstream authors switch to newer compilers, their ports often don't build on whatever is in our base). Despite my enthusiasm for the future of llvm, the reality is that even in the medium-term there are so many ports with hardwired assumptions that they are running on gcc (not to mention on linux on i386) that it will never be possible to fix them all. The current paradigm is that as ports stop building with both base gcc, unless they are switched to depending on a newer gcc from ports, they'll be marked 'broken' and go through the deprecation cycle. Further, I remind people that compile and run and run equally as well through all code-paths are three completely separate levels of effort, possibly having an order of magnitude more work between each. We're looking at a multi-year process here, and not every single port is going to survive. But again -- not all of them currently do, anwyays. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. The latter number seems kind of low right now, but that's probably because some of them are now obscured by BROKEN tags: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc_bug For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error I don't have any statistic for produces bad code. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 01:22:05PM +0100, Bruce Cran wrote: From previous messages I don't think sparc64 is currently supported by clang very well, if at all, so I think we'll still need gcc in the base system for some time. I'll put on my tier-2 package builder hat for a moment. IMHO it helps FreeBSD's robustness to have our other architectures. In particular, fixing bugs in sparc64 may be helping us fix bugs that would affect arm/mips/powerpc, which are key for our embedded userbase. Perhaps I'm just invested in this from having spent time on sparc64 ... But a counter-argument is that if the two archs that llvm currently does not support well (sparc64 and ia64) start holding back major progress on amd64/i386, then we should give the most weight to what 90%+ of our userbase is on, and act accordingly. Hopefully that just means keep gcc as the default for our tier-2 archs. I've been finding it intellectually interesting to work on these, but really, they shouldn't be allowed to hold up the parade. Final note: there is indeed active kernel work on sparc64, ia64, and powerpc, so things are not stalled. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Den 31/05/2010 kl. 21.50 skrev Erik Cederstrand: I do have a problem with buildworld on an unmodified ClangBSD src/ tree within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building it's own Lexer because it picks up the gcc version of the headers instead of the clang version. This has been fixed before in ClangBSD, but probably the logic to decide on which headers to use are insufficient. Building a new ClangBSD VM from the latest revision solved this issue for me and I'm able to build ClangBSD within ClangBSD using unmodified sources. Erik
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Erik Cederstrand wrote: Den 31/05/2010 kl. 21.50 skrev Erik Cederstrand: I do have a problem with buildworld on an unmodified ClangBSD src/ tree within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building it's own Lexer because it picks up the gcc version of the headers instead of the clang version. This has been fixed before in ClangBSD, but probably the logic to decide on which headers to use are insufficient. Building a new ClangBSD VM from the latest revision solved this issue for me and I'm able to build ClangBSD within ClangBSD using unmodified sources. Fine, but can we stop calling it ClangBSD, else we end calling the other one Hurd (formerly known as gccBSD, which once was FreeBSD) /gT/ who now has an excuse to buy a new box, dedicated to FreeBSD(Clang). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Wed, Jun 2, 2010 at 4:14 PM, Gerd Truschinski g...@truschinski.de wrote: Erik Cederstrand wrote: Den 31/05/2010 kl. 21.50 skrev Erik Cederstrand: I do have a problem with buildworld on an unmodified ClangBSD src/ tree within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building it's own Lexer because it picks up the gcc version of the headers instead of the clang version. This has been fixed before in ClangBSD, but probably the logic to decide on which headers to use are insufficient. Building a new ClangBSD VM from the latest revision solved this issue for me and I'm able to build ClangBSD within ClangBSD using unmodified sources. Fine, but can we stop calling it ClangBSD, else we end calling the other one Hurd (formerly known as gccBSD, which once was FreeBSD) /gT/ who now has an excuse to buy a new box, dedicated to FreeBSD(Clang). I have resources; I just don't have the time to maintain more boxes right now. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Wed, Jun 2, 2010 at 4:52 PM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Jun 2, 2010 at 4:14 PM, Gerd Truschinski g...@truschinski.de wrote: Erik Cederstrand wrote: Den 31/05/2010 kl. 21.50 skrev Erik Cederstrand: I do have a problem with buildworld on an unmodified ClangBSD src/ tree within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building it's own Lexer because it picks up the gcc version of the headers instead of the clang version. This has been fixed before in ClangBSD, but probably the logic to decide on which headers to use are insufficient. Building a new ClangBSD VM from the latest revision solved this issue for me and I'm able to build ClangBSD within ClangBSD using unmodified sources. Fine, but can we stop calling it ClangBSD, else we end calling the other one Hurd (formerly known as gccBSD, which once was FreeBSD) /gT/ who now has an excuse to buy a new box, dedicated to FreeBSD(Clang). I have resources; I just don't have the time to maintain more boxes right now. On another note, your.org was donating cycles on ESX machines to the project, so... -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010, Garrett Cooper wrote: I personally would much rather have the glue in place to switch between compilers and have things default to the base version of gcc than just magically switch the compiler over to clang. But I like my bikesheds painted gray. Calling that a bikeshed misses the point of bikesheds. :-) I can't imagine that anyone is arguing for switching the default compiler to clang any time soon. The goal of the current exercise is to provide infrastructure and increase exposure. An entirely seperate set of decisions will be required to (perhaps) throw the following switches: - Make clang the default bootstrapping compiler (i.e., build kernel+world with it) on supported architectures. - Make clang the default ports build compiler. - Install clang as cc. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, Jun 01, 2010 at 10:46:54AM +1000, Lawrence Stewart wrote: On 06/01/10 09:25, James R. Van Artsdalen wrote: [snip interesting history] I do suggest modifying the FreeBSD build process so that uname -a shows the compiler and its version for both the kernel and userland. Reading through this discussion, I wanted to draw attention to this footnote in James' email. It sounds like a sensible and useful suggestion that would go some way to addressing Kostik's concerns about knowing whether a kernel bug report was related to a gcc or clang built kernel. This is unsufficient. What could work is if clang provided some common symbol into all .o files generated by it, e.g. __clang_compiled. And then kernel considered tainted with corresponding banner printed when weak reference to that symbol is resolved to non-zero. This does not handle modules and does not cleanly handle usermode runtime (libc, libthr, rtld etc). I do not care about users busting their systems by using alternative compilers and/or mixed builds. I worry about wasting developers time chasing bugs that are not bugs in the FreeBSD system. As an example see low-visible thread about sig11 during buildworld. pgp90qSFnvwcP.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 06:01:03PM -0500, Brooks Davis wrote: On Mon, May 31, 2010 at 03:52:27PM -0700, Tim Kientzle wrote: Matthew Seaman wrote: Presumably the import of clang to the base does not mean the immediate removal of gcc. Of course not. I'm not part of core and don't know what they may have discussed, but I went through some hoops to replace 'tar' and 'cpio' in the base system and have some idea what approach we might take with clang: I would expect FreeBSD 9 to ship with both compilers, with gcc as the default for 'cc'. So users of 9-STABLE would see and use gcc unless they specifically chose to use clang. Even if we did decide to switch the default for FreeBSD 10, it's possible we would continue to install gcc as part of the base system (just not as 'cc'). So realistically, some form of gcc will be built and installed by default for a few more years. Beyond that, it depends partly on how well clang does and partly on how many problems we have with an increasingly out-of-date gcc. Exactly. We will need to take some risks here, but nuking gcc from the tree won't be one of them for a while. I just sent a link to current and arch with links to the toolchain summit wiki page and a summary of the results. I encorage interested parties to read what is there and provide constructive suggestions. It would be useful to exclude clang or gcc from the build manually. Both both gcc and clang take a long time to compile. pgpkKkJpeDU6H.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, 01 Jun 2010 12:28:06 +0300, Lars Engels lars.eng...@0x20.net wrote: It would be useful to exclude clang or gcc from the build manually. You'd either have to fix a lot of ports or install gcc from ports anyway. Excluding gcc isn't too useful at the moment, but I see how that could be used in the future, once ports infrastructure knows that gcc isn't the one and only compiler. -- Andrius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 31 May 2010, at 11:56, Kostik Belousov wrote: My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. True enough, but that coin has two sides. Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang, but if you have multiple compilers at your disposal you can determine that you're probably looking at a compiler bug instead of a FreeBSD bug. Especially once there are users running the same code compiled with gcc and with clang it should be /easier/ to determine whether it's a compiler bug or not. Seeing a Y doesn't work for me compiled with clang vs. Y works for me compiled with gcc or vice versa would mean that the problem is likely in one of the compilers. Now you're probably correct in saying that the number of compiler bugs you are likely to encounter /now/ would be higher in clang than in gcc, but there also have been a number of cases where clang found bugs in code that gcc didn't find. Whether you find that useful is up to you, you are the developers after all. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4c04de8b10155455914109! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
I'm a bit disappointed in the polemical nature of some of the comments in this thread. I think we're all better off because of the existence of the FSF and their affiliates, and of a body of useful software under the (L)GPL, even if we prefer another license. No one has forced us to use the work that they've made freely available. With regard to importing clang now, I think that the effort needed for switching to a new compiler will not be greatly diminished by waiting, and we will be better served by learning about possible problems (and attempting to have them fixed upstream) sooner rather than later. Those who are concerned about introducing more variables into debugging will still be free to disregard reports involving clang for now if they choose, and we can emphasize that users should provide information about which compiler is involved in bug reports. Please, will those managing the import follow the recommendation of the tool-chain summit in allowing users to opt out of building and installing clang and any related tools with a knob in src.conf, and add support for ripping it out via the delete-old(-libs) targets and tools/build/mk/OptionalObsoleteFiles.inc, as part of any initial import? Also, others have announced that they are running regression tests on systems built with clang. Would it be possible to set up some regularly scheduled tests to uncover possible problems, if this hasn't been done already? b. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Den 01/06/2010 kl. 12.19 skrev b. f.: Also, others have announced that they are running regression tests on systems built with clang. Would it be possible to set up some regularly scheduled tests to uncover possible problems, if this hasn't been done already? As far as I know, regression tests in FreeBSD are pretty sporadic, and a real regression testing system is an open project (http://www.freebsd.org/projects/ideas/ideas.html#p-regression). There's a collection of tests in src/tools/regression which can be run by installing devel/p5-Test-Harness. It does seem like the tests are in a sorry state, as an insane amount of tests are failing for me: freebsd# uname -a FreeBSD freebsd.local 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 freebsd# cd /usr/src/tools/regression/ freebsd# prove fstest/tests/chflags fstest/tests/chflags/00.t .. ok fstest/tests/chflags/01.t .. Failed 5/5 subtests fstest/tests/chflags/02.t .. Failed 6/6 subtests fstest/tests/chflags/03.t .. Failed 13/13 subtests [...] Result: FAIL clangbsd# uname -a FreeBSD clangbsd.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r208586:208611M: Thu May 27 23:35:35 CEST 2010 r...@vb_fbsd8.local:/usr/obj/usr/home/erik/freebsd/clangbsd/src/sys/GENERIC amd64 clangbsd# cd /usr/src/tools/regression/ clangbsd# prove fstest/tests/chflags fstest/tests/chflags/00.t .. ok fstest/tests/chflags/01.t .. Failed 5/5 subtests fstest/tests/chflags/02.t .. Failed 6/6 subtests fstest/tests/chflags/03.t .. Failed 13/13 subtests [...] Result: FAIL Thanks, Erik
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, 1 Jun 2010 15:27:24 +0200 Erik Cederstrand e...@cederstrand.dk wrote: There's a collection of tests in src/tools/regression which can be run by installing devel/p5-Test-Harness. It does seem like the tests are in a sorry state, as an insane amount of tests are failing for me: I get quite a different result on my standard 9-CURRENT system, testing a UFS filesystem: router# prove -r /usr/src/tools/regression/fstest/tests/chflags /usr/src/tools/regression/fstest/tests/chflags/00.t .. ok /usr/src/tools/regression/fstest/tests/chflags/01.t .. ok /usr/src/tools/regression/fstest/tests/chflags/02.t .. ok /usr/src/tools/regression/fstest/tests/chflags/03.t .. ok /usr/src/tools/regression/fstest/tests/chflags/04.t .. ok /usr/src/tools/regression/fstest/tests/chflags/05.t .. ok /usr/src/tools/regression/fstest/tests/chflags/06.t .. ok /usr/src/tools/regression/fstest/tests/chflags/07.t .. ok /usr/src/tools/regression/fstest/tests/chflags/08.t .. ok /usr/src/tools/regression/fstest/tests/chflags/09.t .. ok /usr/src/tools/regression/fstest/tests/chflags/10.t .. ok /usr/src/tools/regression/fstest/tests/chflags/11.t .. ok /usr/src/tools/regression/fstest/tests/chflags/12.t .. ok /usr/src/tools/regression/fstest/tests/chflags/13.t .. ok All tests successful. Files=14, Tests=631, 123 wallclock secs ( 1.95 usr 0.41 sys + 8.50 cusr 29.30 csys = 40.16 CPU) Result: PASS Don't know what that proves though :P -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang, but if you have multiple compilers at your disposal you can determine that you're probably looking at a compiler bug instead of a FreeBSD bug. Especially once there are users running the same code compiled with gcc and with clang it should be /easier/ to determine whether it's a compiler bug or not. Seeing a Y doesn't work for me compiled with clang vs. Y works for me compiled with gcc or vice versa would mean that the problem is likely in one of the compilers. Apparently, you've never read a programming language standard document. You could run into the above situation where both compilers are behaving correctly. Most language standards contain language of the form processor dependent behavior or implementation defined behavior. Here's an example from a draft of the C standard (n1256.pdf). 3.4.1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made EXAMPLE: An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 6/1/2010 3:38 AM, Kostik Belousov wrote: This is unsufficient. What could work is if clang provided some common symbol into all .o files generated by it, e.g. __clang_compiled. And then kernel considered tainted with corresponding banner printed when weak reference to that symbol is resolved to non-zero. This does not handle modules and does not cleanly handle usermode runtime (libc, libthr, rtld etc). Would it be sufficient if send-pr were modified to test the kernel, all loaded modules, and shared objects in /lib, /usr/lib and /usr/local/lib, and to list all items that were _not_ marked with the default compiler version? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Kostik Belousov kostik...@gmail.com writes: I do not object to a single point in your message. On the other hand, all said could be labeled as distilled propaganda. Perhaps, but... [...] This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? ...so is this. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Attilio Rao atti...@freebsd.org writes: I really would like to see CLANG more integrated with FreeBSD only when there are 0 or similar (well-known, already analyzed, listed somewhere, etc.) bugs by the compiler [...] Does this means you're planning to remove GCC, since it has tons of known bugs? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 01.06.2010 16:55, Dag-Erling Smørgrav wrote: Attilio Rao atti...@freebsd.org writes: I really would like to see CLANG more integrated with FreeBSD only when there are 0 or similar (well-known, already analyzed, listed somewhere, etc.) bugs by the compiler [...] Does this means you're planning to remove GCC, since it has tons of known bugs? Sounds more like a knee-jerk reaction to removal of GCC by a ... herd of gnus. ;) //Svein -- +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 01.06.2010 20:57, Vanessa Kraus wrote: It's exciting that there may soon be an option other than gcc for FreeBSD. However I have a few questions. Is there going to be a system in place that will allow port maintainers to say hey this port is now built successfully with Clang or hey this port only builds successfully with gcc? Is it realistic to think that gnome and kde could be built with Clang/LLVM now or in the future? Do you know when you will be interested in being notified of arbitrary ports that wont build with Clang, and where should these notifications be sent? Actually, such a system kind of already exists. It's called build-depends ;) //Svein -- +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
FWIW, I support the import. I don't think GCC is as bad as other people think it is, but I also have been gravely concerned of the the reduction of toolchains down close to one in our business. That in and of itself warrants supporting any viable alternative. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On May 30, 2010, at 7:58 AM, Kostik Belousov wrote: On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. Sounds like you're inviting the discussion right now. I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. 2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still. 3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products. 4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev. 5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the remove gcc discussion. The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Sat, May 29, 2010 at 8:02 AM, Roman Divacky rdiva...@freebsd.org wrote:
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to
import
into HEAD in roughly a week. We would like the initial import to be as
painless
as possible and therefore we ask you to test ClangBSD to assure that the
revision
we are importing does not have some really embarassing bugs.
How to do it (on i386 and amd64):
0) install fresh devel/llvm-devel port
1) svn co http://svn.freebsd.org/base/projects/clangbsd src
2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf
3) cd src make buildworld
4) make installworld DESTDIR=/usr/clangbsd
5) (optional) try to build kernel with clang and boot it
5.1) cd /sys/{arch}/conf
5.2) config YOUR_KERNEL
5.3) setenv CC clang in tcsh or export CC=clang in bash
5.4) cd ../compile/YOUR_KERNEL
5.5) make make install
please make sure that it builds (on amd64/i386) and that the resulting world
is runnable. ie. try to chroot into it and do stuff. ie.
chroot /clangbsd /bin/tcsh
... stuff ...
there's a wiki page on this effort:
http://wiki.freebsd.org/BuildingFreeBSDWithClang
please report back any problems/success to me and/or this mailing list.
thank you for your testing!
Roman Divacky on behalf of the ClangBSD team
I'm running on a full ClangBSD system (world and kernel), and I've
had no issues for the past couple of days. I've had the machine
working nearly constantly -- building new and updating installed
ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and
generally using/abusing my computer by watching Flash video on the
bsdconferences channel on YouTube...
So, what exactly should we expect, if anything, to break? :)
Is there anything more useful than an it works type of feedback that
a novice user like myself could provide?
And...
A Little Message To the ClangBSD Team:
As little more than a novice user, I realize that I don't have the
full picture of what moving from GCC to clang/llvm means to FreeBSD. I
don't have enough experience with either compiler technology or the
FreeBSD project to have a lot to say in any discussion or dialog
regarding the decisions to come. But I do trust the FreeBSD project as
a whole -- the technology and the people involved -- and it seems that
this is a mandatory step in order to continue to to enhance FreeBSD.
So thank you to the ClangBSD team for making awesome progress. It
makes me incredibly happy to see all those involved with ClangBSD,
especially Roman, stand up and steer FreeBSD toward the future.
Looking forward to it,
-Brandon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote: On May 30, 2010, at 7:58 AM, Kostik Belousov wrote: On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. Sounds like you're inviting the discussion right now. I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. 2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still. 3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products. 4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev. 5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the remove gcc discussion. The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project. Scott I do not object to a single point in your message. On the other hand, all said could be labeled as distilled propaganda. My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. Rather, I would consider the changes to ease the use of any external compiler, from ports or whatever, bent into shape and kept up to date with system progress very important, much less controversial and more useful. Then, addicts of any kool-aid-compiler can drink their potion without starting undesired relations. Unfortunately, this is not what happen. pgpYeQEsehxau.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:56:17PM +0300, Kostik Belousov wrote:
On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote:
On May 30, 2010, at 7:58 AM, Kostik Belousov wrote:
On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote:
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we
aim to import into HEAD in roughly a week. We would like the initial
It was promised that before the import, the public discussion on
the mailing list will happen. So far, nothing appeared on either
arch@ or current@ providing argumentation why should we accept this.
Sounds like you're inviting the discussion right now. I'll start =-)
1. I hate gcc with the burning heat of a million suns. It's not a
tool, it's a political weapon wielded by the FSF and their acolytes.
It's also a crummy piece of software that has been good enough for
far too long. Its development model is a burden to work with and has
been a major liability towards FreeBSD releases in the past. Its
demise cannot happen soon enough.
2. Due to the political bent of the GPL3 and the FSF's insistence
on shoving it down everyone's throats, FreeBSD is stuck with a
dead-end version of gcc. This has already been a liability in terms
of addressing bugs in gcc itself, and it will only get worse as
technology moves forward and gcc stands still.
3. Clang/LLVM has an active development base and a clear future. It
will move forward while gcc rots. There simply is no future left in
gcc unless the FreeBSD project decides to embrace the GPL3, and that's
a move that has already been heavily discussed, debated, and decided
on. Anecdotally, I think that FreeBSD is benefiting from shunning the
GPL3; it's made it an attractive option for companies looking for an
unencumbered OS for their products.
4. While Clang is immature now, it will mature in the near future,
and FreeBSD will benefit from that process. FreeBSD will get built-in
access to upcoming technologies like GCD+Blocks and better code
editors and development tools that gcc will never support. It'll break
free of the development stranglehold that exists within gcc. Clang has
shown good agility in adapting to the needs of FreeBSD and the legacy
of gcc, thanks in large part to the efforts of people like Roman. Gcc
has been nothing but drama and headache, even with the valiant efforts
of people like Alexander Kabaev.
5. If all of this turns out to not be true and Clang/LLVM fails,
FreeBSD has lost nothing and can remove it from the base system. Gcc
remains where it is for now, at least until it's time for the remove
gcc discussion.
The future is !gcc. Putting Clang+LLVM into a position where it can
be easily embraced by FreeBSD users will greatly benefit the FreeBSD
project.
Scott
I do not object to a single point in your message. On the other hand, all
said could be labeled as distilled propaganda.
My main concern is the usefulness of HEAD for routine bug-fixing process.
The proposed merge makes it relatively easy for users to start compiling
the system with CLang. Our HEAD userbase is one of the most valuable
project asset to ensure the quality of the system. After the support for
easy compilation with clang is imported, some substantial portion of the
HEAD users definitely start experimenting with it. This immediately makes
the bug reports against HEAD almost useless, since level of demotivation
when looking at the bug is immense. When you do know that the issue can
be in the compiler, and not the OS, why looking ?
Any bug analisys now shall start with exchange to verify which compiler
was used to build the reporter system, and ask to reproduce it with gcc.
[I am talking not only about gnats, but also mailing list questions,
private pleas for help etc].
agreed. what do you propose to help identify/prevent situations when
people are reporting bugs coming from a compiler problem rather than
those from a genuine src problem?
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
My personal opinion is that pushing the import now at the present state
of clang makes a disservice to FreeBSD, and possible clang. Why not keep
the glue on the branch as it is ? Motivated testers willing to help
definitely can checkout from the branch. Import can happen when we are
satisfied with the quality of new compiler, instead of discontent about
old one.
people have been testing stuff and identified bugs. those bugs were fixed.
there are sure some more but we need wider exposure to identify those
new bugs and also clasify them.
the amount of people who are willing and able to checkout and test external
branch is minimal. I feel we are at the point where more exposure is
necessary.
by importing we are sending a strong signal to various 3rd
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On May 31, 2010, at 3:56 AM, Kostik Belousov wrote: My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. Who is we, and what is their criteria? Are you speaking for the entire FreeBSD project? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:24:52PM +0200, Roman Divacky wrote:
On Mon, May 31, 2010 at 12:56:17PM +0300, Kostik Belousov wrote:
On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote:
On May 30, 2010, at 7:58 AM, Kostik Belousov wrote:
On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote:
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we
aim to import into HEAD in roughly a week. We would like the initial
It was promised that before the import, the public discussion on
the mailing list will happen. So far, nothing appeared on either
arch@ or current@ providing argumentation why should we accept this.
Sounds like you're inviting the discussion right now. I'll start =-)
1. I hate gcc with the burning heat of a million suns. It's not a
tool, it's a political weapon wielded by the FSF and their acolytes.
It's also a crummy piece of software that has been good enough for
far too long. Its development model is a burden to work with and has
been a major liability towards FreeBSD releases in the past. Its
demise cannot happen soon enough.
2. Due to the political bent of the GPL3 and the FSF's insistence
on shoving it down everyone's throats, FreeBSD is stuck with a
dead-end version of gcc. This has already been a liability in terms
of addressing bugs in gcc itself, and it will only get worse as
technology moves forward and gcc stands still.
3. Clang/LLVM has an active development base and a clear future. It
will move forward while gcc rots. There simply is no future left in
gcc unless the FreeBSD project decides to embrace the GPL3, and that's
a move that has already been heavily discussed, debated, and decided
on. Anecdotally, I think that FreeBSD is benefiting from shunning the
GPL3; it's made it an attractive option for companies looking for an
unencumbered OS for their products.
4. While Clang is immature now, it will mature in the near future,
and FreeBSD will benefit from that process. FreeBSD will get built-in
access to upcoming technologies like GCD+Blocks and better code
editors and development tools that gcc will never support. It'll break
free of the development stranglehold that exists within gcc. Clang has
shown good agility in adapting to the needs of FreeBSD and the legacy
of gcc, thanks in large part to the efforts of people like Roman. Gcc
has been nothing but drama and headache, even with the valiant efforts
of people like Alexander Kabaev.
5. If all of this turns out to not be true and Clang/LLVM fails,
FreeBSD has lost nothing and can remove it from the base system. Gcc
remains where it is for now, at least until it's time for the remove
gcc discussion.
The future is !gcc. Putting Clang+LLVM into a position where it can
be easily embraced by FreeBSD users will greatly benefit the FreeBSD
project.
Scott
I do not object to a single point in your message. On the other hand, all
said could be labeled as distilled propaganda.
My main concern is the usefulness of HEAD for routine bug-fixing process.
The proposed merge makes it relatively easy for users to start compiling
the system with CLang. Our HEAD userbase is one of the most valuable
project asset to ensure the quality of the system. After the support for
easy compilation with clang is imported, some substantial portion of the
HEAD users definitely start experimenting with it. This immediately makes
the bug reports against HEAD almost useless, since level of demotivation
when looking at the bug is immense. When you do know that the issue can
be in the compiler, and not the OS, why looking ?
Any bug analisys now shall start with exchange to verify which compiler
was used to build the reporter system, and ask to reproduce it with gcc.
[I am talking not only about gnats, but also mailing list questions,
private pleas for help etc].
agreed. what do you propose to help identify/prevent situations when
people are reporting bugs coming from a compiler problem rather than
those from a genuine src problem?
If I have a good idea how to help a situation, I would described it. It
is very strange and worrying that you, who are pushing the import, ask
somebody about plan on identifying and handling the compiler bugs. I
would expect you to have a solid plan before the import. This lowers my
confidence in the proposal even further.
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about signal.
My personal opinion is that pushing the import now at the present state
of
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
2010/5/31 Kostik Belousov kostik...@gmail.com: On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote: On May 30, 2010, at 7:58 AM, Kostik Belousov wrote: On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. Sounds like you're inviting the discussion right now. I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. 2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still. 3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products. 4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev. 5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the remove gcc discussion. The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project. Scott I do not object to a single point in your message. On the other hand, all said could be labeled as distilled propaganda. My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. FWIW, I entirely agree with Kostik here. I really would like to see CLANG more integrated with FreeBSD only when there are 0 or similar (well-known, already analyzed, listed somewhere, etc.) bugs by the compiler rather than still being in the middle of a bug storm. Besides, the 'debugging problem' is pretty much real and nobody answered with a reasonable solution for it, and being honest, I don't see the people pushing for the import concerned about that at all. Are all the bug reports collected somewhere? What's the state of their resolution? There is a description somewhere of missing support and things still to be addressed? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:54:29PM +0200, Attilio Rao wrote: 2010/5/31 Kostik Belousov kostik...@gmail.com: On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote: On May 30, 2010, at 7:58 AM, Kostik Belousov wrote: On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. Sounds like you're inviting the discussion right now. ??I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. 2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still. 3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products. 4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev. 5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the remove gcc discussion. The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project. Scott I do not object to a single point in your message. On the other hand, all said could be labeled as distilled propaganda. My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. FWIW, I entirely agree with Kostik here. I really would like to see CLANG more integrated with FreeBSD only when there are 0 or similar (well-known, already analyzed, listed somewhere, etc.) bugs by the compiler rather than still being in the middle of a bug storm. Besides, the 'debugging problem' is pretty much real and nobody answered with a reasonable solution for it, and being honest, I don't see the people pushing for the import concerned about that at all. Are all the bug reports collected somewhere? What's the state of their resolution? There is a description somewhere of missing support and things still to be addressed? there are no known clang bugs (at
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
2010/5/31 Roman Divacky rdiva...@freebsd.org: On Mon, May 31, 2010 at 12:54:29PM +0200, Attilio Rao wrote: 2010/5/31 Kostik Belousov kostik...@gmail.com: On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote: On May 30, 2010, at 7:58 AM, Kostik Belousov wrote: On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. Sounds like you're inviting the discussion right now. ??I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. 2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still. 3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products. 4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev. 5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the remove gcc discussion. The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project. Scott I do not object to a single point in your message. On the other hand, all said could be labeled as distilled propaganda. My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. FWIW, I entirely agree with Kostik here. I really would like to see CLANG more integrated with FreeBSD only when there are 0 or similar (well-known, already analyzed, listed somewhere, etc.) bugs by the compiler rather than still being in the middle of a bug storm. Besides, the 'debugging problem' is pretty much real and nobody answered with a reasonable solution for it, and being honest, I don't see the people pushing for the import concerned about that at all. Are all the bug reports collected somewhere? What's the state of their resolution? There is a description somewhere of missing support and things still to be
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
If I understand the build process correctly, it should be possible to have both compilers in base for some (presumably short) period of time... then just have which one you use be a configuration option, which should give LLVM/clang some additional exposure, without the obvious risks of a complete switch. It should be relatively simply to have clang as a compile time option in base then clang as default with gcc as an option then clang only, as it proves itself out building the tree. I don't really see how the ~50-100MB that only keeping one compiler in base for a month or two (when there's not going to be a release from HEAD anyway) would be worth it, when it's compared to the massive cluster this is probably going to turn into, provided there's a relatively easy way to opt out of either compiler. As far as bug reports go, it's not as though this is some unprecedented problem. In handling PRs, people are asked to rebuild with patches, different settings, etc already. Its just one more thing among a list of many to keep in mind when going through that process. I don't think users of HEAD would find such a request unreasonable (or, at least, any more unreasonable than what they already have to go through sometimes.) --- Harrison Grundy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
there are no known clang bugs (at least known to me) related to FreeBSD in other words - at this point you can compile FreeBSD with clang (both in the version in clangbsd) and it works (for people who tested it) on amd64 and i386 I don't mean about FreeBSD, but about CLANG itself. It would be very depressing to loose many hours on kernel races before to discover it was a compiler deficiency, for example. thats what I mean - we are not aware of any bugs in clang itself that harm FreeBSD (on i386/amd64). btw. there are 68 open bug reports against gcc 4.2.1 in gcc bugzilla. pgpCXTd7oxwJa.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about signal.
what I wanted to say is that we can get problem reports from people using
other compilers than our stock gcc even today.
Rather, I would consider the changes to ease the use of any external
compiler, from ports or whatever, bent into shape and kept up to date
with system progress very important, much less controversial and more
useful. Then, addicts of any kool-aid-compiler can drink their potion
without starting undesired relations. Unfortunately, this is not what
happen.
this is orthogonal to this. we as a project aim for delivering complete
operating system and we just need a system compiler. gcc4.2.1 just
cant serve us anymore, we need to do something now.
Please describe why gcc in base cannot serve us anymore while served up
to the minute I got your message.
that was summarized in a beautiful way by Scott Long :)
pgpH7p7tmULGb.pgp
Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 6:39 AM, Roman Divacky rdiva...@freebsd.org wrote:
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about signal.
what I wanted to say is that we can get problem reports from people using
other compilers than our stock gcc even today.
Rather, I would consider the changes to ease the use of any external
compiler, from ports or whatever, bent into shape and kept up to date
with system progress very important, much less controversial and more
useful. Then, addicts of any kool-aid-compiler can drink their potion
without starting undesired relations. Unfortunately, this is not what
happen.
this is orthogonal to this. we as a project aim for delivering complete
operating system and we just need a system compiler. gcc4.2.1 just
cant serve us anymore, we need to do something now.
Please describe why gcc in base cannot serve us anymore while served up
to the minute I got your message.
that was summarized in a beautiful way by Scott Long :)
I don't think this is really a question of Can gcc work in base right
now?. Everyone knows it can, because that's what's actually being
used at this very moment. At the same time, I don't think there's any
real argument in saying that eventually FreeBSD will have to switch to
either a new compiler, or a new version of gcc, with the GPLv3
nightmare that could entail (Maybe that's a few years from now, I have
no idea, but it's still going to need to happen, and its not as though
switching will get easier with time.) From my perspective, there seem
to be two real questions:
First, are the two compilers mutually exclusive? (I don't believe they are.)
Second, is there a particular reason not to do this now, that will not
exist later? (I'm not that current on what's going on.. but from what
I can tell, my thought here is no, too.)
It's not as though this is irreversible. It's always possible to make
the change, realize clang won't cut it just yet, and switch back a few
hours/days/weeks/whatever later. Or, like I said earlier, if it's
possible, run both.
--- Harrison
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 06:55:17AM -0500, Astrodog wrote:
On Mon, May 31, 2010 at 6:39 AM, Roman Divacky rdiva...@freebsd.org wrote:
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about signal.
what I wanted to say is that we can get problem reports from people using
other compilers than our stock gcc even today.
Rather, I would consider the changes to ease the use of any external
compiler, from ports or whatever, bent into shape and kept up to date
with system progress very important, much less controversial and more
useful. Then, addicts of any kool-aid-compiler can drink their potion
without starting undesired relations. Unfortunately, this is not what
happen.
this is orthogonal to this. we as a project aim for delivering complete
operating system and we just need a system compiler. gcc4.2.1 just
cant serve us anymore, we need to do something now.
Please describe why gcc in base cannot serve us anymore while served up
to the minute I got your message.
that was summarized in a beautiful way by Scott Long :)
I don't think this is really a question of Can gcc work in base right
now?. Everyone knows it can, because that's what's actually being
used at this very moment. At the same time, I don't think there's any
real argument in saying that eventually FreeBSD will have to switch to
either a new compiler, or a new version of gcc, with the GPLv3
nightmare that could entail (Maybe that's a few years from now, I have
no idea, but it's still going to need to happen, and its not as though
switching will get easier with time.) From my perspective, there seem
to be two real questions:
First, are the two compilers mutually exclusive? (I don't believe they are.)
Second, is there a particular reason not to do this now, that will not
exist later? (I'm not that current on what's going on.. but from what
I can tell, my thought here is no, too.)
It's not as though this is irreversible. It's always possible to make
the change, realize clang won't cut it just yet, and switch back a few
hours/days/weeks/whatever later. Or, like I said earlier, if it's
possible, run both.
See, there is no objection to the idea that clang can and may eventually
displace gcc in the base. This is not the subject of the thread.
The question is whether it is beneficial for FreeBSD to import
infrastructure to ease the clang-in-base spins up to the point where
user can set one variable before the build, right now.
From what it was claimed, even without the import, users can install
whatever compiler from ports, set CC and start the build. Essentially,
the import blesses the clang and its current state as ready for wide use.
pgptyaKjynMra.pgp
Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010 06:11:32 -0500 Astrodog astro...@gmail.com wrote: If I understand the build process correctly, it should be possible to have both compilers in base for some (presumably short) period of time... then just have which one you use be a configuration option, which should give LLVM/clang some additional exposure, without the obvious risks of a complete switch. It should be relatively simply to have clang as a compile time option in base then clang as default with gcc as an option then clang only, as it proves itself out building the tree. From previous messages I don't think sparc64 is currently supported by clang very well, if at all, so I think we'll still need gcc in the base system for some time. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 2:04 PM, Kostik Belousov kostik...@gmail.com wrote: (...) From what it was claimed, even without the import, users can install whatever compiler from ports, set CC and start the build. Essentially, the import blesses the clang and its current state as ready for wide use. Not necessarily. If it is - disabled by default - not recommended anywhere - recommended against for production usage (I suspect it will carry the usual might set your dog on fire - disclaimer for a while) that's hardly a glowing recommendation. I'm not sure if it's the best comparison, but it reminds me of how SCHED_ULE was available but mostly ignored until it was made default. -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 8:04 AM, Kostik Belousov kostik...@gmail.comwrote: See, there is no objection to the idea that clang can and may eventually displace gcc in the base. This is not the subject of the thread. The question is whether it is beneficial for FreeBSD to import infrastructure to ease the clang-in-base spins up to the point where user can set one variable before the build, right now. From what it was claimed, even without the import, users can install whatever compiler from ports, set CC and start the build. Essentially, the import blesses the clang and its current state as ready for wide use. This import simply makes it possible to start testing clang in a more widespread fashion. It doesn't bless anything or make any kind of claim to the suitability of clang for production. I for one am excited about this import and think that this kind of bold step is an enormous victory for FreeBSD. Clang is clearly the future of compiler technology and the earlier we get on board the more involvement we will have with the Clang team and everyone will reap the benefits. So, while I'm just a user this absolutely gets my vote and I look forward to it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010, Scott Long wrote: On May 31, 2010, at 3:56 AM, Kostik Belousov wrote: My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. Who is we, and what is their criteria? Are you speaking for the entire FreeBSD project? I think Kostik's question here is legitimate: clang maturity changes over time. The earlier we adopt it, the sooner we get the advantages of clang -- but we also end up being the people who fault in more of the hard-to-diagnose compiler bugs. Since Kostik fields many of our complex file system/VM/etc bugs, which are themselves often symptoms of hardware problems rather than software bugs (a similar class of issue), and is on the release engineering team, I think he speaks with some authority on the matter. I happen to (currently) disagree with him on whether clang is ready for us to drop in the base system, as I feel providing early access to it (but not enabling it as the bootstrap by default) will be of significant benefit, but don't think that delegitimizes the concern he raises. You can burn a lot of hours chasing software bugs only to eventually (or never) figure out they are compiler bugs. This is the trade-off, but as you point out in your e-mail, there is also a larger non-technical context. By throwing our weight behind clang, we benefit in numerous and often non-technical ways: we lend the clang folks an engaged and technically astute user community who can help them mature their software, as well as give them a user they community they can point at as part of establishing their own legitimacy. That engagement in turn means they will be more responsive to our needs, and it's clear we're at a swing of the compiler/systems pendulum where we can benefit from the improved compiler technology we get through using clang. I also have to say that I've found the clang folks extremely responsive to date -- the one compiler bug I ran into doing the GCD port to FreeBSD was fielded in about 60 minutes, from my report to a fix in their tree. Very impressive. Of course, I also burned 4-6 hours realizing it was a compiler bug before we got to that point, which is, of course, precisely the issue Kostik is pushing on. But I think, at this moment, it's a risk we need to take, manage it well, and benefit from the results. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 02:49:35AM -0500, Brandon Gooch wrote: I'm running on a full ClangBSD system (world and kernel), and I've had no issues for the past couple of days. I've had the machine working nearly constantly -- building new and updating installed ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and generally using/abusing my computer by watching Flash video on the bsdconferences channel on YouTube... So, what exactly should we expect, if anything, to break? :) Did you build and install new boot code? ISTR that clang can't compile src/sys/boot/i386/boot0 to the required 512 bytes. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010, Robert Watson wrote: I think Kostik's question here is legitimate: clang maturity changes over time. The earlier we adopt it, the sooner we get the advantages of clang -- but we also end up being the people who fault in more of the hard-to-diagnose compiler bugs. Since Kostik fields many of our complex file system/VM/etc bugs, which are themselves often symptoms of hardware problems rather than software bugs (a similar class of issue), and is on the release engineering team, I think he speaks with some authority on the matter. I happen to (currently) disagree with him on whether clang is ready for us to drop in the base system, as I feel providing early access to it (but not enabling it as the bootstrap by default) will be of significant benefit, but don't think that delegitimizes the concern he raises. You can burn a lot of hours chasing software bugs only to eventually (or never) figure out they are compiler bugs. This is the trade-off, but as you point out in your e-mail, there is also a larger non-technical context. By throwing our weight behind clang, we benefit in numerous and often non-technical ways: we lend the clang folks an engaged and technically astute user community who can help them mature their software, as well as give them a user they community they can point at as part of establishing their own legitimacy. That engagement in turn means they will be more responsive to our needs, and it's clear we're at a swing of the compiler/systems pendulum where we can benefit from the improved compiler technology we get through using clang. I would like to see this decision made without political bias. Is clangBSD able to support all our architectures? Does it cross build for powerpc, mips, etc? Has it made a ports run and does it successfully build and run most of our ports on Tier-1 archs, and does it compare similarly with gcc for ports on other archs? If it is clearly in a state to entirely replace gcc, then I say import it. But if it is not yet there, and won't be for some time, then I would say leave it out for the time and import it when it can. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 2010-05-31 16:49, Steve Kargl wrote: So, what exactly should we expect, if anything, to break? :) Did you build and install new boot code? ISTR that clang can't compile src/sys/boot/i386/boot0 to the required 512 bytes. No, boot0 is written in assembly, and run through the regular (GNU) assembler. Neither gcc nor clang do anything more except calling the linker. The only component (in the whole clangbsd src tree) which still needs to be compiled with gcc is boot2, which otherwise ends up just a little too big, and doesn't fit. This is being worked on, but it isn't very critical, really. Note that clangbsd automatically uses gcc for this specific code, unless you override it manually. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 05:07:44PM +0200, Dimitry Andric wrote: On 2010-05-31 16:49, Steve Kargl wrote: So, what exactly should we expect, if anything, to break? :) Did you build and install new boot code? ISTR that clang can't compile src/sys/boot/i386/boot0 to the required 512 bytes. No, boot0 is written in assembly, and run through the regular (GNU) assembler. Neither gcc nor clang do anything more except calling the linker. The only component (in the whole clangbsd src tree) which still needs to be compiled with gcc is boot2, which otherwise ends up just a little too big, and doesn't fit. This is being worked on, but it isn't very critical, really. Note that clangbsd automatically uses gcc for this specific code, unless you override it manually. Doesn't this imply that clang/llvm isn't quite ready for deployment. Being able to boot a complete clang/llvm compiled FreeBSD system would seem to be critical. When you say This is being worked on, do you mean clang/llvm is being changed to compile boot2 or do you mean boot2 is being changed to allow clang/lvvm to compile it? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 2010-05-31 17:18, Steve Kargl wrote: Doesn't this imply that clang/llvm isn't quite ready for deployment. Being able to boot a complete clang/llvm compiled FreeBSD system would seem to be critical. You can boot it just fine, only the boot2 part is compiled with gcc, for now. Clang can successfully compile boot2; the issue is that its 'optimize for size' option is not as good as gcc at the moment. At the same time, boot2 is so tight on space, that it misses out by just a few 100 bytes. When you say This is being worked on, do you mean clang/llvm is being changed to compile boot2 or do you mean boot2 is being changed to allow clang/lvvm to compile it? Clang/llvm is being fixed to produce small enough code to fit into the size limit that boot2 has (7 kiB IIRC); no ETA yet. The boot2 code itself should not have to be modified at all (although there might be ways to shrink that code too). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Doesn't this imply that clang/llvm isn't quite ready for deployment. Being able to boot a complete clang/llvm compiled FreeBSD system would seem to be critical. This is why clang would be turned off by default. This import is just making it easier to test the clangbsd branch. I'm all for this change (and when it happens I'll start testing clangbsd). -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/05/2010 16:03:07, Daniel Eischen wrote: Is clangBSD able to support all our architectures? Does it cross build for powerpc, mips, etc? Has it made a ports run and does it successfully build and run most of our ports on Tier-1 archs, and does it compare similarly with gcc for ports on other archs? Mostly agree, but waiting until clang can compile most of the ports is going to be a really long wait. Lots of projects out there won't want to support anything other than gcc for the forseable future. Presumably the import of clang to the base does not mean the immediate removal of gcc. Is it really such a bad thing to have gcc as a build-dependency for various ported applications? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwD3UsACgkQ8Mjk52CukIwCiACdGEn8qPpCoCnGN2u+E3S96BnQ mHAAnAy74w651EtuHf7bkWtjd9WSR/Ny =5QiA -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 9:49 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 31, 2010 at 02:49:35AM -0500, Brandon Gooch wrote: I'm running on a full ClangBSD system (world and kernel), and I've had no issues for the past couple of days. I've had the machine working nearly constantly -- building new and updating installed ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and generally using/abusing my computer by watching Flash video on the bsdconferences channel on YouTube... So, what exactly should we expect, if anything, to break? :) Did you build and install new boot code? ISTR that clang can't compile src/sys/boot/i386/boot0 to the required 512 bytes. No, I didn't install new boot code. Whether or not it was built, I'll check and see; I'm not sure exactly when/where it's built -- during buildkernel? This is an example of the reason I put the quotes around full -- I'm not sure exactly how completely ClangBSD my system really is :) -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 2010-05-31 at 02:49 -0500, Brandon Gooch wrote:
On Sat, May 29, 2010 at 8:02 AM, Roman Divacky rdiva...@freebsd.org wrote:
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to
import
into HEAD in roughly a week. We would like the initial import to be as
painless
as possible and therefore we ask you to test ClangBSD to assure that the
revision
we are importing does not have some really embarassing bugs.
How to do it (on i386 and amd64):
0) install fresh devel/llvm-devel port
1) svn co http://svn.freebsd.org/base/projects/clangbsd src
2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf
3) cd src make buildworld
4) make installworld DESTDIR=/usr/clangbsd
5) (optional) try to build kernel with clang and boot it
5.1) cd /sys/{arch}/conf
5.2) config YOUR_KERNEL
5.3) setenv CC clang in tcsh or export CC=clang in bash
5.4) cd ../compile/YOUR_KERNEL
5.5) make make install
please make sure that it builds (on amd64/i386) and that the resulting world
is runnable. ie. try to chroot into it and do stuff. ie.
chroot /clangbsd /bin/tcsh
... stuff ...
there's a wiki page on this effort:
http://wiki.freebsd.org/BuildingFreeBSDWithClang
please report back any problems/success to me and/or this mailing list.
thank you for your testing!
Roman Divacky on behalf of the ClangBSD team
I'm running on a full ClangBSD system (world and kernel), and I've
had no issues for the past couple of days. I've had the machine
working nearly constantly -- building new and updating installed
ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and
generally using/abusing my computer by watching Flash video on the
bsdconferences channel on YouTube...
What is the good way to do installworld from CURRENT-snapshot to
ClangBSD? Half way through some shared object (run-time loader?) gets
overwritten and it is all signal 11 from there on.
Thank you in advance.
--
Alexandre Kovalenko (Олександр Коваленко)
--
Ovi Mail: Available in 20 languages
http://mail.ovi.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 2010-05-31 19:44, Alexandre Sunny Kovalenko wrote:
What is the good way to do installworld from CURRENT-snapshot to
ClangBSD? Half way through some shared object (run-time loader?) gets
overwritten and it is all signal 11 from there on.
Hi Alexandre,
A fix for this has already been applied in head, but it was not yet
merged back to clangbsd. That is going to happen soon. In the
meantime, please:
- Use /rescue to rollback /libexec/ld-elf.so.1 (from the backup in
/libexec/ld-elf.so.1.old)
- Apply the patch I have attached to your clangbsd source dir
- Rebuild libexec/rtld-elf in there
Then you should be able to do installworld without any problems.
Index: libexec/rtld-elf/arm/reloc.c
===
--- libexec/rtld-elf/arm/reloc.c(revision 208620)
+++ libexec/rtld-elf/arm/reloc.c(working copy)
@@ -245,7 +245,6 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
const Elf_Rel *rellim;
const Elf_Rel *rel;
SymCache *cache;
- int bytes = obj-nchains * sizeof(SymCache);
int r = -1;
/* The relocation for the dynamic loader has already been done. */
@@ -255,10 +254,9 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
* The dynamic loader may be called from a thread, we have
* limited amounts of stack available so we cannot use alloca().
*/
- cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
- if (cache == MAP_FAILED)
- cache = NULL;
-
+ cache = calloc(obj-nchains, sizeof(SymCache));
+ /* No need to check for NULL here */
+
rellim = (const Elf_Rel *)((caddr_t)obj-rel + obj-relsize);
for (rel = obj-rel; rel rellim; rel++) {
if (reloc_nonplt_object(obj, rel, cache) 0)
@@ -266,9 +264,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
}
r = 0;
done:
- if (cache) {
- munmap(cache, bytes);
- }
+ if (cache != NULL)
+ free(cache);
return (r);
}
Index: libexec/rtld-elf/powerpc/reloc.c
===
--- libexec/rtld-elf/powerpc/reloc.c(revision 208620)
+++ libexec/rtld-elf/powerpc/reloc.c(working copy)
@@ -287,7 +287,6 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
const Elf_Rela *relalim;
const Elf_Rela *rela;
SymCache *cache;
- int bytes = obj-nchains * sizeof(SymCache);
int r = -1;
/*
@@ -295,10 +294,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
* limited amounts of stack available so we cannot use alloca().
*/
if (obj != obj_rtld) {
- cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON,
- -1, 0);
- if (cache == MAP_FAILED)
- cache = NULL;
+ cache = calloc(obj-nchains, sizeof(SymCache));
+ /* No need to check for NULL here */
} else
cache = NULL;
@@ -314,9 +311,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
}
r = 0;
done:
- if (cache) {
- munmap(cache, bytes);
- }
+ if (cache != NULL)
+ free(cache);
return (r);
}
Index: libexec/rtld-elf/sparc64/reloc.c
===
--- libexec/rtld-elf/sparc64/reloc.c(revision 208620)
+++ libexec/rtld-elf/sparc64/reloc.c(working copy)
@@ -254,7 +254,6 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
const Elf_Rela *relalim;
const Elf_Rela *rela;
SymCache *cache;
- int bytes = obj-nchains * sizeof(SymCache);
int r = -1;
/*
@@ -262,10 +261,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
* limited amounts of stack available so we cannot use alloca().
*/
if (obj != obj_rtld) {
- cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON,
- -1, 0);
- if (cache == MAP_FAILED)
- cache = NULL;
+ cache = calloc(obj-nchains, sizeof(SymCache));
+ /* No need to check for NULL here */
} else
cache = NULL;
@@ -276,8 +273,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
}
r = 0;
done:
- if (cache)
- munmap(cache, bytes);
+ if (cache != NULL)
+ free(cache);
return (r);
}
Index: libexec/rtld-elf/rtld.c
===
--- libexec/rtld-elf/rtld.c (revision 208620)
+++ libexec/rtld-elf/rtld.c (working copy)
@@ -3311,6 +3311,10 @@ allocate_module_tls(int index)
}
p = malloc(obj-tlssize);
+if (p == NULL) {
+ _rtld_error(Cannot allocate TLS block for index %d, index);
+ die();
+}
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Den 29/05/2010 kl. 15.02 skrev Roman Divacky: ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial import to be as painless as possible and therefore we ask you to test ClangBSD to assure that the revision we are importing does not have some really embarassing bugs. I've been running the stress2 test suite on ClangBSD (in a VirtualBox VM) for the last 48 hours with no crashes. I needed to pull in a couple of patches that have been committed to FreeBSD HEAD since the last merge with ClangBSD to avoid specific crashes, but now everything seems to work just fine. I do have a problem with buildworld on an unmodified ClangBSD src/ tree within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building it's own Lexer because it picks up the gcc version of the headers instead of the clang version. This has been fixed before in ClangBSD, but probably the logic to decide on which headers to use are insufficient. Thanks, Erik
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 2010-05-31 at 20:10 +0200, Dimitry Andric wrote: On 2010-05-31 19:44, Alexandre Sunny Kovalenko wrote: What is the good way to do installworld from CURRENT-snapshot to ClangBSD? Half way through some shared object (run-time loader?) gets overwritten and it is all signal 11 from there on. Hi Alexandre, A fix for this has already been applied in head, but it was not yet merged back to clangbsd. That is going to happen soon. In the meantime, please: - Use /rescue to rollback /libexec/ld-elf.so.1 (from the backup in /libexec/ld-elf.so.1.old) - Apply the patch I have attached to your clangbsd source dir - Rebuild libexec/rtld-elf in there Then you should be able to do installworld without any problems. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org That worked perfectly, thank you! If someone wants to host VirtualBox image of more-or-less fresh (yesterday + patch from Dimitry) clang-built system (1.1GB), please, contact me off the list. -- Alexandre Kovalenko (Олександр Коваленко) -- Ovi Mail: Create an account directly from your phone http://mail.ovi.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010 08:18:42 -0700 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 31, 2010 at 05:07:44PM +0200, Dimitry Andric wrote: On 2010-05-31 16:49, Steve Kargl wrote: So, what exactly should we expect, if anything, to break? :) Did you build and install new boot code? ISTR that clang can't compile src/sys/boot/i386/boot0 to the required 512 bytes. No, boot0 is written in assembly, and run through the regular (GNU) assembler. Neither gcc nor clang do anything more except calling the linker. The only component (in the whole clangbsd src tree) which still needs to be compiled with gcc is boot2, which otherwise ends up just a little too big, and doesn't fit. This is being worked on, but it isn't very critical, really. Note that clangbsd automatically uses gcc for this specific code, unless you override it manually. Doesn't this imply that clang/llvm isn't quite ready for deployment. Being able to boot a complete clang/llvm compiled FreeBSD system would seem to be critical. When you say This is being worked on, do you mean clang/llvm is being changed to compile boot2 or do you mean boot2 is being changed to allow clang/lvvm to compile it? FWIW, boot2 was a problem child for each and every GCC import on my memory. Every single major GCC release has claimed better optimizations and more compact generated code and yet they all inevitably generated code which was appreciably bigger than code produced by previus GCC version. This should not be used as an excuse to hold clang at bay, provided base src still comes with working way for building the working boot2 image (gcc). -- Alexander Kabaev signature.asc Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Sat, 2010-05-29 at 15:02 +0200, Roman Divacky wrote:
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to
import
into HEAD in roughly a week. We would like the initial import to be as
painless
as possible and therefore we ask you to test ClangBSD to assure that the
revision
we are importing does not have some really embarassing bugs.
How to do it (on i386 and amd64):
0) install fresh devel/llvm-devel port
1) svn co http://svn.freebsd.org/base/projects/clangbsd src
2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf
3) cd src make buildworld
4) make installworld DESTDIR=/usr/clangbsd
5) (optional) try to build kernel with clang and boot it
5.1) cd /sys/{arch}/conf
5.2) config YOUR_KERNEL
5.3) setenv CC clang in tcsh or export CC=clang in bash
5.4) cd ../compile/YOUR_KERNEL
5.5) make make install
please make sure that it builds (on amd64/i386) and that the resulting world
is runnable. ie. try to chroot into it and do stuff. ie.
chroot /clangbsd /bin/tcsh
... stuff ...
there's a wiki page on this effort:
http://wiki.freebsd.org/BuildingFreeBSDWithClang
please report back any problems/success to me and/or this mailing list.
thank you for your testing!
Roman Divacky on behalf of the ClangBSD team
Good people,
I have VirtualBox image of the ClangBSD (kernel + world i386) with the
clang installed, and Niclas generously offered to host it on his FTP
server. Image size (compressed) is slightly over 1GB.
Before we go through the hoops of moving image over, I am trying to see
whether there is sufficient interest in it. Would people, who are
interested, please, contact me off list -- if count tallies at about 10,
I will upload the image and Niclas will post URL here.
While I realize that moving target like ClangBSD, probably made this
image obsolete while I was building it, I think it will provide starting
point for those who want to test and/or experiment at the cost of
download.
Please, let me know.
--
Alexandre Kovalenko (Олександр Коваленко)
--
Ovi Mail: Easy setup in minutes
http://mail.ovi.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 4:34 AM, Roman Divacky rdiva...@freebsd.org wrote: there are no known clang bugs (at least known to me) related to FreeBSD in other words - at this point you can compile FreeBSD with clang (both in the version in clangbsd) and it works (for people who tested it) on amd64 and i386 I don't mean about FreeBSD, but about CLANG itself. It would be very depressing to loose many hours on kernel races before to discover it was a compiler deficiency, for example. thats what I mean - we are not aware of any bugs in clang itself that harm FreeBSD (on i386/amd64). btw. there are 68 open bug reports against gcc 4.2.1 in gcc bugzilla. Working with known deficiencies in a given system is much easier to deal with than unknown deficiencies in a new system. I think that's the point that several folks are trying to address. Unless there is a) sufficient testcases to exercise each piece of functionality, and/or b) enough soak time, you're playing a bit of a dangerous game with the unknown. I personally would much rather have the glue in place to switch between compilers and have things default to the base version of gcc than just magically switch the compiler over to clang. But I like my bikesheds painted gray. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Matthew Seaman wrote: Presumably the import of clang to the base does not mean the immediate removal of gcc. Of course not. I'm not part of core and don't know what they may have discussed, but I went through some hoops to replace 'tar' and 'cpio' in the base system and have some idea what approach we might take with clang: I would expect FreeBSD 9 to ship with both compilers, with gcc as the default for 'cc'. So users of 9-STABLE would see and use gcc unless they specifically chose to use clang. Even if we did decide to switch the default for FreeBSD 10, it's possible we would continue to install gcc as part of the base system (just not as 'cc'). So realistically, some form of gcc will be built and installed by default for a few more years. Beyond that, it depends partly on how well clang does and partly on how many problems we have with an increasingly out-of-date gcc. Cheers, Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 03:52:27PM -0700, Tim Kientzle wrote: Matthew Seaman wrote: Presumably the import of clang to the base does not mean the immediate removal of gcc. Of course not. I'm not part of core and don't know what they may have discussed, but I went through some hoops to replace 'tar' and 'cpio' in the base system and have some idea what approach we might take with clang: I would expect FreeBSD 9 to ship with both compilers, with gcc as the default for 'cc'. So users of 9-STABLE would see and use gcc unless they specifically chose to use clang. Even if we did decide to switch the default for FreeBSD 10, it's possible we would continue to install gcc as part of the base system (just not as 'cc'). So realistically, some form of gcc will be built and installed by default for a few more years. Beyond that, it depends partly on how well clang does and partly on how many problems we have with an increasingly out-of-date gcc. Exactly. We will need to take some risks here, but nuking gcc from the tree won't be one of them for a while. I just sent a link to current and arch with links to the toolchain summit wiki page and a summary of the results. I encorage interested parties to read what is there and provide constructive suggestions. -- Brooks pgpNPnYqRDglF.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 3:44 PM, Garrett Cooper yanef...@gmail.com wrote: I personally would much rather have the glue in place to switch between compilers and have things default to the base version of gcc than just magically switch the compiler over to clang. From all the threads I've read on this subject, that's exactly what is planned: - import clang into the source tree - add knobs to select which compiler to use - leave GCC as the default compiler IOW, unless you actually want to test clang and set the appropriate knobs, then nothing will change for you. Everything works as per normal. I really don't see what the big deal is, or why everyone is getting their knickers in a knot over this. GCC isn't being removed from the tree. GCC is staying the default compiler. The sky is not falling. If you want to test clang, you can. If you don't want to test clang, you aren't forced to in any way, shape, or form. It's really no different from the processes used when adding libthread alongside libkse, or add sched_ule alongside sched_bsd. The defaults didn't change, both were available, and everyone carried on without issues while those motivated to test the new bits did so. Eventually, enough bugs were found and fixed, things stabilised, and the new bits became the default. Similar process here. I may be only a lowly user and occasional tested of new bits, but I really don't understand the mountain people are making of this ant hill. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Scott Long wrote: Sounds like you're inviting the discussion right now. I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. Without that political weapon FreeBSD would not have the rich userland it has today. It may not be as important any more but it sure surely was in the '80s into the early '90s. As for the problems with gcc, you have to understand the history. I was the x86 maintainer for a few years, yet by the time of my involvement around 1990 the basic architecture had already been set around the MC68000 with the question being whether Alpha, MIPS or etc would be the future - nobody expected x86 to be viable for much longer and the goal was widely-retargetable at least until things settled out. The x86 did not meet gcc's minimum processor requirements and required hacks to work at all. Had it not been for RMS's insistence x86 might have been deprecated. The other key issue was how little manpower was available. There was only one person paid to do gcc work - if you call RMS's activist wages paid - and the volunteers worked out of whatever spare time they had. I already had an 80 hour/week job *before* volunteering and I think that was not unusual. As a result design decisions were strongly tilted in favor of maintainability over performance. A lot of good code donations were rejected because we simply could not afford to maintain it. I think I accepted only one significant code donation for x86 because of that (the 387 reg-stack code). If someone is willing to do a clean-sheet design around the realities and manpower of 2010 instead of 1988 that's a good thing. I do suggest modifying the FreeBSD build process so that uname -a shows the compiler and its version for both the kernel and userland. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 06/01/10 09:25, James R. Van Artsdalen wrote: [snip interesting history] I do suggest modifying the FreeBSD build process so that uname -a shows the compiler and its version for both the kernel and userland. Reading through this discussion, I wanted to draw attention to this footnote in James' email. It sounds like a sensible and useful suggestion that would go some way to addressing Kostik's concerns about knowing whether a kernel bug report was related to a gcc or clang built kernel. Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 05/31/10 17:46, Lawrence Stewart wrote: On 06/01/10 09:25, James R. Van Artsdalen wrote: [snip interesting history] I do suggest modifying the FreeBSD build process so that uname -a shows the compiler and its version for both the kernel and userland. Reading through this discussion, I wanted to draw attention to this footnote in James' email. It sounds like a sensible and useful suggestion that would go some way to addressing Kostik's concerns about knowing whether a kernel bug report was related to a gcc or clang built kernel. +1 -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 7:51 PM, Doug Barton do...@freebsd.org wrote: On 05/31/10 17:46, Lawrence Stewart wrote: On 06/01/10 09:25, James R. Van Artsdalen wrote: [snip interesting history] I do suggest modifying the FreeBSD build process so that uname -a shows the compiler and its version for both the kernel and userland. Reading through this discussion, I wanted to draw attention to this footnote in James' email. It sounds like a sensible and useful suggestion that would go some way to addressing Kostik's concerns about knowing whether a kernel bug report was related to a gcc or clang built kernel. +1 I doubt there's anyone that would disagree with this. The only thing that would be painful is if there were mixed compiles with applications and triage, but if that was the case the user should debug their own issue because they'd be mixing and matching toolchains :/... Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 31 May 2010 17:01:15 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: Is it really such a bad thing to have gcc as a build-dependency for various ported applications? There are already ports that have gcc-4.4.4 as a dependency, and a few that still require gcc-3.4.6. [on my system, that's : ffmpeg-0.5.1_3,1 gegl-0.1.2_1 gimp-app-2.6.8_3,1 ufraw-0.16_3 x264-0.0.20100222_1 xsane-0.996_3 blas-1.0_4 lapack-3.2.1_1 py26-numpy-1.4.1,1 totem-2.30.1 vinagre-2.30.1 vino-2.28.2 and ...hmm... maybe I've already de-installed whatever was depending on 3.4.6...] Anyway, I don't see this trend slowing down any time soon, so I don't think that being able to compile all of ports is a reasonable constraint on bringing clang into the tree. I've changed my mind about bringing things into the tree since my last post on the subject. Being in-tree helps a lot with the ability to cross-build, which matters now that reasonably priced beasty machines are so much faster than reasonably-priced puny machines. Also, I've learned to love tmux... Also, the ability to have NO_LLVM in make.conf should (just like the other, similar switches) answer the rebuild-time issue. Just a few cents from the peanut gallery. FWIW I'm in favour, but I do understand Kostik's concern. I've been bitten by my share of compiler bugs and hardware bugs. Perhaps, even for a while after introduction, there should be a rule like don't report a bug unless you've reproduced it on a system built with cc(=gcc), just to keep those two issues separate. Perhaps with a side order of: any bug that you find in a clang-compiled system that goes away when re-built with gcc should be reported to the clang folk... Cheers, - -- Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwEklYACgkQgzZZe5eEKMIf4ACffE00q3RsyElRE64q3tOFovI8 Dh0An2tQLYwVc74tvXJD72bbsul0j68V =oTaO -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, Jun 01, 2010 at 02:53:22PM +1000, Andrew Reilly wrote: On Mon, 31 May 2010 17:01:15 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: Is it really such a bad thing to have gcc as a build-dependency for various ported applications? There are already ports that have gcc-4.4.4 as a dependency, and a few that still require gcc-3.4.6. [on my system, that's : ffmpeg-0.5.1_3,1 gegl-0.1.2_1 gimp-app-2.6.8_3,1 ufraw-0.16_3 x264-0.0.20100222_1 xsane-0.996_3 blas-1.0_4 lapack-3.2.1_1 Well, blas and lapack require gcc-4.4.4 because these are implemented in Fortran. Fortran was removed from FreeBSD's base several years ago. Note, also that clang/llvm can't compile these libraries so the dependencies won't disappear anytime soon. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. pgpJZiiTtKZST.pgp Description: PGP signature
