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

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

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: 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

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

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

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

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 for now? or

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

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 the clang

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 really be: -

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

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:

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 option

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 to

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

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 obviously something

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

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

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

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,

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

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 wchar.h, math.h,

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

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

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 KR

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

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

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

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

Re: [CFT] gcc: support for barcelona

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

Re: strange stable/9 buildworld failure

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

Re: clang -fprofile-generate

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

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 using

Re: make xdev broken

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

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

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 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:

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

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

[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

Re: [CFT] Update to clang 3.4

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

Re: [CFT] Update to clang 3.4

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

Re: [CFT] Update to clang 3.4

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

Re: [CFT] Update to clang 3.4

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

Re: clang 3.4 -fms-extensions __wchar_t conflicts with our __wchar_t

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

Re: stray warning from gcc's cpp

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:

Re: [releng_10 tinderbox] failure on arm/arm

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

Re: stray warning from gcc's cpp

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

Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

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:

Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

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

Re: Build error

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);

Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary?

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

Re: clang makes segfaulting code with -march=core2 on i386

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,

Re: clang makes segfaulting code with -march=core2 on i386

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

Re: elftoolchain update?

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

Re: Is this a compiler bug?

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

Re: clang and code coverage

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:

Re: Unable to build world w/o clang on 11

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

Re: clang (both 3.3 and 3.4) OOM crashes on HEAD

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

Re: Migration to dynamic libs for llvm and clang

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

Re: Migration to dynamic libs for llvm and clang

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

Re: clang and scanbuild

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

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote: Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed caused by reliance on signed integer wrapping. This diff should fix

Re: Failed to build with external toolchain

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,

Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

On 31 Mar 2015, at 19:17, Craig Rodrigues rodr...@freebsd.org wrote: On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric d...@freebsd.org wrote: ... Yes, this is a bug in libc++, when compiling it with newer versions of gcc. I reported this upstream some time ago: https://llvm.org/PR22771

Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

On 31 Mar 2015, at 22:06, Craig Rodrigues rodr...@freebsd.org wrote: On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric d...@freebsd.org wrote: On 31 Mar 2015, at 21:38, Craig Rodrigues rodr...@freebsd.org wrote: On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric d...@freebsd.org wrote

Re: Failed to build usr.bin/clang/clang with gcc 4.9

On 29 Mar 2015, at 22:39, Craig Rodrigues rodr...@freebsd.org wrote: When building with gcc 4.9, I am getting unresolved symbols at link time when building usr.bin/clang/clang. Here is one error message:

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem

Re: Failed to build with external toolchain

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:

Re: Failed to build with external toolchain

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

Re: clang confuses kgdb on static symbols

On 20 Oct 2015, at 13:38, Andriy Gapon wrote: > > I see exactly the same behavior both kgdb and kgdb710 (devel/gdb with KGDB > option): > (kgdb) p/x intr_cpus > No symbol "intr_cpus" in current context. > (kgdb) p/x 'intr_cpus.0' > $1 = 0xf > > Not sure if clang should try to

Re: ongoing link issues

On 09 Dec 2015, at 17:50, William A. Mahaffey III wrote: > > I am still trying to statically link my inhouse code. I switched to using > g++5 in the link line: ... > g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static >

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

On 09 Jan 2016, at 04:46, Mark Millard <mar...@dsl-only.net> wrote: > > On 2016-Jan-7, at 2:57 PM, Dimitry Andric wrote: ... >> FYI, I have added a -mno-movt option for this purpose upstream, and >> imported a newer snapshot into the clang380-import branch. As of >>

Re: lang/ruby2* build failure on arm

On 20 Nov 2015, at 23:02, Michael Moll <mm...@freebsd.org> wrote: > > On Fri, Nov 20, 2015 at 06:04:53PM +0100, Dimitry Andric wrote: >>> In r384323 (ports) swills@ fixed the build of the lang/ruby2* ports, >>> however, on a recent CURRENT on armv6hf I'm getting

Re: Duplicate OPT_ entries in gcc/options.h

On 08 Jun 2016, at 23:15, Dimitry Andric <d...@freebsd.org> wrote: > > On 08 Jun 2016, at 21:11, Gerald Pfeifer <ger...@pfeifer.com> wrote: ... > Note that GNU awk does *not* produce a different optionlist file when > used with either LANG=C or LANG=en_US.UTF-8. And that

Re: Duplicate OPT_ entries in gcc/options.h

On 09 Jun 2016, at 00:30, Jung-uk Kim <j...@freebsd.org> wrote: > > On 06/ 8/16 06:16 PM, Dimitry Andric wrote: >> On 08 Jun 2016, at 23:54, Jung-uk Kim <j...@freebsd.org> wrote: >>> >>> On 06/ 8/16 05:15 PM, Dimitry Andric wrote: >>>> On 08

Re: Duplicate OPT_ entries in gcc/options.h

On 08 Jun 2016, at 21:11, Gerald Pfeifer wrote: > > I got a user report, and could reproduce this, that building > GCC (lang/gcc, but also current HEAD, so probably pretty much > any version) with FreeBSD 11 and LANG = en_US.UTF-8 we get > conflicting entires in

Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context]

On 28 May 2016, at 06:18, Mark Millard wrote: ... > The -r300886 powerpc64 devel/powerpc64-gcc combination with no clang build > included has failed: > > --- all_subdir_usr.bin --- > endian.h(111): warning: bitwise operation on signed value possibly > nonportable [117] >

Re: clang -pg, libm and the _end symbol

On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: > > I'm reviewing an update to the textproc/miller port in bug 207194, and > noticed it does some ugly things in post-configure to seemingly > work around the following problem (on 11-HEAD at least): > > % echo 'int

Re: projects/clang380-import -r294609: arm buildworld broken by picking up -r294499's disable of clang.lib.mk -mlong-calls use

On 23 Jan 2016, at 06:43, Mark Millard wrote: > > When I tried an rpi2 buildworld for clang380-import -r294609 it failed with > “relocation truncated” problems. (arm7-a cortex-a7 no misaligned accesses as > my context.) > > It looks like this is from picking up

Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld

On 23 Jan 2016, at 12:25, Mark Millard wrote: > > I tried a buildworld that included building clang and lldb based on using > powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It failed, see > below. This might indicate a more general gcc 5.x vs. clang 3.8.0

Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested]

On 20 Feb 2016, at 09:34, Roman Divacky wrote: > Fwiw, I've just committed the patch to clang in r261422. You might want > to keep using a local modification or ask dim@ to import that patch > to our copy of 3.8. I've asked the LLVM release manager to consider merging this

Re: Questions about problems/errors with the include files

On 20 Feb 2016, at 15:31, Willem Jan Withagen wrote: > > Before I actually dump the problem here. > Would this be the place to ask about include files that give errors for > code compiling under GCC but not under Clang 3.7?? > > gcc version 4.8.3 20140911 (Red Hat 4.8.3-9)

Re: confusing messages from clang

On 20 Feb 2016, at 08:33, Alex Denisov <1101.deb...@gmail.com> wrote: >> On 20 Feb 2016, at 01:57, Steve Kargl >> wrote: >> >> If anyone is interesting fixing FreeBSD's C compiler, it >> would be appreciated. ... >> foo.c:21:1: error: use of undeclared

Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque

On 20 Feb 2016, at 16:09, Willem Jan Withagen wrote: > > I'm trying to build a port of Ceph for FreeBSD, which is sort of trying > to shoot at a tank with a watergun :) This is very nice, it would be good to have Ceph on FreeBSD. Note that if you have problems with

Re: Crash in ostream <

On 15 Mar 2016, at 21:50, Willem Jan Withagen <w...@digiware.nl> wrote: > > On 15-3-2016 19:52, Dimitry Andric wrote: ... Most likely a bug in the Ceph code. Try figuring out where the NULL >> pointer originally came from. > > I've started with compiling wit -O0 but

Re: Crash in ostream <

On 15 Mar 2016, at 12:41, Willem Jan Withagen wrote: > > While running Ceph tools I get a crash in > fr 10 > #10 0x016d82ca in FileStore::omap_get_values(coll_t const&, > ghobject_t const&, std::__1::set std::__1::char_traits,

Re: Running Clang 3.7 on Current....

On 11 Mar 2016, at 10:27, Willem Jan Withagen wrote: > > CURRENT has recently received the upgrade to Clang 3.8. > > Now I run into the problem that some of the tests with Ceph are all of a > sudden failing > Mainly manifesting itself because of access errors thru pointers

Re: clang gets numerical underflow wrong, please fix.

On 13 Mar 2016, at 21:10, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote: ... >> So it's storing the intermediate result in a double, for some reason. >> The fnstsw will then result in zero, since t

Re: clang gets numerical underflow wrong, please fix.

On 14 Mar 2016, at 02:53, Steve Kargl wrote: ... > #include > #include > > int > main(void) > { > int i; > float x = 1.f; > i = 0; > feclearexcept(FE_ALL_EXCEPT); > do { > x *= 2; > i++; > printf("%d %e\n", i, x); > }

Re: c++/libc++ help needed for chromium update

On 16 Mar 2016, at 23:36, Dimitry Andric <d...@freebsd.org> wrote: > > On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder <c...@burggraben.net> > wrote: ... >> Could anyone point me in a direction to resolve this? ... > Last but not least, please ask about this

Re: boost/asio/ip/resolver_query_base.hpp:96:3: warning: all paths through this function will call itself

On 25 Mar 2016, at 20:15, Willem Jan Withagen wrote: > Any suggestions why I'm getting this warning/error in the ceph code: > > In file included from log/Log.cc:12: > In file included from /usr/local/include/boost/asio.hpp:63: > In file included from

Re: CXXSTD=c++11

On 25 Mar 2016, at 00:18, Bryan Drewery <bdrew...@freebsd.org> wrote: > > On 3/24/2016 4:16 PM, Dimitry Andric wrote: >> On 24 Mar 2016, at 23:54, Dimitry Andric <d...@freebsd.org> wrote: >>> >>> On 24 Mar 2016, at 23:51, Bryan Drewery <bdrew...@fre

Re: c++/libc++ help needed for chromium update

On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder wrote: > > I'm currently working on updating www/chromium to the latest > version (the 49 versions). Recently (that is, during development > of version 49) the chromium developers allowed some c++11 features > to be used. >

Re: c++/libc++ help needed for chromium update

On 17 Mar 2016, at 12:38, Christoph Moench-Tegeder wrote: ... >> Last but not least, please ask about this on the Chromium mailing lists. >> There must be lots of C++ libraries out there with non-trivial std::pair >> copy constructors, and they must have some sort of

Re: CXXSTD=c++11

On 24 Mar 2016, at 23:36, Bryan Drewery wrote: > > Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds > now? We do this when using an external GCC since it doesn't default to > the c++11 standard quite yet. As far as I understand, we require c++11 >

Re: CXXSTD=c++11

On 24 Mar 2016, at 23:51, Bryan Drewery <bdrew...@freebsd.org> wrote: > > On 3/24/2016 3:45 PM, Bryan Drewery wrote: >> On 3/24/2016 3:44 PM, Dimitry Andric wrote: >>> On 24 Mar 2016, at 23:36, Bryan Drewery <bdrew...@freebsd.org> wrote: >>>> >

  1   2   >