Re: GCC withdraw
On Thu, Aug 29, 2013 at 06:02:06PM +0100, David Chisnall wrote: rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). And committers need to learn that Devsummit discussions (and optional wiki's) are just like IRC ones -- we're all not there. But we're on the mailing lists. That's how we communicate far-and-wide. John and others bring up really good points. Until GCC is no longer used to build FreeBSD on any platform it should remain in all platforms. If part of your reasoning is to free up gcc and g++ commands for ports -- fine, but change the names /usr/bin/gcc and /usr/bin/g++ on all platforms for something else. /usr/bin/fbsd-gcc /usr/bin/fbsd-g++ or what not. -- -- David (obr...@freebsd.org) ___ 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: GCC withdraw
On 1 Sep 2013, at 02:53, Benjamin Kaduk ka...@mit.edu wrote: I am worried about the definition of polished. I held my tongue in Ottawa in 2011 when Kirk wanted to turn SU+J on by default, since I figured he knew what was going on much better than I did. Then, we discovered the bad interactions between SU+J and snapshots. If memory serves, things like sparc64 and mips64 support for clang/llvm and XCC suppor are being described as only a few man-months work away. But that seems to be just to get something which is working ... I fear that to get it truly polished will be another 2-3 years on top of those man-months. If we are in agreement about what polished means, then by all means announce with 10.0 that gcc's days are numbered and drop it at the appropriate 10.x. I just don't want us to discover terrible bugs a few months after we make a switch, due to being wrong about polished. We are using XCC to build FreeBSD today, on x86 with experimental tools and on MIPS with the compiler in base. It works, but it could do with better documentation. That's what I mean by polishing: making sure that it doesn't just work, it works and is easy to use. Part of this will involve ensuring that we have packages for cross compilers for various platforms so that it's really easy to just install a package with the cross toolchain you want and point your already-installed source tree at it to get a cross-build environment. Many of us have been running clang-is-cc for a long time and we're now seeing more port build failures on 10-with-gcc than 10-without-gcc. That's what I mean by polished. The SPARC back end in LLVM is marked as experimental. Looking over the code, it's actually in a better state than I thought it would be. Some people seem to be working on it. It's not something I would count on getting to a useable state though. If SPARC is to remain a supported architecture, then we'll probably be using an external toolchain for it, unless someone wants to spend a couple of months chasing bugs in the LLVM SPARC back end. Oracle seems to be being quite effective at killing SPARC64 as an architecture for running anything other than Oracle appliances, but SPARC32 is still quite popular in aerospace so it may still be an interesting platform in a few years. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On Fri, Aug 30, 2013 at 10:41:18AM -0400, John Baldwin wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. If this is the case, IMHO: - it's a decision to be made by the project as a whole, not just one individual; - if the decision is made, there should be one major release cycle before it's done; - our userbase (admittedly small) should have a heads-up that they will have to migrate after that timeframe. fwiw, unlike alpha, which was withdrawn because it had ceased to function, sparc64 and ia64 work and have active developer(s), so I don't think it would be entirely fair to cite its removal as a precedent. tl;dr: just because you don't use these boxes doesn't mean others don't. 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: GCC withdraw
On 1 Sep 2013, at 19:03, Mark Linimon lini...@lonesome.com wrote: If this is the case, IMHO: I was going to quote the whole mail, but actually this is enough. As I have already said in this thread, there is no such plan. I repeat, for those who missed it the first time: On 30 Aug 2013, at 16:11, David Chisnall thera...@freebsd.org wrote: I am not proposing: ... - To deprecate any architectures - To break any architectures If a platform ends up without a working toolchain in a few years and there is no way (LLVM, recent GCC, heavily patched old GCC, vendor-supplied toolchain) of building it, then we will have to make the decision about its future. Whether that means getting the Foundation and / or some other interested body to pay for someone to work on a toolchain or dropping support is an issue for stakeholders in the platform. We will probably have to make this call about at least IA64 in a couple of years, and possibly some PowerPC and SPARC variants, but it's not a decision that needs to be made any time soon. I know SemiHalf does a lot of embedded FreeBSD work with PowerPC and a few people do with SPARC, so there are definitely people with vested interests in maintaining those two platforms. I'd honestly be surprised if IA64 is around in two years (mind you, I've been expecting it to die for the last five, so I'm willing to be surprised again), but maybe there will be a lot of cheap second-hand IA64 hardware on the market as all of the big customers switch to something else reviving interest in the platform... David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On Sep 1, 2013, at 12:03 PM, Mark Linimon wrote: On Fri, Aug 30, 2013 at 10:41:18AM -0400, John Baldwin wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. If this is the case, IMHO: - it's a decision to be made by the project as a whole, not just one individual; - if the decision is made, there should be one major release cycle before it's done; - our userbase (admittedly small) should have a heads-up that they will have to migrate after that timeframe. fwiw, unlike alpha, which was withdrawn because it had ceased to function, sparc64 and ia64 work and have active developer(s), so I don't think it would be entirely fair to cite its removal as a precedent. tl;dr: just because you don't use these boxes doesn't mean others don't. I'm working on a set of ports that can be installed so you can use the external toolchain support in the tree... But it is being a pain since there turns out to be some unexpected interdependencies and ordering that's tricky to get right. But this does mean I've extracted the FreeBSD specific changes into a series of patches... Warner ___ 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: GCC withdraw
John Baldwin wrote this message on Fri, Aug 30, 2013 at 10:41 -0400: So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? Why didn't this come up when John added XSAVE (a year ago) or Pedro Giffuni added amdfam10 support (3 months ago)? Plus, I've sent other patches earlier this year to -toolchain and made clear why I was adding them... Had I known that the policy was gcc was dead for HEAD (which btw, I was told multiple times that we were keeping gcc for 10 for i386/amd64), I would have just committed my kernel changes by now, but didn't want to break a (what I thought was) supported configuration... We need to communicate better on issues like these, since this isn't the first time one group of people made a decision w/o telling the rest of the community... For major items like this, we need to make sure the road map is published, either on www.freebsd.org or on the wiki and gets kept up to date... For example, the release schedule for 10 wasn't posted till over a week after the code slush was announced (which caught people, like myself, by surprise)... That's kinda the wrong order to do it in, the schedule should be posted well in advance so people know what to expect... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: GCC withdraw
On 31 Aug 2013, at 08:33, John-Mark Gurney j...@funkthat.com wrote: Why didn't this come up when John added XSAVE (a year ago) or Pedro Giffuni added amdfam10 support (3 months ago)? Plus, I've sent other patches earlier this year to -toolchain and made clear why I was adding them... Had I known that the policy was gcc was dead for HEAD (which btw, I was told multiple times that we were keeping gcc for 10 for i386/amd64), I would have just committed my kernel changes by now, but didn't want to break a (what I thought was) supported configuration... gcc is not dead for 10.0, we're simply wanting to not ship it in binary form by default. There is a BIG difference between saying 'if you want gcc then you must explicitly opt in and build it yourself and it may not be there for the entire 10.x series' and saying 'gcc is gone now, don't expect any of FreeBSD to build with it'. We are absolutely not proposing the latter for 10.0. We still expect the 10.0 kernel and most of the userland (libc++ excepted) to build with gcc. We expect this to be true for 10.1, and probably 10.2, possibly even 10.3. I'd probably expect that at least the kernel will build with gcc 4.2.1 for the entire timeframe. Some modules may not, although for ease of debugging compiler bugs I'd recommend that if they don't build with gcc 4.2.1 then at least they build with upstream gcc. However, we want to be able to make it unsupported at some point in the 10.x series when there is a polished alternative for every supported architecture (either when they've moved to clang or when the XCC stuff is fully documented in the handbook and tested in a large variety of configurations and once our forked binutils and is available as a package and we have cross-gcc that uses it). If this doesn't happen by the time 10.x is EOL'd then I'll be sad, but we still have the fall-back position of gcc in base for the entire 10.x. If it does happen, then we can start more aggressively phasing out gcc in the base system. We need to communicate better on issues like these, since this isn't the first time one group of people made a decision w/o telling the rest of the community... For major items like this, we need to make sure the road map is published, either on www.freebsd.org or on the wiki and gets kept up to date... I agree. This is why I made sure that at the BSDCam DevSummit all of the sessions had someone who was taking notes for their sessions on the wiki: https://wiki.freebsd.org/201308DevSummit#Schedule-1 (Well, except, somewhat ironically, the docs team, who still haven't put their notes on the wiki) It's also why I've taken charge of putting out special status reports for each DevSummit for wider public consumption, like this one: http://www.freebsd.org/news/status/report-2013-05-devsummit.html I'd be interested in hearing any more suggestions about how we can improve this. For example, the release schedule for 10 wasn't posted till over a week after the code slush was announced (which caught people, like myself, by surprise)... That's kinda the wrong order to do it in, the schedule should be posted well in advance so people know what to expect... This one you'll have to discuss with re@. I think that after 10.0 there will be some more discussion about our release policy. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
Sorry for adding to the long thread. On Sat, 31 Aug 2013, David Chisnall wrote: However, we want to be able to make it unsupported at some point in the 10.x series when there is a polished alternative for every supported architecture (either when they've moved to clang or when the XCC stuff I am worried about the definition of polished. I held my tongue in Ottawa in 2011 when Kirk wanted to turn SU+J on by default, since I figured he knew what was going on much better than I did. Then, we discovered the bad interactions between SU+J and snapshots. If memory serves, things like sparc64 and mips64 support for clang/llvm and XCC suppor are being described as only a few man-months work away. But that seems to be just to get something which is working ... I fear that to get it truly polished will be another 2-3 years on top of those man-months. If we are in agreement about what polished means, then by all means announce with 10.0 that gcc's days are numbered and drop it at the appropriate 10.x. I just don't want us to discover terrible bugs a few months after we make a switch, due to being wrong about polished. -Ben is fully documented in the handbook and tested in a large variety of configurations and once our forked binutils and is available as a package and we have cross-gcc that uses it). If this doesn't happen by the time 10.x is EOL'd then I'll be sad, but we still have the fall-back position of gcc in base for the entire 10.x. If it does happen, then we can start more aggressively phasing out gcc in the base system. ___ 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: GCC withdraw
On 8/30/13 1:02 AM, David Chisnall wrote: On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports. According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed. Our gcc does not support the ARM EABI hard float variant. I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float. This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers. This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications.
Re: GCC withdraw
On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: How does removing GCC from base change this? I already deal with having 3 different GCC versions at work by building them from ports and building things with the right rpath, etc. so I am familiar with this, and having GCC in the base doesn't make that problem any worse. In fact, I'd argue that this is an argument for not shipping an STL in the base system at all (though I'd be loathe to do that) if it is an argument for disabling GCC. It means that you don't need to patch configure scripts to tell them to ignore gcc even if they find it. Please talk to port maintainers about the amount of effort that they're being forced to put into this. They'll still have to keep doing this until 9.x is EOL'd, but it would be nice if they could then stop, rather than having to wait for 10.x to also be EOL'd. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Strictly speaking you do not have to modify it in all cases. The recent change to make it work with log10 does not appear to have been a requirement to fix anything (at least judging from the log message). There does seem to have been about 10 changes to libstdc++ in the past year, though a few were 2-3 line changes in config.h which isn't but so earth-shattering. And each libc change that exposes anything that is used by libstdc++ goes through the same cycle: - Commit - Wait for bug reports - Spend a few hours trying to work out why C++ programs are failing to run or compile in odd ways - Commit a libstdc++ fix And, once again, the people who are advocating for gcc to remain in the default install are not the ones doing this work. Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. If we remove it from the default install now, users don't expect it to keep working for the lifetime of the 10.x branch. If we leave it in, then they do. If tier-2 architectures are still using it for 10.0, that's fine, because users of tier-2 architectures don't expect everything to remain stable over the span of a release. ARM is technically Tier-2, but for the purpose of this I'm including modern ARM platforms (i.e. things like the Efika and Raspberry Pi, where we hope to get re@-supported images soon - by 10.1 if not by 10.0), but ARM EABI Hard-Float (the platform in question) is already supported by clang and so has the same level of support as x86. So let's be absolutely clear what we mean by non-x86: - Old ARM (ARMv4/ARMv5), most commonly used in microcontrollers which don't have the power to run a full base system or arbitrary ports anyway. - MIPS, which is a few months of effort in LLVM to get completely working. LLVM on MIPS is already self-hosting and I'm currently chasing the remaining issues. We are planning on releasing an open source MIPS64 implementation soon, and gcc will be the system compiler for the first release, but we'll be switching to clang very soon for that - long before 10.x goes EOL. MIPS has other serious issues (for example, gdb doesn't work at all - it can't even find the memory regions that contain the binary) and our ld is too old to support several of the GOT-related optimisations required to build large programs, so gcc is the least of its concerns, toolchain-wise. The MIPS binutils changes have not been upstreamed, so this is somewhat problematic as we don't have any useable toolchains for MIPS64, including gcc in base, for moderately-sized applications. This should be addressed some time over the next 6-12 months by switching MIPS over to LLVM / MCLinker. MIPS is perhaps the m ost important one because the new owners of MIPS are investing in LLVM quite heavily (they've been ramping up their LLVM development a lot over the last year even before the
Re: GCC withdraw
On 30 Aug 2013, at 08:18, Julian Elischer jul...@freebsd.org wrote: As far as I'm concerned we can even slate it for possible removal in 10.2-- if clang has proven up to the task I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). David ___ 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: GCC withdraw
On Friday, 30 August 2013 at 08:35, David Chisnall wrote: I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. I don't see how that's very different from requiring a gcc/g++ package. Jon -- Jonathan Anderson jonat...@freebsd.org ___ 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: GCC withdraw
On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will have to install a libstdc++ package. People wanting to build base with g++ will still have to explicitly enable the build of libstdc++, yes. That's only really an issue for 10.0 though, because in 10.1 we won't be able to build clang (or lldb) with either g++ from base or our libstdc++ from base, as both use C++11 features. David ___ 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: GCC withdraw
I've been reading this thread and must confess that I'm a little confused about what exactly is being discussed. * I presume we've all agreed that clang is installed by default in FreeBSD-10. * I presume everyone agrees that cc is clang in FreeBSD-10. * There obviously needs to be a gcc command in FreeBSD-10, since cc and gcc are synonyms in so many people's finger-memory. Is the debate here just a question of whether gcc is clang or the *real* GCC? Would it be feasible to install GCC as gcc42 or something similar so people could still reach it regardless of what the gcc alias pointed to? On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: ... then people wanting to compile the base system with gcc/g++ ... I'm still curious *why* some people want this? Personally, I would rather compile the base system with the *supported* compiler. Today, on FreeBSD-CURRENT/x86 and FreeBSD-CURRENT/amd64, that is clang. On Aug 30, 2013, at 12:18 AM, Julian Elischer jul...@freebsd.org wrote: Clang is new. clang WILL HAVE BUGS. Based on my own experience, I would put this rather differently: GCC and Clang are COMPILERS. Therefore, they have DIFFERENT BUGS. This is why I worry about having cc and gcc be different compilers. 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: GCC withdraw
I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. Warner ___ 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: GCC withdraw
On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. Warner Actually, I have to put a +1 on this. I also had a long reply full of reality-based refutations of various facts from this thread, and I also just deleted it because clearly the discussion has become pointless. -- Ian ___ 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: GCC withdraw
30.08.2013 11:33, David Chisnall пишет: The time to raise objections for this was when the plan was originally raised over a year ago David, can you please point me to the original plan with gcc removal at 10.x? (I do remember only a plan to make clang the default compiler, but I may be wrong here) Thanks. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: GCC withdraw
On 08/30/13 00:35, David Chisnall wrote: On 30 Aug 2013, at 08:18, Julian Elischer jul...@freebsd.org wrote: As far as I'm concerned we can even slate it for possible removal in 10.2-- if clang has proven up to the task I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. -Nathan ___ 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: GCC withdraw
On 30 Aug 2013, at 15:41, John Baldwin j...@freebsd.org wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. I expect that platforms that don't have support from clang or some external toolchain will die. If people care about IA64, then getting Intel's compiler working as an external toolchain would probably be a good idea (it generates vastly better code than gcc). If people care about SPARC64, then either gcc from ports as an external toolchain, or finishing up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back end is not that much effort (it's probably a couple of person-months of work - getting the calling conventions right does require some small tweaks to LLVM IR that I think someone's working on), but it hasn't been done because no one appears to care quite enough to make it a priority. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the impression that this was widespread common knowledge and something I've personally discussed with various people including ports people on several occasions. I would have made the commit a couple of months ago, but getting the ports infrastructure back up to a state where it's easy to test has been a blocker there. If removing gcc from the standard install is going to cause major pain for people, then we can leave it in for 10.0. I'm currently doing a make tinderbox on the removal patch, modified to leave gcc in, and only remove libstdc++, which is something that we definitely need to do because it's causing an amount of pain that is only going to increase. I have no plans to make anything in the base system (other than clang itself, when 3.4 is imported) depend on libc++-only features (I'd love to do it for dtc, but it has to run on embedded platforms that are going to be stuck with libstdc++ in base for a while - at least a year, and that's if we're lucky). Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system compiler - On platforms where clang is not cc, leave libstdc++ as the default system STL, but encourage ports to start depending explicitly on ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then you are free to install it, clang will still use it if you specify -stdlib=libstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you will see no difference. If you need to test whether building the base system or kernel with gcc fixes things that are broken, then you
Re: GCC withdraw
On 30 Aug 2013, at 15:53, Nathan Whitehorn nwhiteh...@freebsd.org wrote: So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. If we can make our g++ compile C++11 code, then we can compile libc++ with g++. This support requires significant modifications to the parser (it adds a second Turing-complete compile-time language, for one...) and so retrofitting C++11 support to g++ 4.2.1 is not going to happen. It's taken upstream gcc a couple of years to get to the required level of support. We don't have the manpower to replicate this. David ___ 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: GCC withdraw
Only a few comments in reply to avoid banging my head against a brick wall and then I'm done: On Friday, August 30, 2013 3:33:21 am David Chisnall wrote: On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. [snip] So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@ and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? -- 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: GCC withdraw
On Fri, Aug 30, 2013 at 6:47 AM, Ian Lepore i...@freebsd.org wrote: On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote: I had a long, rambling reply to this that corrected many of the factual errors made in it. But why bother. You have your world view, it doesn't match what people are doing today and this mismatch is going to cause people pain and suffering in the embedded world far beyond what you think. And you've shown an extreme reluctance to accept that your world view isn't quite right, and listen to people. This makes me sad, but I recognize a lost cause when I see it. Do whatever the fuck you want, but it won't make your arguments right. And it won't keep me from saying I told you so when your optimistic timelines don't come to fruition, or the people processors you dismiss as being too weak to run a full FreeBSD (despite the fact they are doing it today) complain about the needless pain they are going through. Warner Actually, I have to put a +1 on this. I also had a long reply full of reality-based refutations of various facts from this thread, and I also just deleted it because clearly the discussion has become pointless. I don't really have any skin in this game; the vendor I work for uses x86 hardware, and we're not ready to be running on FreeBSD 10 yet. But as an old guy I really don't see why we'd change the plan of record so late. Nor do I think prioritizing ports over the base system on alternate architectures is the right play -- there's a lot of vendors who use FreeBSD on !x86. And there's a lot of vendors who don't use very many ports. And there's a lot of vendors putting money into the FreeBSD foundation, and into the hands of FreeBSD committers, to make it better. Vendors who, while it would be painful to switch, do have a choice of which OS to build their product around. Just my 2c. Actual value may differ. Cheers, matthew ___ 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: GCC withdraw
On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote: On 29 Aug 2013, at 18:44, John Baldwin j...@freebsd.org wrote: default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC to build. :) Not really. Clang + gcc takes longer to build than just clang. Building gcc is in the noise. I've sent you number on this. John is correct. It takes much much longer to buildworld with clang. -- 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: GCC withdraw
On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall thera...@freebsd.orgwrote: On 30 Aug 2013, at 15:41, John Baldwin j...@freebsd.org wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen that goal discussed publically. I expect that platforms that don't have support from clang or some external toolchain will die. If people care about IA64, then getting Intel's compiler working as an external toolchain would probably be a good idea (it generates vastly better code than gcc). If people care about SPARC64, then either gcc from ports as an external toolchain, or finishing up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back end is not that much effort (it's probably a couple of person-months of work - getting the calling conventions right does require some small tweaks to LLVM IR that I think someone's working on), but it hasn't been done because no one appears to care quite enough to make it a priority. Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked the relevant ports so that everything is built with clang. I would also love to be able to build the base system with GCC 47 instead of 42, it just doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally raised over a year ago, or at any of the points when it's been discussed in between. It is not after we're ready to flip the switch. So I think the crux of the issue might be this: I have no doubt that this has been discussed extensively on toolchain@and in toolchain-specific devsummit sessions. The proposal to disable GCC by default does not appear to have been discussed in a wider audience from what I can tell. (I can't find any relevant threads on arch@ or current@ prior to this one.) While this is a toolchain-specific decision, it is a very broad decision. Also, we aren't here because of a new thread started intentionally to say Hey, we as the toolchain folks think we should disable GCC by default on 10 for x86. Instead, we started off in a thread about adding AES instructions to our binutils and out of left field there is an e-mail of Oh, don't bother cause I'm disabling GCC next week (paraphrase). Can you appreciate at all that this is a total surprise to people who aren't subscribed to toolchain@ and haven't been to a toolchain session at a devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the impression that this was widespread common knowledge and something I've personally discussed with various people including ports people on several occasions. I would have made the commit a couple of months ago, but getting the ports infrastructure back up to a state where it's easy to test has been a blocker there. If removing gcc from the standard install is going to cause major pain for people, then we can leave it in for 10.0. I'm currently doing a make tinderbox on the removal patch, modified to leave gcc in, and only remove libstdc++, which is something that we definitely need to do because it's causing an amount of pain that is only going to increase. I have no plans to make anything in the base system (other than clang itself, when 3.4 is imported) depend on libc++-only features (I'd love to do it for dtc, but it has to run on embedded platforms that are going to be stuck with libstdc++ in base for a while - at least a year, and that's if we're lucky). Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system compiler - On platforms where clang is not cc, leave libstdc++ as the default system STL, but encourage ports to start depending explicitly on ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then you are free to install it, clang will still use it if you specify -stdlib=libstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you will see no
Re: GCC withdraw
On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote: On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: ... then people wanting to compile the base system with gcc/g++ ... I'm still curious *why* some people want this? Buildworld completes in 1/4th the amount of time with gcc and it consumes much less memory. -- 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: GCC withdraw
Subject: Re: GCC withdraw From: Warner Losh i...@bsdimp.com Date: Thu, 29 Aug 2013 10:00:19 -0600 Gcc is still an absolute requirement on all non-x86 platforms (including arm) due to the issues with clang. Some of these issues are bugs in specific things (arm) that keep coming up (and keep getting fixed), while others are more severe (sparc64 has no clang support, and don't forget ia64 Anton ___ 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: GCC withdraw
On Fri, Aug 30, 2013 at 04:11:08PM +0100, David Chisnall wrote: Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) And remember about breaking firewire+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: GCC withdraw
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? This is a red herring and I'd wish you'd stop bringing it up constantly. GCC has not needed constant care and feeding in the 7.x/8.x/9.x branches and it won't need it in 10.x either. I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. -- 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: GCC withdraw
On Aug 29, 2013, at 8:57 AM, John Baldwin wrote: On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote: On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? This is a red herring and I'd wish you'd stop bringing it up constantly. GCC has not needed constant care and feeding in the 7.x/8.x/9.x branches and it won't need it in 10.x either. I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. Agreed. Gcc is still an absolute requirement on all non-x86 platforms (including arm) due to the issues with clang. Some of these issues are bugs in specific things (arm) that keep coming up (and keep getting fixed), while others are more severe (sparc64 has no clang support, and no way to generate a self-hosting system in the absence of a bootstrap gcc in the base, even with the external toolchain support). gcc will absolutely be in the base for 10. That's the long-standing agreement that we've had, and breaking it now at the 11th hour is going to totally screw up !x86 platforms and really piss off a lot of developers for no good reason. The time is long since past to change this plan. This is the plan of record, and we need to stick to it: 10: clang default, where possible, gcc in base otherwise 11: clang default, full external toolchain support, including self-hosting So the time for voting and carping has long since past. Warner ___ 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: GCC withdraw
On Aug 25, 2013, at 8:21 AM, Ian Lepore wrote: On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ David And THIS is a major reason why FreeBSD needs a compiler in base instead of all tools being ports. The last thing we need is to start responding to every problem with this is not my problem, go file a report upstream. If we're already doing it for the compiler that's supposed to be the new supported tool, how much worse will peoples' experience be when we assert no ownership or responsibility for a toolchain at all? Especially when the external toolchain support is far from well integrated, is lacking key features and needs much documentation on what is there. One of the huge draws to FreeBSD is that you don't have to play whack-a-mole with gcc/binutils/libc/etc. I'd sure hate to lose that. Warner ___ 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: GCC withdraw
On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports. According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed. Our gcc does not support the ARM EABI hard float variant. I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float. This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers. This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications. We want to start shipping
Re: GCC withdraw
On Aug 29, 2013, at 11:02 AM, David Chisnall wrote: On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway. Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. True, but this doesn't cause any problems for gcc, just g++. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Fair enough, but the number of these has been, to date, quite small. Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. It actually is close to zero effort. The effort level is quite small, as evidence by the small number of commits to gcc over time. Not zero, but not as huge a deal as you make it out to be. However, we still need to make the efforts so long as it is part of the base. Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. This is a legitimate issue, for g++, not for gcc. But on !x86 targets we'll need to continue to do this. When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Seems more like an issue for 11 not 10. Also, we need to be able to bootstrap the base tools with gcc, since that's been the fallback bootstrap method for some time for people upgrading from really old systems: build the system with clang disabled the first time, and then use that to bootstrap clang since the gcc there can build it. I'd hate to loose this fallback plan, but do recognize at some point we must. Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work
Re: GCC withdraw
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote: On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. How does removing GCC from base change this? I already deal with having 3 different GCC versions at work by building them from ports and building things with the right rpath, etc. so I am familiar with this, and having GCC in the base doesn't make that problem any worse. In fact, I'd argue that this is an argument for not shipping an STL in the base system at all (though I'd be loathe to do that) if it is an argument for disabling GCC. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Strictly speaking you do not have to modify it in all cases. The recent change to make it work with log10 does not appear to have been a requirement to fix anything (at least judging from the log message). There does seem to have been about 10 changes to libstdc++ in the past year, though a few were 2-3 line changes in config.h which isn't but so earth-shattering. Also, unless you plan on desupporting all non-x86 platforms, you _still_ have to do all this work while those platforms require GCC anyway. Just turning off GCC on x86 doesn't change this problem one iota. And that point is actually relevant to many of the other concerns you raised. It's not at all clear what disabling GCC on x86 will buy you unless you are intending on short-changing support for GCC on non-x86. Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine- dependent code on these architecture. The new instructions (and I've added some) go into binutils, not gcc per se. Even the ARM ABI changes only touched Makefiles and one config header in contrib/gcc, not actual code changes. The code changes in contrib/gcc to add more AMD instrinics were done because someone felt like doing it, not because it was a requirement or blocking issue for someone. When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Eh, it sounds like if you have to force them to use clang for 9.x bootstrapping that also solves your problem in 10, so it's the same amount of work either way. Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system. Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that... This is your worst argument as clang is known to take far longer than GCC to build. :) I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports. I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt. I posit that it only saves you work if you short-change non-x86 platforms, and that this will be harder to detect without gcc built on x86. I do
Re: GCC withdraw
On 24 Aug 2013, at 16:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same problem. -- Rui Paulo ___ 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: GCC withdraw
On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: On 24 Aug 2013, at 16:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html ___ 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: GCC withdraw
On 25 Aug 2013, at 00:24, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: On 24 Aug 2013, at 16:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html Have you tried submitting that directly to mplayer? -- Rui Paulo ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the issue was fixed by updating the port to a more recent version. Mplayer is currently mplayer-1.1.r20130308, do you still see the same issues with clang? -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. ___ 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: GCC withdraw
On Sun, Aug 25, 2013 at 02:23:54AM -0500, Scot Hetzel wrote:
On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote:
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
don't understand inlined asm.
Clang supports inline asm. If there is some specific inline asm
syntax that clang does not recognise, then please will you point me
to the relevant LLVM bug report and I will investigate it.
Sorry, I don't know about clang/llvm bug reports, I just try to build
mplayer with Win32 codecs support on FreeBSD-10/i386.
And currenly (in rev r315041) building by clang disabled in ports tree.
And i found PR about clang and mplayer: ports/176272
This PR contains log with build error log.
PR176272 is form mplayer-1.1.r20120721_2, and was closed due to the
issue was fixed by updating the port to a more recent version.
Mplayer is currently mplayer-1.1.r20130308, do you still see the same
issues with clang?
Now issues as in ports/180564. Not same, but very close ('ran out of
registers during register allocation' in other place).
___
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: GCC withdraw
On Sun, Aug 25, 2013 at 12:23:45AM -0700, Rui Paulo wrote: On 25 Aug 2013, at 00:24, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote: On 24 Aug 2013, at 16:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. Irrelevant to the discussion since the base system GCC has the same problem. How about ports/180564? And llvm community known about this issue: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2013-July/259146.html Have you tried submitting that directly to mplayer? No, I don't know about mplayer bug database and mplayer's support FreeBSD-current as target. ___ 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: GCC withdraw
On 25 Aug 2013, at 00:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. This bug relates to a corner case in complex floating point support, which GCC in base doesn't get right either, and which affects a tiny proportion of users and which comes with a hypothetical test case but no evidence that any real-world code is affected by it. If you have some real-world code that is compiled correctly by GCC but incorrectly by clang as a result of this, then please update the bug. Oh, and it's worth noting that clang, as an extension, supports using initialiser lists to create complex values and so this particular case is trivial to avoid if you use this feature, which you will if you create complex numbers using the macro that the C specification introduced specifically to avoid this case. David ___ 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: GCC withdraw
On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ David And THIS is a major reason why FreeBSD needs a compiler in base instead of all tools being ports. The last thing we need is to start responding to every problem with this is not my problem, go file a report upstream. If we're already doing it for the compiler that's supposed to be the new supported tool, how much worse will peoples' experience be when we assert no ownership or responsibility for a toolchain at all? -- Ian ___ 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: GCC withdraw
Den 25/08/2013 kl. 16.21 skrev Ian Lepore i...@freebsd.org: Please file clang bugs at http://llvm.org/bugs/ And THIS is a major reason why FreeBSD needs a compiler in base instead of all tools being ports. The last thing we need is to start responding to every problem with this is not my problem, go file a report upstream. If we're already doing it for the compiler that's supposed to be the new supported tool, how much worse will peoples' experience be when we assert no ownership or responsibility for a toolchain at all? I think it's perfectly reasonable to direct compilation problems in a program residing in ports to the developers of the compiler. It really has nothing to do with the FreeBSD base compiler. The reason being that mplayer relies on a non-docmented GCC-specific asm side-effect, and there's a one-line patch in the PR which solves the problem, makes the claim even more absurd. Expecting FreeBSD Clang maintainers to respond to compilation issues in FreeBSD base seems perfectly reasonable. Expecting them to respond to random issues in the ~24.000 ports is not. Erik ___ 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: GCC withdraw
On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote: On 25 Aug 2013, at 00:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. This bug relates to a corner case in complex floating point support, which GCC in base doesn't get right either, GCC addressed issue in 4.5.0. I don't necessarily agree with the fix, but gcc did not ignore it. I understand why FreeBSD has not updated to a newer gcc base. and which affects a tiny proportion of users yep, anyone using complex arithmetic. and which comes with a hypothetical test case Of course, it is a trivial testcase. It was meant to be trivial to demonstrate the bug and aid the compiler writer in fixing it. but no evidence that any real-world code is affected by it. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599 If you have some real-world code that is compiled correctly by GCC but incorrectly by clang as a result of this, then please update the bug. Go read FreeBSD libm's code where I (and now others) had/have to jump through hoops with cpack[f|l] functions to avoid the problem. Oh, and it's worth noting that clang, as an extension, supports using initialiser lists to create complex values and so this particular case is trivial to avoid if you use this feature, which you will if you create complex numbers using the macro that the C specification introduced specifically to avoid this case. See msun/src/math_private.h. But, the above is irrelevant. You missed my point, so to be blunt. Reporting the bug to llvm does not mean that it will be fixed. More importantly the problem with mplayer and clang should be reported/recorded in FreeBSD's bug database where others can find the issue when clang fails to build mplayer. The mplayer maintainer can either fix the problem or escaluate the issue upstream. -- 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: GCC withdraw
2013/8/25 David Chisnall thera...@freebsd.org: Oh, and it's worth noting that clang, as an extension, supports using initialiser lists to create complex values and so this particular case is trivial to avoid if you use this feature, which you will if you create complex numbers using the macro that the C specification introduced specifically to avoid this case. Or even better, use the C11 CMPLX()/CMPLXF()/CMPLXL() macros, which are properly supported by FreeBSD -HEAD. -- Ed Schouten e...@80386.nl ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote: On 8/24/13 3:23 AM, Mark Felder wrote: On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. Why do you need to use gcc for everything? What happens if you use clang? Be specific, without details this is just FUD. Roman ___ 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: GCC withdraw
On 24 Aug 2013, at 02:35, Julian Elischer jul...@freebsd.org wrote: I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. Please point to the FreeBSD PRs and clang bug reports that you have filed about this. I have been running a FreeBSD VM on Xen with the clang is cc option for over a year and not encountered this problem. David ___ 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: GCC withdraw
If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. I am not a developer, just a user, so I am not versed in all of the issues but I would REALLY like to see gcc moved to ports for 10.x In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. FreeBSD as a community made the decision to move to clang as a compiler, and moving gcc to ports enforces that decision, I prefer the rip the band aid off approach because it brings issues to light faster, and now people have real reasons to fix things. Now, I am aware that other architectures like ARM etc. need gcc in base for basic things like building kernel/world, because clang cant do this yet. Maybe this is over simplifying it a bit but can't we just modify scripts in some way to pull gcc from ports into base, for these platforms at build time? SVN *is* in base now (svnlite) From an outside look at this, it seems to me that we're holding back the amd64 platform just because the developer activity is a little more sparse than we would prefer on other platforms. Other platforms are important and they are needed, but those platforms are the ones that need patched up, they are the ones that need the band-aids implemented so that gcc still works for them. So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) So in the name of progress, let's make a comfortable final resting place for gcc in our ports tree and look to clang for our future. Thoughts, Sam Fourman Jr. ___ 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: GCC withdraw
On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? David ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 06:30:24AM -0400, Sam Fourman Jr. wrote: If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. I am not a developer, just a user, so I am not versed in all of the issues but I would REALLY like to see gcc moved to ports for 10.x In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. ___ 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: GCC withdraw
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. David ___ 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: GCC withdraw
In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved -- Sam Fourman Jr. ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 12:11:16PM +, Sam Fourman Jr. wrote: In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved Yes, I just edit Makefile. But this is point about ports builded by 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: GCC withdraw
On 8/24/13 7:19 PM, David Chisnall wrote: On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? The same work needs to be done no matter where it is.. there is no saving in moving it, and a lot of hassle.. leave the damned thing alone and be thankful that we have switched to clang by default! don't over-reach your successes. David ___ 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 ___ 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: GCC withdraw
On 8/24/13 3:41 PM, Roman Divacky wrote: On Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote: On 8/24/13 3:23 AM, Mark Felder wrote: On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. Why do you need to use gcc for everything? What happens if you use clang? Be specific, without details this is just FUD. Roman I couldn't even get it to compile a few weeks ago. i386 xen kernel.. gcc breezed straight through (though getting it to boot was another story) ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. PS: Also, if FreeBSD ship clang why ship not full set of clang? For example, when I try to build llvm-lua not found sets of files: LLVMCompiler.cpp:25:30: error: llvm/LLVMContext.h: No such file or directory LLVMCompiler.cpp:26:31: error: llvm/DerivedTypes.h: No such file or directory LLVMCompiler.cpp:27:50: error: llvm/ExecutionEngine/ExecutionEngine.h: No such file or directory LLVMCompiler.cpp:28:25: error: llvm/Module.h: No such file or directory LLVMCompiler.cpp:29:30: error: llvm/PassManager.h: No such file or directory LLVMCompiler.cpp:30:36: error: llvm/Analysis/Verifier.h: No such file or directory LLVMCompiler.cpp:31:36: error: llvm/Target/TargetData.h: No such file or directory LLVMCompiler.cpp:32:39: error: llvm/Target/TargetMachine.h: No such file or directory LLVMCompiler.cpp:33:40: error: llvm/Target/TargetOptions.h: No such file or directory LLVMCompiler.cpp:34:36: error: llvm/Transforms/Scalar.h: No such file or directory LLVMCompiler.cpp:35:33: error: llvm/Transforms/IPO.h: No such file or directory LLVMCompiler.cpp:36:43: error: llvm/Transforms/Utils/Cloning.h: No such file or directory LLVMCompiler.cpp:37:36: error: llvm/Support/IRBuilder.h: No such file or directory LLVMCompiler.cpp:38:32: error: llvm/Support/Timer.h: No such file or directory LLVMCompiler.cpp:39:38: error: llvm/Support/CommandLine.h: No such file or directory ___ 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: GCC withdraw
On Aug 24, 2013, at 6:11 AM, Sam Fourman Jr. wrote: In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved The problem is that there's a lot of cases in ports where this work needs to be done. That work is ongoing, but isn't done yet. The ports people have indicated that in the 10 time frame may be a bit optimistic... Warner ___ 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: GCC withdraw
On Sat, Aug 24, 2013 at 07:42:17PM +0400, Slawa Olhovchenkov wrote: On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. ___ 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: GCC withdraw
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. -- 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ 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: GCC withdraw
23.08.2013 15:16, Kurt Jaeger пишет: Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: GCC withdraw
On 23.08.13 14:16, Kurt Jaeger wrote: Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. For many of the important ports, they do get used together with other ports that already require newer gcc from ports anyway. So no additional pollution will be created. Daniel ___ 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: GCC withdraw
In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 5:16 AM, Kurt Jaeger wrote: Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. Warner ___ 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 7:54 AM, David Chisnall wrote: On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... I'll have to try the native build part of the cycle then... Early versions of the patch failed when you cross built the target, installed the target, but wound up with no compilers to bootstrap the external toolchains with to do native builds on the target. Warner ___ 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Fri, Aug 23, 2013 at 03:02:18PM +0400, Boris Samorodov wrote: 23.08.2013 13:16, David Chisnall ??: I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. +1 -- 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: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. There is also the concern whether clang in base will reliably build gcc required for some ports, and then there are those CPU architectures for which clang is nonexistent or not ready. Regarding those ports that build with the ancient gcc 4.2.1 but not with newer versions, that has to be considered a bug. Consider that Linux and the other BSDs use newer versions of gcc to build their base system and ports or pkgsrc. Tom ___ 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: GCC withdraw
On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. ___ 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: GCC withdraw
On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. ___ 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: GCC withdraw
On 8/24/13 3:23 AM, Mark Felder wrote: On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. ___ 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 ___ 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
