On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote:
> On 08/25/13 18:41, Gerald Pfeifer wrote:
>> On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
>>> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be
>>> compiled with lang/gcc. I checked this once and the number of ports
>>> tha
On Mon, 26 Aug 2013, Claude Buisson wrote:
> Perhaps you could have a look at the fact that lang/gcc is at 4.6.3,
> and lang/gcc46 is no more a snapshot but a true release 4.6.4.
I am aware of that. Owed to a strongly voiced desire by users,
I am triggering a rebuild of lang/gcc as rarely as pos
On 08/25/13 18:41, Gerald Pfeifer wrote:
> On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
>> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be
>> compiled with lang/gcc. I checked this once and the number of ports
>> that require strictly gcc 4.2.1 was bigger for me then number o
On 08/26/2013 03:12, Gerald Pfeifer wrote:
On Sat, 24 Aug 2013, Warner Losh wrote:
"If you push gcc out to a port, and you have the 'external compiler'
toolchain support working correctly enough to build with this, why
don't we just push clang out to a port, and be done with it?"
This is a stup
Can all such ports be identified with a ports build run in a special chroot
without FreeBSD's FCC installed?
Sent from my iPad
On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer wrote:
> On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
>> I object. Many ports that compiles perfectly on gcc 4.2.1 can't
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote:
> A possible hack could be to add a check for USE_GCC=any to behave like
> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
> from ports for a lot of people on HEAD I suppose.
I am planning to work on this a bit more once the two
On Sat, 24 Aug 2013, Warner Losh wrote:
>> "If you push gcc out to a port, and you have the 'external compiler'
>> toolchain support working correctly enough to build with this, why
>> don't we just push clang out to a port, and be done with it?"
> This is a stupid idea. It kills the tightly inte
On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be
> compiled with lang/gcc. I checked this once and the number of ports
> that require strictly gcc 4.2.1 was bigger for me then number of
> ports that can't be compiled with clang b
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote:
> lang/gcc42 is on the list of ports that have USE_GCC=any. So you would
> need to fix it first to be able to compile it with clang 3.3 from base.
I don't think so. :-)
You can install lang/gcc which builds just fine with clang, and
then use lang/gcc
On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote:
> On Sat, 24 Aug 2013, Warner Losh wrote:
>>> "If you push gcc out to a port, and you have the 'external compiler'
>>> toolchain support working correctly enough to build with this, why
>>> don't we just push clang out to a port, and be done wi
On Aug 24, 2013, at 3:04 PM, Sam Fourman Jr. wrote:
>
>
>
> On Sat, Aug 24, 2013 at 12:33 PM, Adrian Chadd wrote:
> You know, I could be a total jerk and say:
>
> "If you push gcc out to a port, and you have the 'external compiler'
> toolchain support working correctly enough to build with t
On Sat, Aug 24, 2013 at 12:33 PM, Adrian Chadd wrote:
> You know, I could be a total jerk and say:
>
> "If you push gcc out to a port, and you have the 'external compiler'
> toolchain support working correctly enough to build with this, why don't we
> just push clang out to a port, and be done wi
On Sat, Aug 24, 2013 at 01:05:13AM +0400, Slawa Olhovchenkov wrote:
> On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote:
>
> > Hi!
> >
> > If firewire code doesn't build on clang correctly, have you filed a bug so
> > it gets looked at before 10.0 is released? that's pretty broken
> >
On 8/24/13 9:33 AM, Adrian Chadd wrote:
You know, I could be a total jerk and say:
"If you push gcc out to a port, and you have the 'external compiler'
toolchain support working correctly enough to build with this, why don't we
just push clang out to a port, and be done with it?"
... just sayin
You know, I could be a total jerk and say:
"If you push gcc out to a port, and you have the 'external compiler'
toolchain support working correctly enough to build with this, why don't we
just push clang out to a port, and be done with it?"
... just saying.
-adrian
On Aug 24, 2013, at 4:05 AM, David Chisnall wrote:
> On 23 Aug 2013, at 23:37, Warner Losh wrote:
>
>> I'd dispute the 'and surely it seems like it does' part of this. Non x86
>> architectures will continue to use gcc because clang just isn't ready at
>> this time for them. Some are very clos
On 23 Aug 2013, at 23:37, Warner Losh wrote:
> I'd dispute the 'and surely it seems like it does' part of this. Non x86
> architectures will continue to use gcc because clang just isn't ready at this
> time for them. Some are very close (arm), some are close (powerpc64, mips*),
> some are no w
On 23 Aug 2013, at 13:30, Bernhard Fröhlich wrote:
> lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need
> to fix it first to be able to compile it with clang 3.3 from base.
What is the issue with the gcc 4.2.1 build (aside from the fact that it has a
terrifying number o
On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote:
> On 8/23/13 3:35 AM, David Chisnall wrote:
>> On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
>>
>>> I don't know if you are aware that IF you really do that we will have
>>> serious
>>> problems to ship packages for 10. USE_GCC=any is t
On 8/23/13 3:35 AM, David Chisnall wrote:
On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
I don't know if you are aware that IF you really do that we will have serious
problems to ship packages for 10. USE_GCC=any is the fallback in the
portstree for all ports that are unable to build with
On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote:
> Hi!
>
> If firewire code doesn't build on clang correctly, have you filed a bug so
> it gets looked at before 10.0 is released? that's pretty broken
> code/behaviour.
How I can do it correctly?
Currently in src.conf:
WITHOUT_CLANG=
On 8/23/13 8:26 PM, Andriy Gapon wrote:
on 23/08/2013 14:06 David Chisnall said the following:
Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its
atomic generation so you can't use it sensibly without lots of inline
assembly (which it doesn't support for newer architectu
> 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
cl
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 de
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 Aug 23, 2013, at 6:30 AM, Ian Lepore wrote:
> On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote:
>> On 23 Aug 2013, at 11:42, Julian Elischer wrote:
>>
>>> no, I believe we have said that 10 would ship with clang by default. NO
>>> mention was made about gcc being absent, and I am unc
Hi!
If firewire code doesn't build on clang correctly, have you filed a bug so
it gets looked at before 10.0 is released? that's pretty broken
code/behaviour.
-adrian
On 23 August 2013 04:46, Slawa Olhovchenkov wrote:
> On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer 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, althogh Brooks' work gets us most of
> the way there.
We'
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-o
On Aug 23, 2013, at 5:06 AM, David Chisnall wrote:
> On 23 Aug 2013, at 11:42, Julian Elischer wrote:
>
>> no, I believe we have said that 10 would ship with clang by default. NO
>> mention was made about gcc being absent, and I am uncomfortable with taking
>> that step yet. Having gcc just p
On 08/23/13 07:30, Ian Lepore wrote:
On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote:
On 23 Aug 2013, at 11:42, Julian Elischer wrote:
no, I believe we have said that 10 would ship with clang by default. NO mention
was made about gcc being absent, and I am uncomfortable with taking t
on 23/08/2013 15:56 David Chisnall said the following:
> So you don't want a working debugger? Our gdb doesn't work at all on MIPS
> and barely works with code compiled with clang or a recent gcc.
I am capable of using devel/gdb. Or do you mean kernel debugger?
> We are
> planning on importing
on 23/08/2013 15:34 Nathan Whitehorn said the following:
> On 08/23/13 07:26, Andriy Gapon wrote:
>> on 23/08/2013 14:06 David Chisnall said the following:
>>> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its
>>> atomic generation so you can't use it sensibly without lots
On 23 Aug 2013, at 13:26, Andriy Gapon wrote:
> On the other hand these tools are perfect for building FreeBSD kernel and
> base.
> Extrapolating my experience with base GCC I am very confident in it as a
> FreeBSD development tool.
> Extrapolating my experience with Clang I am not yet confident
On 08/23/13 07:26, Andriy Gapon wrote:
on 23/08/2013 14:06 David Chisnall said the following:
Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its
atomic generation so you can't use it sensibly without lots of inline
assembly (which it doesn't support for newer architectur
On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote:
> On 23 Aug 2013, at 11:42, Julian Elischer wrote:
>
> > no, I believe we have said that 10 would ship with clang by default. NO
> > mention was made about gcc being absent, and I am uncomfortable with taking
> > that step yet. Having gcc
On Fri, Aug 23, 2013 at 2:12 PM, Volodymyr Kostyrko wrote:
> 23.08.2013 12:58, Bernhard Fröhlich wrote:
>>
>> I don't know if you are aware that IF you really do that we will have
>> serious
>> problems to ship packages for 10. USE_GCC=any is the fallback in the
>> portstree for all ports that are
on 23/08/2013 14:06 David Chisnall said the following:
> Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its
> atomic generation so you can't use it sensibly without lots of inline
> assembly (which it doesn't support for newer architectures) for
> multithreaded things.
>
>
23.08.2013 12:58, Bernhard Fröhlich wrote:
I don't know if you are aware that IF you really do that we will have serious
problems to ship packages for 10. USE_GCC=any is the fallback in the
portstree for all ports that are unable to build with clang which was introduced
when HEAD switched to clan
On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote:
> On 8/23/13 6:35 PM, David Chisnall wrote:
> > On 23 Aug 2013, at 10:58, Bernhard Fr?hlich wrote:
> >
> >> I don't know if you are aware that IF you really do that we will have
> >> serious
> >> problems to ship packages for 10. U
On Fri, Aug 23, 2013 at 12:35 PM, David Chisnall wrote:
> On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
>
>> I don't know if you are aware that IF you really do that we will have serious
>> problems to ship packages for 10. USE_GCC=any is the fallback in the
>> portstree for all ports that a
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
On 23 Aug 2013, at 11:42, Julian Elischer wrote:
> no, I believe we have said that 10 would ship with clang by default. NO
> mention was made about gcc being absent, and I am uncomfortable with taking
> that step yet. Having gcc just present, will not hurt you.. even after it is
> gone we wil
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 fo
On 8/23/13 6:35 PM, David Chisnall wrote:
On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
I don't know if you are aware that IF you really do that we will have serious
problems to ship packages for 10. USE_GCC=any is the fallback in the
portstree for all ports that are unable to build with
On 23 Aug 2013, at 10:58, Bernhard Fröhlich wrote:
> I don't know if you are aware that IF you really do that we will have serious
> problems to ship packages for 10. USE_GCC=any is the fallback in the
> portstree for all ports that are unable to build with clang which was
> introduced
> when HE
I don't know if you are aware that IF you really do that we will have serious
problems to ship packages for 10. USE_GCC=any is the fallback in the
portstree for all ports that are unable to build with clang which was introduced
when HEAD switched to clang as default cc. Right now there are 150 port
on 23/08/2013 12:16 David Chisnall said the following:
> 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
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.
David
On 2
In my work to get AES-NI performance in a better state and the fact
that we haven't deprecated gcc yet, I have developed another patch to
add the appropriate AES intrinstic headers to gcc.
The patch is available at:
https://people.freebsd.org/~jmg/gcc.aes.intrin.patch
I did have to change the opt
50 matches
Mail list logo
