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 u
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.
On 1 Sep 2013, at 19:03, Mark Linimon 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 Chisnal
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
On 1 Sep 2013, at 02:53, Benjamin Kaduk 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 b
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
On 31 Aug 2013, at 08:33, John-Mark Gurney 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 t
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 appea
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 l
>Subject: Re: GCC withdraw
>From: Warner Losh
>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
On Fri, Aug 30, 2013 at 11:11 AM, David Chisnall wrote:
> On 30 Aug 2013, at 15:41, 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.
On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote:
>
> On 30 Aug 2013, at 08:56, Jonathan Anderson 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 ti
On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote:
> On 29 Aug 2013, at 18:44, John Baldwin 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 bu
On Fri, Aug 30, 2013 at 6:47 AM, Ian Lepore 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
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 wrote:
> > Also, unless you plan on desupporting all non-x86 platforms, you _still_
> > have to do al
On 30 Aug 2013, at 15:53, Nathan Whitehorn 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++1
On 30 Aug 2013, at 15:41, 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
On 08/30/13 00:35, David Chisnall wrote:
> On 30 Aug 2013, at 08:18, Julian Elischer 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 deprecate
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 wron
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 suff
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
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"
On 30 Aug 2013, at 08:56, Jonathan Anderson 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
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
On 30 Aug 2013, at 08:18, Julian Elischer 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 t
On 29 Aug 2013, at 18:44, John Baldwin 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
On 8/30/13 1:02 AM, David Chisnall wrote:
On 29 Aug 2013, at 15:57, John Baldwin 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-specifi
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin 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
On Aug 29, 2013, at 11:02 AM, David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin 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 st
On 29 Aug 2013, at 15:57, John Baldwin 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 h
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 wrote:
>>
>>> And i found PR about clang and mplayer: ports/176272
>>> This PR contains log with build error log.
>>
>> Please file clang bu
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." wrote:
>>
>>> So I vote, let's not give ourselves the burden of "lugging" dead weight in
>>> base
>>> for another 5 years. (in 2017 do
On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
> On 24 Aug 2013, at 11:30, "Sam Fourman Jr." 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?)
>
2013/8/25 David Chisnall :
> 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 spe
On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote:
> On 25 Aug 2013, at 00:06, Steve Kargl
> wrote:
>
> > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
> >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
> >>
> >>> And i found PR about clang and mplayer: por
On Sun, Aug 25, 2013 at 05:24:23PM +0200, Erik Cederstrand wrote:
> 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.
OK, how FreeBSD Clang maintainers can r
Den 25/08/2013 kl. 16.21 skrev Ian Lepore :
>> 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, g
On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote:
> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov 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
On 25 Aug 2013, at 00:06, Steve Kargl wrote:
> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
>>
>>> And i found PR about clang and mplayer: ports/176272
>>> This PR contains log with build error log.
>>
>> Please file cla
On Sun, Aug 25, 2013 at 12:23:45AM -0700, Rui Paulo wrote:
> On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote:
>
> > On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
> >
> >> On 24 Aug 2013, at 16:06, Steve Kargl
> >> wrote:
> >>
> >>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, Da
On Sun, Aug 25, 2013 at 02:23:54AM -0500, Scot Hetzel wrote:
> On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov 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
On Sat, Aug 24, 2013 at 5:42 PM, Slawa Olhovchenkov 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 wrote:
>> >
>> > > Oh, I remember. mplayer on
On 25 Aug 2013, at 00:24, Slawa Olhovchenkov wrote:
> On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
>
>> On 24 Aug 2013, at 16:06, Steve Kargl
>> wrote:
>>
>>> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote
On Sun, Aug 25, 2013 at 12:13:15AM -0700, Rui Paulo wrote:
> On 24 Aug 2013, at 16:06, Steve Kargl
> wrote:
>
> > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
> >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
> >>
> >>> And i found PR about clang and mplayer: ports/1
On 24 Aug 2013, at 16:06, Steve Kargl wrote:
> On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
>> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
>>
>>> And i found PR about clang and mplayer: ports/176272
>>> This PR contains log with build error log.
>>
>> Please file cla
On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov 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 go
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov 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
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 wrote:
> >
> > > Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
> > > don't understand
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
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote:
> On 24 Aug 2013, at 12:51, Slawa Olhovchenkov 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 as
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
On 8/24/13 7:19 PM, David Chisnall wrote:
On 24 Aug 2013, at 11:30, "Sam Fourman Jr." 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
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.
> >
> >
> 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
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov 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
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 po
On 24 Aug 2013, at 11:30, "Sam Fourman Jr." 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 maintai
> 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
On 24 Aug 2013, at 02:35, Julian Elischer 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
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:
> >>>
> >
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 thi
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
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
> 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 architectur
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;
On Aug 23, 2013, at 7:54 AM, David Chisnall wrote:
> On 23 Aug 2013, at 14:52, Warner Losh 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, alt
On 23 Aug 2013, at 14:52, Warner Losh 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'
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 de
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
e 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
; 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 gc
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 w
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.
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.
73 matches
Mail list logo
