> On Dec 18, 2014, at 12:01 PM, Dimitry Andric wrote:
>
> On 18 Dec 2014, at 15:47, Warner Losh wrote:
> ...
>>> * Mips will only have a chance with the upcoming clang 3.6.0, but that
>>> is way too late for this import. It will probably require external
&
This is excellent news Dimitry!
> On Dec 16, 2014, at 12:36 PM, Dimitry Andric wrote:
>
> On 28 Nov 2014, at 22:03, Dimitry Andric wrote:
>>
>> We're working on updating llvm, clang and lldb to 3.5.0 in head. This
>> is quite a big update again, and any help with testing is appreciated.
>>
>
imp added a subscriber: imp.
imp accepted this revision.
imp added a reviewer: imp.
imp added a comment.
This revision is now accepted and ready to land.
Looks good to me.
REVISION DETAIL
https://reviews.freebsd.org/D1327
To: emaste, imp
Cc: imp, freebsd-toolchain
_
> On Dec 16, 2014, at 12:01 PM, Dimitry Andric wrote:
>
> On 16 Dec 2014, at 18:54, Warner Losh wrote:
>>
>>> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote:
>>>
>>> Fair enough, I'd definitely like to see fewer build-time knobs over
>>&g
> On Dec 16, 2014, at 10:44 AM, Ed Maste wrote:
>
> Fair enough, I'd definitely like to see fewer build-time knobs over
> time, not more.
Until we stop using build-time knobs to control what’s in the final image
as a poor man’s packaging scheme, I expect the number of knobs to
continue to grow.
> On Dec 16, 2014, at 9:32 AM, Dimitry Andric wrote:
>
> On 16 Dec 2014, at 17:15, David Chisnall wrote:
>>
>> On 16 Dec 2014, at 16:04, Dimitry Andric wrote:
>>> This is precisely why the libs should go into /usr/lib/private, so as to
>>> avoid collisions with any upstream libraries installe
On Sep 6, 2014, at 5:32 AM, Dimitry Andric wrote:
> On 06 Sep 2014, at 05:16, Warner Losh wrote:
>>
>> On Sep 5, 2014, at 8:21 PM, Garrett Cooper wrote:
>>>
>>> One of the questions that came up from a co-worker is "why do I
>>> need to buil
On Sep 6, 2014, at 5:28 AM, David Chisnall wrote:
> On 6 Sep 2014, at 06:47, Garrett Cooper wrote:
>
>> Makes sense. I'll do some poking around and see if things could potentially
>> be optimized with the clang build. On beefy machines it's not a big deal,
>> but as we know on machines witho
On Sep 5, 2014, at 8:21 PM, Garrett Cooper wrote:
> Hi all,
>One of the questions that came up from a co-worker is "why do I
> need to build clang in buildworld if I already installed it from
> ports"? I could see some valid reasons for doing this (one needs a
> cross-compiler, one might nee
On Jun 11, 2014, at 12:53 PM, Craig Rodrigues wrote:
> Hi,
>
> Recently when trying to debug some coredumps in CURRENT from
> a userland process in the devel/libvirt port, I found that the gdb in
> base could not get a backtrace from the core file:
>
> http://lists.freebsd.org/pipermail/freebs
About the time clang was MFC’d, this started appearing. It has been several
days now.
Did the clang MFC botch something? Was the timing just a coincidence?
Warner
Begin forwarded message:
> From: FreeBSD Tinderbox
> Subject: [releng_10 tinderbox] failure on arm/arm
> Date: March 23, 2014 at 9
On Mar 1, 2014, at 4:18 PM, Ahmed Charles wrote:
>
>> Subject: Re: More dangerous UB handling of clang (compared to gcc)
>> From: bsd...@gmail.com
>> Date: Fri, 28 Feb 2014 08:38:38 -0700
>> To: amd...@amdmi3.ru
>> CC: freebsd-toolchain@FreeBSD.org
>>
>>
On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov wrote:
> Hi!
>
> Another issue I wanted to mention: compared to gcc, clang handles
> some undefined behaviour cases more dangerously. It has the full
> right to do so as it's UB, however we may want to take extra steps
> to find and fix these cases.
I'd add to the list the upgrade path (from 9.x, 10.x and current) as well, just
to make sure they all still work... If there are problems with the 9.x upgrade
path, we'll need to call them out since 10.0 hasn't been released yet and
there's still a lot of 9.x boxes in the wild...
Warner
On Jan
On Nov 24, 2013, at 5:54 AM, David Chisnall wrote:
> On 23 Nov 2013, at 22:11, Pedro Giffuni wrote:
>
>> I have particular interest in -fwritable-strings
>> and the block support, mostly with the idea of making our gcc
>> somewhat more compatible to clang.
>
> I would absolutely love to see ou
On Nov 17, 2013, at 2:45 PM, Dimitry Andric wrote:
> On 17 Nov 2013, at 20:37, Warner Losh wrote:
>> In 9.2 stable on amd64, make xdev is broken.
>>
>> sudo make xdev XDEV=i386 XDEV_ARCH=i386
>>
>> terminates with
>>
>> In file included from
&g
In 9.2 stable on amd64, make xdev is broken.
sudo make xdev XDEV=i386 XDEV_ARCH=i386
terminates with
In file included from
/imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:17:
/imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/t
ould just use something
> as simple as :
>
> if uname="FreeBSD"
> # override configure preference for gcc since FreeBSD ships an ancient one.
> AC_PROG_CC(clang llvm-gcc gcc)
> AC_PROG_CXX(clang++ llvm-g++ g++)
> else
> AC_PROG_CC
> AC_PROG_CXX
>
On Sep 12, 2013, at 7:32 PM, Murray Stokely wrote:
> Some application software I use seems to prefer ancient gcc release or
> gcc46 from ports rather than clang.
>
> Is there a recommended autoconf recipe for third party software to use the
> right compilers across FreeBSD versions?
I thought t
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.
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
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 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 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
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 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&#x
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 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 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
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 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
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
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 Jun 10, 2013, at 10:36 AM, Simon J. Gerraty wrote:
> Hi Chris,
>
>> bmake appears to export ${.MAKE.LEVEL} into the environment, which sh
>> doesn't support, due to the leading '.'. Normally this is ignored,
>
> Yes, though env(1) does allow it. The leading '.' was deliberately chosen
> t
On May 30, 2013, at 10:11 AM, Pedro Giffuni wrote:
> On 29.05.2013 11:06, Warner Losh wrote:
>> On May 29, 2013, at 2:47 AM, David Chisnall wrote:
>>
>>> On 29 May 2013, at 07:57, Andriy Gapon wrote:
>>>
>>>> In fact, I am of opinion that while suc
On May 29, 2013, at 2:47 AM, David Chisnall wrote:
> On 29 May 2013, at 07:57, Andriy Gapon wrote:
>
>> In fact, I am of opinion that while such bugs exist gcc should be crowned
>> back
>> as a default compiler.
>
> Seriously? Your show stopper bug is that, very occasionally, clang emits
>
On May 28, 2013, at 12:10 PM, David Chisnall wrote:
> On 28 May 2013, at 18:40, Warner Losh wrote:
>
>> That's not going to happen soon. While it works OK for amd64, there's still
>> many bugs in its ARM support and even more in its MIPS support. There's 0
On May 27, 2013, at 2:07 PM, Pedro Giffuni wrote:
> On 27.05.2013 14:38, Dimitry Andric wrote:
>> On May 27, 2013, at 21:12, Rui Paulo wrote:
>>> On 27 May 2013, at 09:41, Pedro Giffuni wrote:
Almost a year ago I tried to bring in the support for AMD's barcelona
chipset into our gcc.
On May 27, 2013, at 1:48 PM, Pedro Giffuni wrote:
> On 27.05.2013 14:12, Rui Paulo wrote:
>> On 27 May 2013, at 09:41, Pedro Giffuni wrote:
>>
>>> Hello;
>>>
>>> Almost a year ago I tried to bring in the support for AMD's barcelona
>>> chipset into our gcc. This actually filled a lot of holes
On May 7, 2013, at 11:41 PM, Simon J. Gerraty wrote:
>
> On Tue, 7 May 2013 21:25:37 -0600, Warner Losh writes:
>> where does MAKEOBJDIRPREFIX come into play?
>
> I don't normally use it, it is a handy but rather crude implement.
> I normally use
>
>
On May 7, 2013, at 9:42 PM, Garrett Cooper wrote:
> On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote:
>
> On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote:
>
> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote:
>
> > On May 7, 2013, at 1:39 PM, Brooks Davis wro
On May 7, 2013, at 3:31 PM, Simon J. Gerraty wrote:
>
> On Tue, 7 May 2013 13:05:07 -0700, Garrett Cooper writes:
>> A common pattern that I've seen at Isilon and something else that I've
>> wanted to have for a while is the ability to designate where the top of a
>> source tree was. This is i
On May 7, 2013, at 2:46 PM, Garrett Cooper wrote:
> On May 7, 2013, at 1:39 PM, Brooks Davis wrote:
>
>> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote:
>>> Hi,
>>> A common pattern that I've seen at Isilon and something else that I've
>>> wanted to have for a while is the abil
On Mar 18, 2013, at 3:07 AM, Andrew Turner wrote:
> I would like to make clang the default compiler on ARM using the patch
> at [1]. This only affects little-endian ARM as there is no support for
> big-endian ARM in clang.
>
> This will help me with my work to update the FreeBSD ARM ABI as I am
On Mar 7, 2013, at 8:07 PM, Eitan Adler wrote:
> On 7 March 2013 18:03, Tijl Coosemans wrote:
>> On 2013-03-07 22:36, Warner Losh wrote:
>>> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote:
>>>> On 2013-03-07 21:22, Tijl Coosemans wrote:
>>>> ...
&g
On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote:
> On 2013-03-07 21:22, Tijl Coosemans wrote:
> ...
>> Because it's the practical thing to do? Old code/makefiles can't possibly
>> be expected to know about compilers of the future, while new code can be
>> expected to add -std=c11.
>
> I am not
On Jan 26, 2013, at 5:28 AM, Pedro Giffuni wrote:
> The situation is not too different from the fortran removal: for many reasons
> it is convenient to use a pre-packaged compiler for many ports. Gcc 4.2.1 is
> also becoming obsolete and is really difficult to maintain..
Removing it before all
On Jan 25, 2013, at 3:18 PM, Andriy Gapon wrote:
> on 25/01/2013 21:35 Warner Losh said the following:
>> This has been talked about in a vague way for years.
>
> Warner,
>
> just a nitpick, couldn't resist - sorry, so for years we talked about the
> magic
>
On Jan 25, 2013, at 1:41 AM, David Chisnall wrote:
> Hi All,
>
> In 10.0, the plan is not to ship any GPL'd code, so I'd like to start
> disconnecting things from the default build, starting with gcc. I've been
> running a gcc-free system for a while, and I think all of the ports that
> don'
On Jan 25, 2013, at 7:25 AM, Andriy Gapon wrote:
> on 25/01/2013 16:10 David Chisnall said the following:
>> On 25 Jan 2013, at 14:03, Andriy Gapon wrote:
>>
>>> on 25/01/2013 15:21 David Chisnall said the following:
This is something that has been said on mailing lists, at BSDCan and at
>
On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote:
> On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote:
>> Hi All,
>>
>> In 10.0, the plan is not to ship any GPL'd code, so I'd like to start
>> disconnecting things from the default build, starting with gcc. I've been
>> runn
On Jan 17, 2013, at 12:05 AM, John-Mark Gurney wrote:
> Mike Belopuhov pointed me to the patch in OpenBSD:
> http://freshbsd.org/commit/openbsd/0babc91a00b1f1953637bb39c8ec97aef704629e/diff.txt
>
> While OpenBSD's binutils is quite different than FreeBSD's, I was able
> to use his patch to teach
On Dec 13, 2012, at 6:18 AM, Erik Cederstrand wrote:
> Den 13/12/2012 kl. 14.10 skrev David Chisnall :
>
>> Hi Eric,
>>
>> The easiest way of doing this is to make /usr/bin/ld (in the host system and
>> in the bootstrap) into a symbolic link that points to whatever the selected
>> linker is.
On Nov 12, 2012, at 12:53 AM, Erik Cederstrand wrote:
> Den 09/11/2012 kl. 16.22 skrev Erik Cederstrand :
>
>> Den 09/11/2012 kl. 15.36 skrev Warner Losh :
>>
>>> On Nov 9, 2012, at 3:52 AM, Erik Cederstrand wrote:
>>>
>>>> Hello toolchainers,
On Nov 9, 2012, at 3:52 AM, Erik Cederstrand wrote:
> Hello toolchainers,
>
> I'm attempting to clean up hardcoded ar(1) flags in the tree to use the
> global ARFLAGS in share/mk/sys.mk instead. I want to be able to add "-D" to
> ARFLAGS and have it used everywhere.
>
> The patch changes some
On Sep 17, 2012, at 1:51 PM, Brooks Davis wrote:
> On Mon, Sep 17, 2012 at 01:36:53PM -0600, Warner Losh wrote:
>>
>> On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote:
>>> Now that we have the COMPILER_TYPE variable I'm following up on an idea
>>> by the
On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote:
> Now that we have the COMPILER_TYPE variable I'm following up on an idea
> by theraven@ that we should enable libc++ by default when we are
> building world with a compiler that supports it. The following patch
> implements this:
>
> http://peopl
On Sep 15, 2012, at 3:14 AM, Roman Divacky wrote:
> LLVM by default turns these:
>
>case LibFunc::copysign: case LibFunc::copysignf: case LibFunc::copysignl:
>case LibFunc::fabs: case LibFunc::fabsf: case LibFunc::fabsl:
>case LibFunc::sin: case LibFunc::sinf:
On Sep 10, 2012, at 4:56 PM, Brooks Davis wrote:
> .if ${COMPILER_TYPE} != "clang"
>
> I'd like to commit this in the next few days unless there are objections
> requiring a major redesign.
Due to other $LIFE happening, I just scanned the patch, but I really like it.
I'd also propose a COMPILER
Hi Pete,
the best way to find out if support for archives are needed is to release it
for testing. People find the craziest things when testing in a wider arena.
Alternatively, see if can survive /usr/ports being thrown at it :) even clang
can't do that yet (although it isn't always clang's f
On Jul 6, 2012, at 1:11 PM, David Chisnall wrote:
> On 6 Jul 2012, at 17:54, Andriy Gapon wrote:
>
>> Yeah. Honestly speaking I myself was not aware of what is written in that
>> link
>> and I thought that our gcc ports (from ports) added /usr/local/include to the
>> default search path by som
On Jul 6, 2012, at 9:14 AM, Andriy Gapon wrote:
> on 06/07/2012 18:10 Warner Losh said the following:
>> I think it shouldn't be there. It is non-standard behavior both in the gcc
>> world and in the freebsd world. It does save a little on makefiles on some
>> por
Top posting, because I'm lame...
I think it shouldn't be there. It is non-standard behavior both in the gcc
world and in the freebsd world. It does save a little on makefiles on some
ports, but most ports already grok things are in /usr/local or opt/local and
cope.
Warner
On Jul 6, 2012, at
On Feb 26, 2012, at 2:37 PM, Alexander Best wrote:
> hi there,
>
> any chance support for setting CC/CXX/CPP unconditionally in src.conf could be
> added before the release of freebsd 10.0? the way it is done atm is really not
> intuitive. the rule should really be:
>
> - make.conf = applies gl
On Nov 8, 2011, at 2:55 PM, Alexander Best wrote:
> find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} +
> rm/obj/usr/git-freebsd-head/*
>
> that should only execute chflags(1) on those files with flags set.
THat's only faster if the entire directory tree says in the directory
On Nov 8, 2011, at 1:49 PM, Alexander Best wrote:
> hi there,
>
> any reason 'make cleanworld' does
>
> otaku% make cleanworld
> rm -rf /usr/obj/usr/git-freebsd-head/*
> chflags -R 0 /usr/obj/usr/git-freebsd-head
> rm -rf /usr/obj/usr/git-freebsd-head/*
>
> where
>
> otaku% make cleanworld
>
On Nov 6, 2011, at 5:47 PM, Rui Paulo wrote:
> On Nov 6, 2011, at 4:36 PM, Warner Losh wrote:
>
>> On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote:
>>> The only argument against this tautological check that I agree with is when
>>> the code is explicitly trying to be
On Nov 6, 2011, at 2:13 PM, Rui Paulo wrote:
> The only argument against this tautological check that I agree with is when
> the code is explicitly trying to be safe. If the developer checks for "i < 0"
> when indexing an array he/she is trying to guard against possible pitfalls in
> the future
On Nov 6, 2011, at 1:58 PM, Alexander Best wrote:
> On Sun Nov 6 11, Dimitry Andric wrote:
>> On 2011-11-06 21:33, Alexander Best wrote:
>> ...
>>> the problem is, something like
>>>
>>> uint x;
>>>
>>> if (x < 0) ...
>>>
>>> clang will warn about this, yet it is 100% valid code so my vote w
I'm all for leaving it on because things like char are signed on some
architectures and unsigned on others. This leads to bugs that only appear on
one architecture. This warning will, at least, flag those usages.
On Oct 17, 2011, at 10:56 AM, Gerald Pfeifer wrote:
> On Mon, 17 Oct 2011, Alexa
We really need a 'SYSTEM_COMPILER={gcc,clang,xxx}' sort of knob.
Warner
On Aug 18, 2011, at 2:04 PM, Kostik Belousov wrote:
> On Thu, Aug 18, 2011 at 09:54:41PM +0200, Dimitry Andric wrote:
>> The problem is in your make.conf. Effectively, you are doing:
>>
>> CC = clang
>> CXX = clang++
>>
>>
On Aug 4, 2011, at 4:13 AM, Dimitry Andric wrote:
> On 2011-08-04 10:38, majia gm wrote:
>> I'm building the libc code which derived from a current trunk
>> mirror/freebsd/head under PCBSD 8.2 which contains FreeBSD 8.2
>> release.
>> I'm trying to test the modified libc by using LD_LIBRARY_PATH.
You need to use buildworld or one of its sub-targets.
Warner
On Aug 4, 2011, at 2:38 AM, majia gm wrote:
> Hi, everyone.
>
> I'm building the libc code which derived from a current trunk
> mirror/freebsd/head under PCBSD 8.2 which contains FreeBSD 8.2
> release.
> I'm trying to test the modifie
On Jun 25, 2011, at 9:16 AM, Gerald Pfeifer wrote:
> On Wed, 22 Jun 2011, Damjan Marion wrote:
>> I see 3 options to fix this:
>>
>> 1. Ask clang folks to patch llvm to use old mnemonics ("mov r0, r0, rrx"
>> instead of "rrx r0,r0")
>> 2. Maintain same patch for freebsd only
>> 3. patch binuti
On Jun 22, 2011, at 10:42 AM, Ryan Stone wrote:
> On Wed, Jun 22, 2011 at 11:39 AM, Warner Losh wrote:
>> I'd be inclined to include a small patch to FreeBSD's binutils to implement
>> this. You might be able to snag it from a newer version of binutils if you
>&g
I'd be inclined to include a small patch to FreeBSD's binutils to implement
this. You might be able to snag it from a newer version of binutils if you can
track down the author of that code and ask if you can include it in a GPLv2
version of binutils.
Warner
On Jun 22, 2011, at 7:09 AM, Damja
On Jun 21, 2011, at 3:31 PM, Damjan Marion wrote:
>
> On Jun 21, 2011, at 7:06 PM, Warner Losh wrote:
>>
>> On Jun 21, 2011, at 3:12 AM, Damjan Marion wrote:
>>>
>>> On Jun 17, 2011, at 9:16 PM, Warner Losh wrote:
>>>>
>>>> How it
On Jun 21, 2011, at 3:12 AM, Damjan Marion wrote:
>
> On Jun 17, 2011, at 9:16 PM, Warner Losh wrote:
>
>>
>> On Jun 17, 2011, at 12:38 PM, Damjan Marion wrote:
>>
>>> Now, I'm back on my original problem, clang invokes /usr/bin/as which is
>&
On Jun 17, 2011, at 12:38 PM, Damjan Marion wrote:
>
> On Jun 17, 2011, at 7:29 PM, Warner Losh wrote:
>
>> Shouldn't you be modifying the CFLAGS and CXXFLAGS instead of CC and CXX?
>>
>> Warner
>
>
> Right, must be some "smart" reason why
Shouldn't you be modifying the CFLAGS and CXXFLAGS instead of CC and CXX?
Warner
On Jun 17, 2011, at 10:50 AM, Damjan Marion wrote:
>
> Hi,
>
> Im trying to fix cross-compiling for arm architecture using clang. I added
> following patch:
>
>
> ==
Hey Marcel,
I don't mean to throw cold water at your enthusiasm, but I thought I heard that
upstream llvm was in the process of decommissioning ia64 support. Did I hear
wrong?
Warner
On Jun 10, 2011, at 9:38 AM, Marcel Moolenaar wrote:
>
> On Jun 10, 2011, at 12:25 AM, Roman Divacky wrote:
On May 27, 2011, at 12:14 PM, Alexander Best wrote:
> On Fri May 27 11, Warner Losh wrote:
>> These look generally good. Just one thing I had a question on:
>>
>> #
>> +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct
>> gcc to
>>
These look generally good. Just one thing I had a question on:
#
+# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc to
+# enable some diagnostics, which make it easier to pinpoint tinderbox failures.
+CFLAGS+= -fformat-extensions -fdiagnostics-show-option
+
Does
On 02/18/2011 18:01, Alexander Best wrote:
hi everybody,
r218745 triggered quite a discussion about dead code in boot2.c. i talked to
roman (rdivacky@) and we were trying to improve the situation so that boot2
would build with clang 2.8 (base) and the latest development version of
clang (trunk).
On 02/01/2011 04:27, b. f. wrote:
Gerald Pfeifer wrote:
On Sun, 30 Jan 2011, Alexander Best wrote:
i might have described things a bit too complicated. basically i want to
have CPUTYPE ?= core2 in my make.conf. clang is capable of producing
core2 specific code, however core2 always gets downgra
101 - 187 of 187 matches
Mail list logo
