Please test the binutils-2.17 project branch

Hi all, As you may know, I am working on an update of our in-tree binutils to 2.17.50, the last version that was still under version 2 of the GPL. I have put this in a project branch, which you can checkout from: svn://svn.freebsd.org/base/projects/binutils-2.17 Please try building world and

Re: Please test the binutils-2.17 project branch

On 2010-11-02 19:47, Dimitry Andric wrote: The following arches still have building problems: - arm There is some weird issue that causes the cross-tools ld to segfault during buildworld, when linking a binary blob into a .o file: This particular segfault was a binutils bug, PR7093

Re: Please test the binutils-2.17 project branch

On 2010-11-02 19:47, Dimitry Andric wrote: - ia64 Something in sys/boot/ia64/efi/ldscript.ia64 makes ld complain about mixing ordered and unordered sections: ===> sys/boot/ia64/efi (all) ... /usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: .data

Re: Clang and -frandom-seed

On 2010-11-14 23:29, Erik Cederstrand wrote: I noticed that two consecutive builds of (GCC-built) Clang don't produce identical binaries. This is true for clang, clang++ and tblgen. I asked on the llvm-dev list yesterday, and it turns out it's because GCC uses a random seed on some symbols. Ap

Re: Clang and -frandom-seed

On 2010-11-15 11:10, Erik Cederstrand wrote: I was thinking of something along the same lines. I think we agree that it only needs to be random across files, not across builds. Someone on llvm-dev also suggested using the path (either full or relative to src/) as a seed. The path should relativ

Re: Clang and -frandom-seed

On 2010-11-19 16:51, Erik Cederstrand wrote: Poking around, I decided to add this patch: # svn diff lib/clang/clang.build.mk Index: lib/clang/clang.build.mk === --- lib/clang/clang.build.mk(revision 215422) +++ lib/clang/clang.b

Re: Clang and -frandom-seed

On 2010-11-22 15:05, Erik Cederstrand wrote: .ifdef WITH_DETERMINISTIC CXXFLAGS+=-frandom-seed=\"${.IMPSRC:S/^${.CURDIR}\///}\" .endif to lib/clang/clang.build.mk and "WITH_DETERMINISTIC=true" to src.conf, but apparently the flag isn't being propagated to clang.build.mk. However it is being pi

Re: clang and -mfpmath=387 on ARCH=amd64

On 2010-12-11 12:47, Alexander Best wrote: clang doesn't seem to make use of -mfpmath=387 on ARCH=amd64 and complains about it (e.g. during TARGET=buildkernel). any thoughts about the attached patch? I have compiled two GENERIC kernels on amd64 with and without the -mfpmath=386 option, and tho

Re: -integrated-as status?

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 bui

Re: clang and -mfpmath=387 on ARCH=amd64

On 2010-12-14 21:40, Alexander Best wrote: On Sun Dec 12 10, Dimitry Andric wrote: ... I have compiled two GENERIC kernels on amd64 with and without the -mfpmath=386 option, and those resulted in exactly the same binaries (apart from the compilation timestamp). So I think the whole -mfpmath

Re: clang fails to crossbuild world for i386 on amd64

On 2011-01-04 21:02, Alexander Best wrote: just experienced this failure. the command line i used is right at the end: ... /tmp/cc-dFZCvC.s: Assembler messages: /tmp/cc-dFZCvC.s:33: Error: suffix or operands invalid for `push' Crosscompiling isn't supported (yet) with clang. They're apparent

Re: searchpath for clang

On 2011-01-09 01:50, Alexander Best wrote: i just noticed that when CC is set to clang, target buildworld will honour $PATH, whereas target buildkernel doesn't. shouldn't target buildworld also discarg $PATH? It does discard PATH. See the top Makefile, one of the first things it does is: PATH

Re: searchpath for clang

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

Re: clang and 3dnow(a)

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 attach

Re: [rfc] a few kern.mk and bsd.sys.mk related changes

On 2011-05-31 11:57, Alexander Best wrote: ... however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. The critical option when -O2 is used is -fno-omit-frame-point

Re: [rfc] a few kern.mk and bsd.sys.mk related changes

On 2011-05-31 16:39, Alexander Best wrote: ... ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn'

Re: [rfc] a few kern.mk and bsd.sys.mk related changes

On 2011-05-31 17:26, Alexander Best wrote: ... so how about the following patch? Could you please try to not mix spacing and style changes with functional changes in this patch? It makes it more difficult to review. ___ freebsd-toolchain@freebsd.org

Re: llvm-ia64 is off the ground...

On 2011-06-10 17:38, Marcel Moolenaar wrote: ... Unfortunately, the FreeBSD build doesn't give me goodies like llc or bugpoint so there may be value in adding that to the FreeBSD build as optional or developer-only build targets... These programs are of little use for normal users, or even most

Re: Adding additional llvm/clang goodies

On 2011-06-17 08:48, Roman Divacky wrote: * llvm-rtdyld * macho-dump these two look extra useful on FreeBSD :-P Well, I just took the whole list of utilities under llvm/tools that were built during a normal (./configure && gmake) build of clang. :) But yes, if any of these tools will be guar

Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586

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

Re: [help] rebuild libc failed

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. But failed to build it. I change the current direcotry into hea

Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported

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 (obj,depend,all,

Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported

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 post

Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported

On 2011-08-19 10:01, Alexander Best wrote: On Thu Aug 18 11, Dimitry Andric wrote: ... Please use the following fragment instead, which is recommended on <http://wiki.freebsd.org/BuildingFreeBSDWithClang>: thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP to cl

Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported

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 make

Re: [clang] rtld-elf/rtld.c and stack traces in gdb(1)

On 2011-08-21 11:08, Test Rat wrote: I often get corrupted traces with clang world, the cause seems to be in rtld. ... (gdb) bt #0 0x0008009455ac in ?? () #1 0x000800944fa7 in ?? () After some digging, this turned out to be caused by the empty function r_debug_state() in li

Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings

On 2011-11-03 11:45, Alexander Best wrote: ... > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: > warning: signed shift result (0x2) requires 35 bits to represent, but > 'int' only has 32 bits [-Wshift-overflow] > OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_

Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings

On 2011-11-03 20:03, Alexander Best wrote: > On Thu Nov 3 11, Dimitry Andric wrote: >> On 2011-11-03 11:45, Alexander Best wrote: >> ... >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: >>> warning: signed shift result (0x200

Re: [poc] buildkernel + clang + -Werror

On 2011-11-05 11:21, Alexander Best wrote: > i'm sending this mail to the mailinglist simply to prevent my work being list. > i've experimented with the -Werror and -Wno-error= options and got to the > point > where i was able to compile GENERIC on amd64 with clang: ... Why don't you just use NO_

Re: [poc] buildkernel + clang + -Werror

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

Re: CPUTYPE=native handling

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 f

Re: make cleanworld

On 2011-11-08 21:49, Alexander Best wrote: > 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 > chflags -R 0 /usr/obj/us

Re: CPUTYPE=native handling

On 2011-11-08 22:04, Alexander Best wrote: ... > for me -march=native reports: > > otaku% gcc -march=native -E -v - Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.2 20070831 prerelease [FreeBSD] >

Re: -fstack-protector vs. -fstack-protector-all

On 2011-11-18 15:37, Alexander Best wrote: > what are the reasons for using -fstack-protector instead of > -fstack-protector-all in sys/conf/kern.mk? My guess would be one or more of the following: - The price in performance is too high - The gain in security is too low - Some routines in the ker

Re: svn commit: r228435 - in head/libexec/rtld-elf: . amd64 arm i386 ia64 mips powerpc powerpc64 sparc64

On 2011-12-14 13:24, Gerald Pfeifer wrote: > On Mon, 12 Dec 2011, Kostik Belousov wrote: >> Does anybody on toolchain@ know how to submit the gas change to >> maintainers for inclusion into mainline, or better, can submit it >> himself ? I assume that no copyright assignment is required for this >>

Re: buildworld broken with _WITHOUT_SRCCONF=

On 2011-12-21 13:54, Alexander Best wrote: i just ran into some issues while trying to make buildworld: otaku% make buildworld -- Building an up-to-date make(1) -- "/usr/sha

Re: [rfc] removing/conditionalising WERROR= in Makefiles

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 remov

Re: [rfc] removing/conditionalising WERROR= in Makefiles

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

Re: setting CC/CXX/CPP unconditionally in src.conf

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 real

Re: setting CC/CXX/CPP unconditionally in src.conf

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 = ap

Re: [RFC] Un-staticise the toolchain

On 2012-04-26 13:53, David Chisnall wrote: ... > I did some benchmarks a little while ago, and there was, I think, about a 5% > slowdown on buildworld with a dynamically linked clang vs a statically linked > one on x86-64. Ideally, I'd want the bootstrap compiler to be statically > linked but t

Re: GCC update for testing

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: > http://people.freebsd.org/~pfg/p

Re: WITH_CLANG_IS_CC and unrecognized command line options

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 opti

Re: gcc46 header search path

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

Re: MCLinker and llvm-config

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 t

Re: BSD ld (was Re: MCLinker and llvm-config)

On 2012-07-28 16:15, Pedro Giffuni wrote: > The Elftoolchain project has been developing a BSD ld: > > http://sourceforge.net/apps/trac/elftoolchain/ > > > http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/ld > > > I thought that would be the official FreeBSD implementation. Let's

Re: BSD archive file formats

On 2012-08-06 14:16, Erik Cederstrand wrote: ... > To do that, it would be helpful if our LLVM is updated to something later > than r160433, since our version in CURRENT needs patching for MCLinker to > work. I've asked dim@, but no reply yet. As far I know, we try to follow > official LLVM rele

Re: Clang as default compiler November 4th

On 2012-09-11 09:58, David Chisnall wrote: Clang should default to c89 mode when invoked as cc. I had a patch to do this, but I seem to have misplaced it. I'll try to find or rewrite it in the next couple of days. A lot of the ports failures I saw were due to ports using cc as the default C

Re: Clang as default compiler November 4th

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 bett

Re: Clang as default compiler November 4th

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 obviou

Re: Clang as default compiler November 4th

On 2012-09-15 16:30, Tijl Coosemans wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. Fix committed in .

Compiler performance tests on FreeBSD 10.0-CURRENT

t over 4 percent. Copyright (c) 2012 Dimitry Andric Verbatim copying and redistribution of this entire text are permitted, provided this not

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

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 har

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

On 2012-09-16 07:19, Konstantin Belousov wrote: On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: ... I tried to map the CPUID into more human-friendly family moniker, and it seems that these are Pentium-4 class CPUs. Am I right ? Yes, it is apparently a Nocona model, this is

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

On 2012-09-16 07:25, Garrett Cooper wrote: ... If you can provide the tests, I can rerun it on some Nehalem class workstations I have access to. I unfortunately don't have access to SNB/Romley hardware yet. I did these tests as follows: - Install a recent -CURRENT snapshot on the box (or r

Re: enabling libc++ by default when building with clang

On 2012-09-17 21:10, 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://people.freebsd.org/~broo

More kernel performance tests on FreeBSD 10.0-CURRENT

gcc, -O2 is slightly faster than -O1. ======== Copyright (c) 2012 Dimitry Andric Verbatim copying and redistribution of this entire text are permitte

Re: More kernel performance tests on FreeBSD 10.0-CURRENT

On 2012-09-22 09:35, O. Hartmann wrote: Am 09/21/12 23:39, schrieb Dimitry Andric: ... At least one can say FreeBSD does not suffer from performance drain using the cutting edge clang 3.2 compared with a gcc 4.2.1 compiler, the echo from the past. Well, the main idea of these tests is to

Re: More kernel performance tests on FreeBSD 10.0-CURRENT

On 2012-09-22 14:52, O. Hartmann wrote: ... When we used FreeBSD for scientific work, that was around 1998 - 2002, there were some attempts made to use Intel's icc compiler suite on FreeBSD in the 32Bit Linuxulator. That time I used that compiler only for compiling my modelling software, but ther

Re: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

On 2012-11-23 00:09, Yamaya Takashi wrote: With -std=c++98, -std=c++03 or -ansi, __LONG_LONG_SUPPORTED is not defined. So some functions((lldiv_t, )atoll, strtoll, strtoull, llabs, lldiv, wcstoll, wcstoull) are undeclared. But libc++ headers(cstdlib and cwchar) use them. The general idea of you

Re: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

On 2012-11-24 11:45, David Chisnall wrote: On 23 Nov 2012, at 21:27, Dimitry Andric wrote: Note there are also other problems when compiling libc++ with -std=c++98 and -std=c++03, such as complaints about namespacing and such. I am not entirely sure libc++ is fully supported yet under those

Re: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

On 2012-11-24 11:45, David Chisnall wrote: ... In theory, the libc++ headers that are part of the C++03 spec (i.e. not things like ) should work in C++98 / C++03 mode, however the implementation in libc++ must be compiled in C++11 mode. Minor note: we now use -std=c++0x by default for buildin

Re: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

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

Re: svn commit: r309380 - head/emulators/wine-devel (fwd)

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 by

Re: temp file turd left behind in odd case...

On 2013-01-15 20:35, John-Mark Gurney wrote: If you try to compile the following file: #include __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 select: int

Re: ports/170256: audio/mpg123: SIGNAL 10 (SIGBUS) error

On 2013-01-22 18:13, Jan Beich wrote: The bug probably happens with every .mp3 file. ... And this is caused by a broken .align check in configure.ac: $ echo '.align 3' | clang -c -o /dev/null -x assembler - $ echo '.align 3' | gcc47 -c -o /dev/null -x assembler - {standard input}: Assembler me

Re: Removing default build of gcc

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, clan

Re: base gcc and _GLIBCXX_USE_C99

On 2013-02-01 14: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 , , , , and can be used or exposed. */ /* #undef _GLIBCXX_

Re: [patch]r246028, libcxxrt's Version.map is broken

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 have

Re: base gcc and _GLIBCXX_USE_C99

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 , , , , and ca

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

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. ___ freebsd-tool

Re: bin/175930: clang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t

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 Resp

Re: c89 broken on head?

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] [-

Re: c89 broken on head?

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 K&R

Re: clang: -mno-omit-leaf-frame-pointer

On Mar 30, 2013, at 09:10, Andriy Gapon wrote: > It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply > -mno-omit-leaf-frame-pointer. This is probably a bug. Yes, this is indeed the case. There is even a rather old unresolved PR for it in LLVM's Bugzilla: http://llvm.org

Re: Miscellaneous questions

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 pthread

Re: patch to add AES & PCLMUL intrinsics to gcc

On 2013-05-06 10:39, David Chisnall wrote: On 6 May 2013, at 01:27, John-Mark Gurney 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 all supposed to hav

Re: missing some c++11 support for clang in FreeBSD

On May 14, 2013, at 02:35, Alexander K. Beros 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 > building from the

Re: [CFT] gcc: support for barcelona

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. This actually filled a lot of holes in that were left >> when similar intel support was brought in. >> >>

Re: Should "make -DNOCLEAN buildworld" always rebuild clang?

On May 30, 2013, at 22:49, David Wolfskill wrote: > As some of you may be aware, I track stable/9 daily. (A recent history > of "uname -vp" outputs for stable/9 on my laptop may be seen at > .) > > And lest this message is misin

Re: Should "make -DNOCLEAN buildworld" always rebuild clang?

On May 30, 2013, at 23:19, Dimitry Andric wrote: > On May 30, 2013, at 22:49, David Wolfskill wrote: >> As some of you may be aware, I track stable/9 daily. (A recent history >> of "uname -vp" outputs for stable/9 on my laptop may be seen at >> <http://www.cat

Re: strange stable/9 buildworld failure

On Jul 11, 2013, at 19:19, Andriy Gapon 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 >> /usr/obj/usr/src/

Re: clang looking all over for linux libs [9.2 PRERELEASE]

On Jul 18, 2013, at 14:48, Kurt Lidl wrote: > On 7/17/13 5:33 PM, Roman Divacky wrote: >> Yes, this is because the FreeBSD driver toolchain shares the same >> infrastructure with Linux. So we stat ~200 linux dirs :( >> >> This rys.vlakno.cz/~rdivacky/freebsd-driver.patch proof of concept >> patch

Re: stable/8 kernel-toolchain fails with clang on head

On Aug 23, 2013, at 14:16, Andriy Gapon wrote: > $ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make kernel-toolchain > WITHOUT_CLANG=1 __MAKE_CONF=/dev/null SRCCONF=/dev/null ... > It seems that the problem is specific to stable/8 and is caused by missing > -std=gnu89. And that seems to be ca

Re: clang -fprofile-generate

On Sep 2, 2013, at 21:40, Tijl Coosemans 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 input/raw.o i

Re: i386 clang optimisation problem with stack alignment

On Sep 10, 2013, at 18:34, Tijl Coosemans wrote: > On Tue, 10 Sep 2013 18:16:01 +0200 Tijl Coosemans wrote: >> I've attached a small test program extracted from multimedia/gstreamer-ffmpeg >> (libavcodec/h264_cabac.c:ff_h264_init_cabac_states(H264Context *h)). >> >> When you compile and run it li

Re: gcc failing for mips cross-compile

On Sep 27, 2013, at 22:07, hiren panchasara wrote: ... >> So, following worked: >> sudo make TARGET=mips TARGET_ARCH=mipseb TARGET_CPUARCH=mips toolchain >> >> What does that mean? >> >> how do I get/know 32bit mips setup? Reading https://wiki.freebsd.org/FreeBSD/BuildingMIPS , it seems just "m

Re: clang sanitizers (memory, address, etc)

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 us

Re: make xdev broken

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 > /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:17: > /imp

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

On 18 Nov 2013, at 22:20, Matthias Andree wrote: > [Please keep me in Cc:, I am not subscribed.] > > Greetings, > > I have recently spent some efforts getting rawtherapee to compile on > 10-stable. I think I succeeded, and came across something I find worth > investigating. > > For just one of

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

On 18 Nov 2013, at 23:25, Matthias Andree 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

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

On 18 Nov 2013, at 23:54, Matthias Andree wrote: ... > Uploaded. http://people.freebsd.org/~mandree/ has: > > : the xzipped .ii > file (unpacked: 6.5 MB) > > : > compiler comm

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

On 19 Nov 2013, at 09:10, Matthias Andree 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 pat

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

On 19 Nov 2013, at 11:27, Dimitry Andric wrote: > On 19 Nov 2013, at 09:10, Matthias Andree 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,

[CFT] Update to clang 3.4

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 o

Re: [CFT] Update to clang 3.4

On 01 Jan 2014, at 23:37, Warner Losh 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, we'll need to call them out since 10.0 hasn't been released yet > and there's s

Re: [CFT] Update to clang 3.4

On 02 Jan 2014, at 01:11, Dimitry Andric wrote: > On 01 Jan 2014, at 23:37, Warner Losh 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 pat

Re: [CFT] Update to clang 3.4

On 02 Jan 2014, at 22:36, Dimitry Andric wrote: > On 02 Jan 2014, at 01:11, Dimitry Andric wrote: >> On 01 Jan 2014, at 23:37, Warner Losh 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 sti

Re: [CFT] Update to clang 3.4

On 05 Jan 2014, at 13:06, Ed Schouten wrote: > 2014/1/1 Dimitry Andric : >> 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 gd

Re: [CFT] Update to clang 3.4

On 12 Jan 2014, at 13:12, Yamaya Takashi 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 handle some options. >

  1   2   3   >