2010/5/31 Roman Divacky <rdivacky_at_freebsd.org>: > On Mon, May 31, 2010 at 12:54:29PM +0200, Attilio Rao wrote: >> 2010/5/31 Kostik Belousov <kostikbel_at_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_at_ or current_at_ 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 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. Attilio -- Peace can only be achieved by understanding - A. EinsteinReceived on Mon May 31 2010 - 09:30:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC