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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: 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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
