On 07 Mar 2015, at 21:12, Craig Rodrigues rodr...@freebsd.org wrote:
I ran the build again and this time I am getting errors about undefined
symbol utimensat():
https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/console
Any ideas?
It's linking against the wrong libc,
On 04 Mar 2015, at 09:48, Craig Rodrigues rodr...@freebsd.org wrote:
On Tue, Mar 3, 2015 at 9:17 AM, Dimitry Andric d...@freebsd.org wrote:
On 03 Mar 2015, at 09:00, Craig Rodrigues rodr...@freebsd.org wrote:
CXXFLAGS+= -D_LIBCPP_HAS_NO_ADVANCED_SFINAE
to the make.conf file you use
On 03 Mar 2015, at 09:00, Craig Rodrigues rodr...@freebsd.org wrote:
Based on this mail:
https://lists.freebsd.org/pipermail/freebsd-current/2014-November/053577.html
I created this script to build HEAD with amd64-gcc:
dim created this revision.
dim added reviewers: emaste, theraven.
dim added a subscriber: freebsd-toolchain.
REVISION SUMMARY
Since r34282 (almost 17 years ago) we have been carrying the alias 'CC'
for 'c++, to invoke the C++ compiler. The original reason in O'Brien's
commit message is for
dim updated this revision to Diff 3900.
dim added a comment.
Added one more instance of CC.1.
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D1932?vs=3899id=3900
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1932
AFFECTED FILES
ObsoleteFiles.inc
On 11 Feb 2015, at 22:17, Craig Rodrigues rodr...@freebsd.org wrote:
We currently have a Jenkins job which checks out llvm trunk and builds
it like this:
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm
./configure --enable-optimized --disable-assertions --disable-docs
dim added a subscriber: dim.
dim accepted this revision.
dim added a reviewer: dim.
dim added a comment.
This revision is now accepted and ready to land.
LGTM.
REVISION DETAIL
https://reviews.freebsd.org/D1663
To: emaste, dim
Cc: dim, freebsd-toolchain
dim closed this revision.
dim updated this revision to Diff 3155.
dim added a comment.
Closed by commit rS277146 (authored by @dim).
REVISION DETAIL
https://reviews.freebsd.org/D1505
AFFECTED FILES
head/etc/mtree/BSD.debug.dist
head/etc/mtree/BSD.usr.dist
head/lib/Makefile
dim updated this revision to Diff 3131.
dim added a comment.
Avoid specifically listing architectures.
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D1505?vs=3130id=3131
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1505
AFFECTED FILES
etc/mtree/BSD.debug.dist
dim added a comment.
Minor note: this survived a make universe on one of the FreeBSD.org reference
machines.
REVISION DETAIL
https://reviews.freebsd.org/D1505
To: dim, andrew, bapt, emaste, imp
Cc: freebsd-toolchain
___
dim created this revision.
dim added reviewers: andrew, bapt, emaste, imp.
dim added a subscriber: freebsd-toolchain.
REVISION SUMMARY
I added the libclang_rt libraries (Address Sanitizer, Undefined Behavior
Sanitizer and Profile Guided Optimization) from compiler-rt to the tree
recently,
dim accepted this revision.
dim added a comment.
Yes, this looks fine. Though it would be nice to somehow make use of some of
these routines? E.g., clang can possibly insert calls to quicker VFP based
primitives, if you compile with the correct CPU settings.
BRANCH
/head
REVISION DETAIL
dim closed this revision.
dim updated this revision to Diff 3035.
dim added a comment.
Closed by commit rS276783 (authored by @dim).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1446?vs=3033id=3035#toc
REVISION DETAIL
https://reviews.freebsd.org/D1446
AFFECTED FILES
dim commandeered this revision.
dim edited reviewers, added: andrew; removed: dim
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1446
To: dim, emaste, andrew
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing list
dim added inline comments.
BRANCH
/head
INLINE COMMENTS
lib/clang/clang.build.mk:33 That should not be arm53, but arm64,
obviously.
REVISION DETAIL
https://reviews.freebsd.org/D1446
To: andrew, emaste, dim
Cc: freebsd-toolchain, emaste
___
On 16 Dec 2014, at 16:58, David Chisnall thera...@freebsd.org wrote:
On 16 Dec 2014, at 15:46, Ed Maste ema...@freebsd.org wrote:
One of goals for the toolchain prior to the FreeBSD 11 branch is to
create a libllvm.so and libclang.so for use by all of the LLVM family
tools installed in the
On 16 Dec 2014, at 17:15, David Chisnall thera...@freebsd.org wrote:
On 16 Dec 2014, at 16:04, Dimitry Andric d...@freebsd.org wrote:
This is precisely why the libs should go into /usr/lib/private, so as to
avoid collisions with any upstream libraries installed by e.g. ports (or
when you
On 18 Nov 2014, at 21:05, Dmitry Marakasov amd...@amdmi3.ru wrote:
* Dimitry Andric (d...@freebsd.org) wrote:
This seems to be same issue as in
http://llvm.org/bugs/show_bug.cgi?id=20893 for which there is patch
review going
on
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon
On 11 Nov 2014, at 20:04, Chris H bsd-li...@bsdforge.com wrote:
...
But sadly. blowing away ports, src, and obj. Then checking out
src r274382, and performing a buildworld. Although I got further.
it bombed at:
=== usr.sbin/hyperv (all)
=== usr.sbin/hyperv/tools (all)
cc -O2 -pipe
On 06 Nov 2014, at 18:26, Craig Rodrigues rodr...@freebsd.org wrote:
On Thu, Nov 6, 2014 at 9:13 AM, Arthur Mesh am...@juniper.net wrote:
/usr/bin/ld: /usr/bin/../lib/libprofile_rt.a: No such file: No such file
or directory
Prokash Sinha from Panasas asked the exact same question:
On 22 Sep 2014, at 04:20, Rui Paulo rpa...@me.com wrote:
On Sep 21, 2014, at 18:48, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote:
On Sep 21, 2014, at 18:19, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
#include
On 18 Sep 2014, at 01:01, Will Andrews w...@freebsd.org wrote:
I see there have been a lot of updates fixes to elftoolchain since
the last import into FreeBSD/head nearly 8 months ago. Are there any
plans to update the import?
I'm asking because it appears that ctfconvert currently crashes
On 12 Sep 2014, at 22:52, Andrey Chernov a...@freebsd.org wrote:
On 13.09.2014 0:44, Andrey Chernov wrote:
On 12.09.2014 22:40, Andrey Chernov wrote:
I don't have -current i386 combination, but I can try -current x64
later (with different -march).
It works on -current, amd64,
On 13 Sep 2014, at 20:00, Andrey Chernov a...@freebsd.org wrote:
On 13.09.2014 20:45, Dimitry Andric wrote:
After some massaging of gcc's source to disable its built-in segfault
handlers, I get this backtrace:
Do you get this with my core or finally able to reproduce it by yourself?
I
On 06 Sep 2014, at 05:16, Warner Losh i...@bsdimp.com wrote:
On Sep 5, 2014, at 8:21 PM, Garrett Cooper yaneurab...@gmail.com wrote:
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
On 29 Aug 2014, at 18:31, Sinha, Prokash psi...@panasas.com wrote:
I was trying to build the latest from the svn trunk - clang/llvm -
langAttrEmitter.cpp:994:29: error: 'SimpleArgument' does not refer to a value
Ptr = llvm::make_uniqueSimpleArgument(Arg, Attr, int);
On 11 Jun 2014, at 20:53, Craig Rodrigues rodr...@freebsd.org wrote:
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:
On 11 Jun 2014, at 21:56, Craig Rodrigues rodr...@freebsd.org wrote:
On Wed, Jun 11, 2014 at 12:30 PM, Dimitry Andric d...@freebsd.org wrote:
On 11 Jun 2014, at 20:53, Craig Rodrigues rodr...@freebsd.org wrote:
Recently when trying to debug some coredumps in CURRENT from
a userland process
On 19 Mar 2014, at 21:00, Dimitry Andric d...@freebsd.org wrote:
On 19 Mar 2014, at 10:58, Andriy Gapon a...@freebsd.org wrote:
I observe the following minor annoyance on FreeBSD systems where cpp is GCC's
cpp. If a DTrace script has the following shebang line:
#!/usr/sbin/dtrace -Cs
On 23 Mar 2014, at 17:59, Warner Losh i...@bsdimp.com wrote:
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?
I hope the latter, but I didn't investigate yet. I do know that I ran a
On 19 Mar 2014, at 10:58, Andriy Gapon a...@freebsd.org wrote:
I observe the following minor annoyance on FreeBSD systems where cpp is GCC's
cpp. If a DTrace script has the following shebang line:
#!/usr/sbin/dtrace -Cs
then the following warning is produced when the script is run:
cc1:
On 18 Mar 2014, at 16:38, Tijl Coosemans t...@freebsd.org wrote:
With -fms-extensions clang 3.4 seems to define a built-in type named
__wchar_t. This conflicts with __wchar_t in /usr/include/machine/_types.h
% cat test.c
#include sys/types.h
% cc -c test.c -fms-extensions
In file
On 01 Jan 2014, at 23:32, Dimitry Andric d...@freebsd.org wrote:
I have almost completed the preliminary work to import clang 3.4 into
FreeBSD 11-CURRENT. The official clang 3.4 release has not yet been
announced, but I do not expect any more changes from upstream for now.
However, since
On 12 Jan 2014, at 13:12, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote:
buildworld is failed when WITH_LLDB=
Yes, this is a known issue. I discussed it with Ed Maste. Clang 3.4
will have to be imported first, afterwards we can fix lldb.
some ports cannot build.
reason1: clang cannot
On 05 Jan 2014, at 13:06, Ed Schouten e...@80386.nl wrote:
2014/1/1 Dimitry Andric d...@freebsd.org:
Another important new issue is that clang 3.4 now outputs DWARF4 as
default format when using -g. Our ancient version of gdb in base does
not support this, so you must either install the gdb
On 02 Jan 2014, at 01:11, Dimitry Andric d...@freebsd.org wrote:
On 01 Jan 2014, at 23:37, Warner Losh i...@bsdimp.com wrote:
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
Hi,
I have almost completed the preliminary work to import clang 3.4 into
FreeBSD 11-CURRENT. The official clang 3.4 release has not yet been
announced, but I do not expect any more changes from upstream for now.
However, since this version introduces a bunch of new warnings, and a
more strict
On 19 Nov 2013, at 09:10, Matthias Andree mand...@freebsd.org wrote:
Am 19.11.2013 08:49, schrieb Dimitry Andric:
...
Ok, this looks like http://llvm.org/PR16474 , which has a relatively
simple fix. I have attached it, can you please try it out? You can
just apply the patch to /usr/src
On 19 Nov 2013, at 11:27, Dimitry Andric d...@freebsd.org wrote:
On 19 Nov 2013, at 09:10, Matthias Andree mand...@freebsd.org wrote:
Am 19.11.2013 08:49, schrieb Dimitry Andric:
...
Ok, this looks like http://llvm.org/PR16474 , which has a relatively
simple fix.
...
Excellent, problem
On 18 Nov 2013, at 23:25, Matthias Andree mand...@freebsd.org wrote:
Am 18.11.2013 23:04, schrieb Dimitry Andric:
I will have a look at the port meanwhile, I hope it does not pull in too
many dependencies?
Thanks for the prompt response. Trying top-of-clang-tree will take me a
few days
On 18 Nov 2013, at 23:54, Matthias Andree mand...@freebsd.org wrote:
...
Uploaded. http://people.freebsd.org/~mandree/ has:
http://people.freebsd.org/~mandree/ipsharpen.ii.xz: the xzipped .ii
file (unpacked: 6.5 MB)
http://people.freebsd.org/~mandree/ipsharpen-compile%2bwarnings.txt:
On 17 Nov 2013, at 20:37, Warner Losh i...@bsdimp.com 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
On Oct 22, 2013, at 15:05, sq...@peralex.com wrote:
I'm running current, and I've managed to compile, but not link some code
using -sanitizer=memory. The linker is missing some symbols
(__msan_memcpy and others), and I can't find the appropriate library.
I've found no mention of anybody using
On Sep 2, 2013, at 21:40, Tijl Coosemans t...@freebsd.org wrote:
I was trying to build multimedia/x264 using clang as follows:
In the Makefile remove USE_GCC=any.
In option dialog on leave PGO on.
It ends in the following linker error:
cc -o x264 x264.o input/input.o input/timecode.o
On Jul 11, 2013, at 19:19, Andriy Gapon a...@freebsd.org wrote:
on 11/07/2013 19:43 Andriy Gapon said the following:
buildword was run as make -j8 buildworld and the it mysteriously failed like
this:
sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80
On May 27, 2013, at 21:12, Rui Paulo rpa...@felyko.com wrote:
On 27 May 2013, at 09:41, Pedro Giffuni p...@freebsd.org wrote:
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 in that were left
when similar intel
On May 14, 2013, at 02:35, Alexander K. Beros a...@154cm.com wrote:
I have just started using clang (on FreeBSD 9.1 AMD64) and encountered a
couple problems. I have worked around these points, but in case they
represent something unintentional (as opposed to some error on my part while
On 2013-05-06 10:39, David Chisnall wrote:
On 6 May 2013, at 01:27, John-Mark Gurney j...@funkthat.com wrote:
One question I have is that I copied wmmintrin.h from clang... It has a
license statement, but no copyright statement... Do I need to add one
from somewhere?
The clang headers are
On 2013-05-03 03:08, Kennith Caudill wrote:
1.) Processor affinity with C++11 threads
Will there be a standard non-hackish way to set processor affinity on C++11
std::threads?
This would be a great feature imho. I admit that I haven't researched this and
maybe it's
possible to use the
On 2013-03-07 18:24, Tijl Coosemans wrote:
Whatever the command line arguments, running c89 almost always results in
the following output. Anyone else seeing this?
c89: illegal option -- 1
usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ...
[-o outfile]
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 sure I buy that argument; if it were so, we should default to
KR
On 2013-02-09 17:03, lini...@freebsd.org wrote: Old Synopsis: CLang does not
define __STDC_ISO_10646__, despite having Unicode in wchar_t
New Synopsis: clang does not define __STDC_ISO_10646__, despite having Unicode
in wchar_t
Responsible-Changed-From-To: freebsd-bugs-freebsd-toolchain
On 2013-02-04 23:12, Pedro Giffuni wrote:
On 02/04/2013 17:03, Hongli Lai wrote:
Any progress on fixing this issue?
I think there is a fix (and a fix to the fix) in -current.
I have merged the necessary fixes to stable/9 in r246368.
___
On 2013-02-01 16:28, Yamaya Takashi wrote:
On 2013/02/01 08:03, Yamaya Takashi wrote:
After r246028, make buildworld with -stdlib=libc++ -std=c++11 is failed.
libcxxrt's Version.map is broken, because some needed symbols are removed.
Add missing symbol and refine.
Thank you very much. I
On 2013-02-01 15:46, Pedro Giffuni wrote:
On 02/01/2013 08:01, Andriy Gapon wrote:
on 28/01/2013 17:11 Andriy Gapon said the following:
I wonder why the following is the case for the base gcc.
/usr/include/c++/4.2/bits/c++config.h:
/* Define if C99 functions or macros from wchar.h, math.h,
On 2013-01-25 21:54, Pedro Giffuni wrote:
...
I am aware a fix is being worked on. I think that as long as
the default compiler/C++ library works it is OK to make things
easier for other compilers. I am OK with having that change in
-current but for 9.x it is simply unacceptable.
Actually,
On 2013-01-15 20:35, John-Mark Gurney wrote:
If you try to compile the following file:
#include wmmintrin.h
__m128i
bar(__m128i a, __m128i b)
{
return _mm_aesenc_si128(a, b);
}
w/ the command:
clang -D__AES__ -c intrintest.c
You'll get the error:
fatal error: error in backend: Cannot
On 2012-12-22 04:15, Gerald Pfeifer wrote:
If someone wants to have a look, this was on
10.0-CURRENT FreeBSD 10.0-CURRENT #6 r243901: Wed Dec 5 21:18:57 UTC 2012
with
FreeBSD clang version 3.2 (branches/release_32 168974) 20121130
Attached you'll find the log and two trace files created
On 2012-11-25 18:31, Dimitry Andric wrote:
...
I have posted a proposed patch to the upstream mailing list here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121119/068587.html
If it is accepted as-is, I will merge it immediately.
Upstream committed the patch after some
On 2012-09-16 01:22, Luigi Rizzo wrote:
...
the fact that the difference is so small is interesting,
and it might almost suggests that the test is dominated by
other factors than the compiler.
Yes, this result was more or less what I expected: runtime performance
is probably related more to
On 2012-09-11 15:24, Steve Kargl wrote:
...
How fast clang builds world in comparison to gcc is irrelevant.
Not at all irrelevant: this proposal is about changing the default
compiler for the FreeBSD system itself, not for all software out there.
If certain software performs significantly
On 2012-09-11 16:27, Tijl Coosemans wrote: On 11-09-2012 16:10, Dimitry Andric
wrote:
...
Yes, maths support, specifically precision, is admittedly still one of
clang's (really llvm's) weaker points. It is currently not really a
high priority item for upstream.
This is obviously something
On 2012-07-24 11:02, Erik Cederstrand wrote:
I'm creating a FreeBSD port for MCLinker (http://code.google.com/p/mclinker/)
in preparation of MCLinker working without patching LLVM, and testing
MCLinker as a system linker when it gets far enough.
In the configure stage, MCLinker needs to
On 2012-07-06 22:44, Warner Losh wrote:
...
The reasons are that /usr/local/include superceds anything in /usr/include.
This is dangerous. Users should get just the system default libraries and
headers when they compile unless they ask for more. That's what makes it
stupid.
Well, one
On 2012-05-20 19:34, Bruce Cran wrote: I've done a fresh install of FreeBSD
9.0, upgraded to 10-CURRENT and
have just tried doing a rebuild with CLANG_IS_CC=yes in src.conf.
However there's an error building ncurses:
cc: unrecognized option '-Qunused-arguments'
cc: unrecognized option
On 2012-05-17 17:44, Pedro Giffuni wrote: Hi;
I took a bunch of patches that were merged into the GCC 4.1 branch
(under GPLv2) and prepared a patch for merging them into our base
gcc. These are supposed to be bug fixes only.
You can get the patch here:
On 2012-02-26 22:37, Alexander Best wrote:
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 globally
- src.conf = applies
On 2012-02-26 23:38, Warner Losh wrote:
On Feb 26, 2012, at 2:37 PM, Alexander Best wrote:
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:
-
On 2011-12-26 11:10, Alexander Best wrote:
that's why i'd like to propose the following patch. i ran a full tinderbox run
against r228878 and it suceeded.
Did you also try this with clang? For example the xfs module alone gets
a whole slew of warnings, which would be fatal if WERROR= was
On 2011-12-30 14:28, David Chisnall wrote:
On 30 Dec 2011, at 13:06, Dimitry Andric wrote:
sys/gnu/fs/xfs/xfs_dir2_block.c:1149:17: warning: array index of '1' indexes
past the end of an array (that contains 1 element) [-Warray-bounds]
I recall some discussion of this warning on the clang
On 2011-11-08 01:25, Alexander Best wrote:
i've seen dozens of issues, where people set CPUTYPE=native. although this
works in a lot of cases, it doesn't in others. why don't we simply add
something like
. if ${CPUTYPE} == native
. error bla
. endif
in share/mk/bsd.cpu.mk for now? or
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 would be to
make such an error into a warning.
Sorry, but checking something unsigned to be smaller than zero is bogus,
On 2011-08-23 11:23, Alexander Best wrote:
...
The patch fixes this by adding -ECC -ECXX -EAS -ELD to the build32
sub-make invocation, which forces those environment variables to always
override any assignment in makefiles.
It makes it possible to simply do:
CC=clang
CXX=clang++
in your
On 2011-08-18 07:01, Alexander Best wrote:
i'm getting this error, when trying to make target buildwork with clang.
You mean with make target buildwork, that you are running make
buildworld TARGET=whatever, right?
...
this is the error i'm getting:
=== lib/csu/i386-elf
On 2011-08-18 19:35, Alexander Best wrote:
...
ld: Relocatable linking with relocations from format elf64-x86-64-freebsd
(crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
Most likely, this is because you are forcing CC=clang, which does not
work as expected. Can you please
On 2011-07-21 14:17, Julian H. Stacey wrote:
Summary:
I found a problem with CFLAGS += -march=i586 on an i686 linking
a crt.o for an i686, then not running on an i586,
IMHO this is a bit of a PEBKAC issue. If you change CPUFLAGS to target
a specific CPU, you should really rebuild all of
On 2011-04-15 01:41, Alexander Best wrote:
per coincidence i discovered the following contrary behavior between gcc and
clang:
-mno-mmx implies -mno-3dnow under gcc. under clang -mno-mmx will *not* imply
-mno-3dnow!
is this a clang design feature or a bug? fixing it would be trivial (see
On 2011-01-09 15:31, Alexander Best wrote:
...
i really cannot spot the problem on my system. :(
...
In file included from /usr/subversion-src/usr.bin/make/parse.c:75:
/usr/local/bin/../lib/clang/2.9/include/stdarg.h:47:9: warning:
'__GNUC_VA_LIST' macro redefined
#define __GNUC_VA_LIST 1
On 2010-12-17 15:10, Erik Cederstrand wrote:
Den 17/12/2010 kl. 15.02 skrev Roman Divacky:
On Fri, Dec 17, 2010 at 02:58:34PM +0100, Erik Cederstrand wrote:
It is my understanding that -integrated-as is supposed to work for ELF on
FreeBSD now. Is anybody working on supporting this flag for
101 - 179 of 179 matches
Mail list logo
