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
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 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
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
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
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 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
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
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
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
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
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
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
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
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_
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.org The Power To Serve
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
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
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
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
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
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
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
51 matches
Mail list logo