Re: Is it possible for freebsd 13 to update to LLVM 11.1.0?

On 28 May 2021, at 08:39, YUANRUI wrote: > > Is it possible for freebsd 13 to update to LLVM 11.1.0? There isn't much use in updating LLVM to 11.1.0, as this version only fixes an LLVM ABI issue that is not important for us. I am currently working on updating LLVM to 12.0.0 (and later 12.0.1

Re: Looking for std::map::erase_if

Well, -std=c++20 even, it is that new. :) That said, it's always hazardous to rely on experimental features, they are effectively unsupported. As shown on e.g. cppreference.com, you can use an equivalent function that looks like: auto old_size = c.size(); for (auto i = c.begin(), last =

Re: clang options for load segments

On 19 Feb 2021, at 15:18, Paul Floyd wrote: > > A while back when I upgraded to FreeBSD 12.2 (and thus to clang 10) I got > quite a new category of errors with Valgrind. > > The problem is that the clang 10 toolchain produces two RW LOAD segments, for > instance see below. Valgrind assumes >

Re: devel/glib20 build issue

On 9 Dec 2020, at 12:44, Kristof Provost wrote: > > On 19 Nov 2020, at 11:59, Dimitry Andric wrote: >> On 19 Nov 2020, at 11:57, Kristof Provost wrote: ... > This https://reviews.llvm.org/D91784 got merged upstream. How do you feel > about cherry-picking that into o

Re: devel/glib20 build issue

On 19 Nov 2020, at 11:57, Kristof Provost wrote: > > While trying to build assorted ports on RISC-V I found that devel/glib20 > doesn’t build. > It turns out to be due to a missing __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 > define. That define is implicitly set by the toolchain. Or, at least, it is

Re: clang miscompiles OpenLibm on i686-*-freebsd

On 8 Sep 2020, at 19:47, Steve Kargl wrote: > > On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote: >> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote: >>> >>> Interval tested for exp2f: [1,8] >>> ulp <= 0.5: 0.056% 14072 | 0.056% 14072 >>> 0.5 < ulp <

Re: Undefined reference to __bswapsi2/__bswapdi2

On 20 Aug 2020, at 19:52, Gleb Popov wrote: > > On Wed, Aug 19, 2020 at 10:15 PM Gleb Popov wrote: > >> Hi toolchain@ >> >> I'm building the latest GHC on 12.1-RELEASE i386 and having almost the >> same problem as with atomic functions. This time the error is >> >> d: error: undefined

Re: RO Elf program headers

On 2020-02-23 16:31, Paul Floyd wrote: > I’ve been working on getting Valgrind to work again on FreeBSD. > Probably the biggest problem at the moment is that Valgrind doesn’t (yet) > handle the read-only program headers. > If I run “readelf -l libc++.so.1.0” on Linux I see two LOAD headers, the

[Differential] D22061: Build toolchain components as dynamically linked executables by default

dim created this revision. dim added reviewers: emaste, imp, jhb, kib. Herald added a subscriber: bdrewery. Herald added a reviewer: manpages. REVISION SUMMARY Historically, we have built toolchain components such as cc, ld, etc as statically linked executables. One of the reasons being that

Re: amd64 head -r351153 self-built but via devel/llvm90: 'objcopy: elf_update() failed: Layout constraint violation' for gptboot.bin

On 17 Aug 2019, at 05:33, Mark Millard wrote: > > I upgraded to head -r351153 and then attempted a buildworld > buildkernel via devel/llvm90 (rc2 via ports head -r509054), > but that (from scratch) build attempt got: > > --- gptboot.bin --- > objcopy: elf_update() failed: Layout constraint

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain wrote: > This was in a poudriere bulk build on a head -r347549 based powerpc64 > system with system clang 8 for cc and c++ and base/binutils > for the likes of ld. (The system has the llvm libunwind patches > for powerpc64 so throwing

Re: stable/11 discards const qualifiers

On 25 Apr 2019, at 16:01, Dmitry Chagin wrote: > > I'm trying to merge r331056, r331057, r331060, r331356,(by emaste@) to the > stable/11 and get the following error: > > ===> linux (all) > cc -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -fno-strict-aliasing > -Werror -D_KERNEL -DKLD_MODULE

Re: Is this a programming error, or a compiler error..

On 13 Mar 2019, at 12:57, Willem Jan Withagen wrote: > > I'm getting a crash in a Ceph test program in the following pice of code: > > struct entity_addrvec_t { > vector v; > . > entity_addr_t legacy_addr() const { > for (auto& a : v) { > if (a.type ==

Re: clang broken on current?

On 10 Feb 2019, at 06:00, Steve Kargl wrote: > > I have > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386 > > % dmesg | more > ... > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > VT(vga): resolution 640x480 > CPU:

Re: svn commit: r339898 - head/lib/libc/amd64/sys

On 4 Nov 2018, at 08:43, Julian Elischer wrote: > > what's an ifunc? This is a GNU extension, an "indirect function". It allows you to provide multiple different implementations of the same function, for instance optimized for specific CPU types, and choose between them at dynamic link time

Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"

On 12 Oct 2018, at 15:00, Jan Beich wrote: > > Mark Millard writes: >> The following is on a powerpc64 machine (old PowerMac G5 so-called >> "Quad Core") running a personal build of head -r339076 that was >> built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1). >> The compiler for

Re: unknown -z value: common-page-size=4096

On 29 Sep 2018, at 04:08, Shawn Webb wrote: > > On Fri, Sep 28, 2018 at 10:01:31PM -0400, Charlie Li wrote: >> I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64 >> base starting with r338990, and among other issues, ld.lld70 refuses to >> link the kernel: >> >> Building

Re: Broken arm support in clang now?

On 11 Aug 2018, at 19:31, Warner Losh wrote: > > On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote: > On 11 Aug 2018, at 16:55, Warner Losh wrote: > > > > It looks like armv5 clang bogusly uses lld: > > > > From a 'make buildkernel' of the RT1310 kernel confi

Re: Broken arm support in clang now?

On 11 Aug 2018, at 16:55, Warner Losh wrote: > > It looks like armv5 clang bogusly uses lld: > > From a 'make buildkernel' of the RT1310 kernel config: > > cc -target arm-gnueabi-freebsd12.0 > --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp >

Re: Clang 6.0.[01]: UNREACHABLE executed

On 13 Jul 2018, at 18:45, Dimitry Andric wrote: > > On 13 Jul 2018, at 14:30, Jonathan Anderson wrote: >> >> I recently ran into an unreachable statement execution in Clang 6, both >> with v6.0.0 from the llvm60 package and v6.0.1 from HEAD (FreeBSD >> r33579

Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3

On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain wrote: > > On 2018-Jul-12, at 2:44 AM, tech-lists wrote: > >> On 11/07/2018 17:21, Mark Millard wrote: >>> It seems from the quoted material that neither kernel-toolchain nor >>> build world was done before buildkernel . My

Re: svn commit: r334647 - in head: . . . [this broke ci.freebsd.org's FreeBSD-head-amd64-gcc build but via an include/c++/v1/ problem]

On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain wrote: > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows: > > --- all_subdir_usr.sbin/pmc --- > In file included from > /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/ios:216:0, >

Re: Compiling libc with LTO

On 5 Mar 2018, at 00:11, Shawn Webb wrote: > > I'm working on Cross-DSO CFI support in HardenedBSD. I've noticed > certain libraries do not like to be compiled with -flto, libc being > one of them. I'm scratching my head a bit, but unsure where to go from > here, so a

Re: projects/clang600-import and ld.lld

On 12 Jan 2018, at 18:04, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > On Fri, Jan 12, 2018 at 10:26:59AM -0500, Shawn Webb wrote: >> On Fri, Jan 12, 2018 at 04:17:50PM +0100, Dimitry Andric wrote: >>> On 12 Jan 2018, at 15:38, Shawn Webb <shawn.w...@harden

Re: projects/clang600-import and ld.lld

On 12 Jan 2018, at 15:38, Shawn Webb wrote: > > I know it's early in the game, but I thought I'd report this anyways. > I have lld as the default linker (MK_LLD_IS_LD=yes). When lld tries to > link usr.bin/clang/llvm-extract/llvm-extract, lld errors out with some >

Re: Is -march/-mtune=native actually supported on FreeBSD arm* or aarch64?

On 5 Jan 2018, at 06:52, Jan Beich wrote: > > Some ports pass -march=native and/or -mtune=native. Both are extensively > documented by GCC for x86. For other architectures some excerpts say > "native" is only supported on Linux (via /proc/cpuinfo). For example, > > $ uname

Re: ARM broken since a while

On 25 Nov 2017, at 22:10, Pedro Giffuni wrote: > > On 11/25/17 15:28, Pedro Giffuni wrote: >> >> ... >> >> I have seen problems on arm with zstd though. >> > For the record: > arm.armv6 buildworld failed, check _.arm.armv6.buildworld for details > > ===> lib/libzstd

Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

On 27 Oct 2017, at 08:23, Eddy Petrișor wrote: > > I am trying to make the FreeBSD code base build from a Linux host and > found this bit which defines BUILD_TRIPLE in a way which to my > untrained eyes look like overengineering. > > .if ${TARGET_ARCH:Marmv6*} &&

Re: Buildfailures with ld.lld

On 14 Aug 2017, at 19:41, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > On Mon, Aug 14, 2017 at 07:38:28PM +0200, Dimitry Andric wrote: >> On 14 Aug 2017, at 18:40, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: >>> >>> On Mon, Aug 14, 2017 at 07:

Re: Buildfailures with ld.lld

On 14 Aug 2017, at 18:40, Shawn Webb wrote: > > On Mon, Aug 14, 2017 at 07:28:39PM +0300, Johannes Jost Meixner wrote: >> I'm seeing a few `undefined references` trying to build recent base on >> HardenedBSD with clang 5.0.0: >> >> https://dpaste.de/FThb/raw >> >>

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

On 29 Jul 2017, at 01:59, Tijl Coosemans <t...@freebsd.org> wrote: > > On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric <d...@freebsd.org> wrote: >> On 28 Jul 2017, at 13:55, Tijl Coosemans <t...@freebsd.org> wrote: >>> >>> On Thu, 27 Jul 2

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

On 28 Jul 2017, at 13:55, Tijl Coosemans wrote: > > On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote: ... >> In file included from squirrel/squirrel/sqvm.cc:5: >> In file included from /usr/include/c++/v1/math.h:310: >> /usr/include/c++/v1/limits:149:85: error:

Re: amd64 -r321109 -> -r321371 buildworld update failed (spans clang 5 update); error: too few arguments provided to function-like macro invocation; , METAMODE and -j8 was used

On 23 Jul 2017, at 02:02, Mark Millard <mar...@dsl-only.net> wrote: > > On 2017-Jul-22, at 4:50 PM, Dimitry Andric <d...@freebsd.org> wrote: >> On 23 Jul 2017, at 01:32, Mark Millard <mar...@dsl-only.net> wrote: >>> >>> My first attempt to upd

Re: amd64 -r321109 -> -r321371 buildworld update failed (spans clang 5 update); error: too few arguments provided to function-like macro invocation; , METAMODE and -j8 was used

On 23 Jul 2017, at 01:32, Mark Millard wrote: > > My first attempt to update amd64 to a clang 5 based /usr/src > failed ( -r321109 -> -r321371 ). Listing just the first > error initially: > > --- ToolDrivers/llvm-lib/LibDriver.o --- > In file included from >

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

On 29 Jun 2017, at 12:04, Mark Millard wrote: > > [The libc++ code in question appears to not be ready for > 32-bit contexts with 64 bit times. Disable > experimental/filesystem for now? I've submitted > llvm bugzilla 33638 for the issue and have > added it to llvm's 25780,

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

On 21 Jun 2017, at 02:15, Ryan Stone <ryst...@gmail.com> wrote: > > On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric <d...@freebsd.org> wrote: > >> Solution B is problematic because arm_neon.h uses stdint.h types >> extensively. >> > > If I manua

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

On 19 Jun 2017, at 08:46, Mark Millard wrote: > > This is a variant of the wording in bugzilla 220125: > > Unless buildworld (not just kernel-toolchain) is used before > buildkernel the result for arm64 is: > > --- armv8_crypto_wrap.o --- > In file included from

Re: llvm FreeBSD powerpc ABI target bug fix: Re: [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result)

On 4 May 2017, at 21:39, Mark Millard wrote: > > I just got a report of a fix for the FreeBSD > powerpc ABI's code generation in llvm. It should > fix a stack handling related problem that > currently makes clang (through 4) largely useless > for TARGET_ARCH=powerpc . > >

Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?

On 14 Apr 2017, at 22:40, Mark Millard wrote: > > man src.conf (from -r315914 ) reports: > > WITH_LLD_IS_LD > Set to use LLVM's LLD as the system linker, instead of GNU > binutils ld. > > This is a default setting on arm64/aarch64.

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On 30 Mar 2017, at 19:55, Brooks Davis <bro...@freebsd.org> wrote: > > On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote: ... >> >> As said, this is because of WITH_DEBUG. Don't use that for the llvm >> ports, for now. It will also allow you to

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On 30 Mar 2017, at 19:06, Alexey Dokuchaev <da...@freebsd.org> wrote: > > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: >> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote: >>> ... >>> Also interesting was:

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On 29 Mar 2017, at 17:53, Brooks Davis wrote: > > On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote: ... >> This is extreme enough that next time I synchronize >> /usr/ports and it has a devel/llvm40 update I'll >> likely rebuild devel/llvm40 without using

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On 27 Mar 2017, at 23:11, Mark Millard <mar...@dsl-only.net> wrote: > > On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote: >> On 27 Mar 2017, at 12:25, Mark Millard wrote: >>> >>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric <d...@freebsd.org> wrote: &

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On 27 Mar 2017, at 12:25, Mark Millard <mar...@dsl-only.net> wrote: > > On 2017-Mar-27, at 2:41 AM, Dimitry Andric <d...@freebsd.org> wrote: >> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote: ... >>> Installed packages to be REMOVED:

Re: GCC i386 stack misalignment: [package - head-i386-default][graphics/rawtherapee-devel] Failed for rawtherapee-devel-5.0 in stage

On 29 Jan 2017, at 19:35, Matthias Andree wrote: > whenever I've traced one of the attached SIGBUS issues on gcc-compiled > i386 code with SSE2, I found that it was using unaligned 128-bit = > 16-byte wide SSE2 access which also needs 16-byte aligned data > (including

Re: [clang/lld 4.0.0 arm64] link failure in sys/boot/efi/loader

On 23 Jan 2017, at 16:27, Shawn Webb wrote: > > Here's an interesting failure I'm seeing on HardenedBSD with clang 4.0.0 > bits mixed in: > > BEGIN LOG > cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr > -O2 -pipe -DHARDENEDBSD

Re: status of WITH_SHARED_TOOLCHAIN

On 25 Dec 2016, at 19:21, Nikolai Lifanov wrote: > > I would like to understand why WITH_SHARED_TOOLCHAIN is not the default. This has been a long standing tradition. Mainly, because you could theoretically rescue yourself out of some bad situations by being able to

Re: Seeking help with some Clang trouble, compiling ceph

On 21 Oct 2016, at 17:07, Willem Jan Withagen wrote: > > On 21-10-2016 15:09, Willem Jan Withagen wrote: >> Hi, >> >> All this Ceph stuff finally used to compile under FreeBSD. >> And all testss completed correctly. >> >> But somewhere in the Ceph-tree there was a lot of

Re: binutils 2.27 [not working for powerpc64 (and powerpc?)]

Has anyone succeeded in bisecting upstream binutils, to see where this problem was introduced? -Dimitry On 20 Sep 2016, at 22:56, Mark Millard wrote: > > The below forward from freebsd-pcc's list confirms that binutils 2.27 not > working for powerpc64 (& powerpc?)

Re: From llvm: Fwd: [Bug 26856] clang 3.8.0/powerpc/powerpc64's _Unwind_RaiseException code generation has messed up r31 (frame pointer) save/restore code (SEGV's can result) [another issue reported f

On 31 Aug 2016, at 03:17, Mark Millard wrote: > > The below notice from Hal Finkel [via llvm's bugzilla] indicates that at > least part of llvm bug 26856 for powerpc64's is expected to have been fixed > by r280188 (likely on trunk?). I merged the upstream fix to

Re: From llvm: Fwd: [Bug 25780] [META] Using Clang as the FreeBSD/ppc system compiler [one item fixed on trunk]

On 30 Aug 2016, at 08:28, Mark Millard wrote: > > llvm bug 19098 "clang and llvm should support -mminimal-toc and -mlongcall > for PowerPC" has been listed as fixed on llvm's trunk. > > That leaves about 5 pending bugs in the list that the META bug 25780 > currently has.

Re: name conflict after upgrade to HEAD.

On 24 Aug 2016, at 16:30, Willem Jan Withagen <w...@digiware.nl> wrote: > > On 24-8-2016 15:23, Dimitry Andric wrote: ... >> Can you show the full command line used to build the offending source >> file? Usually this is caused by an incorrect include directory search &

Re: name conflict after upgrade to HEAD.

On 24 Aug 2016, at 12:14, Willem Jan Withagen wrote: > > While compile Ceph source code I run into this conflict of the usuage of > 'log' > > Now I've fixed it by prefixing the log with ::log on line 845. > Which works for me, but I'm pretty sure that that is not the best

Re: Problems with out libgcc_s.so in base

On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: > > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl > wrote: ... >> % ldconfig -r | grep libgcc >>6:-lgcc_s.1 => /lib/libgcc_s.so.1 >>735:-lgcc_s.1 =>

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 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 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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 01 Apr 2016, at 00:44, Warner Losh wrote: > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery wrote: >> I didn't realize the ports compiler was defaulting /usr/local/include >> into the search path now. It does not have /usr/local/lib in the >> default

Re: warning: DWARF2 only supports one section per compilation unit

On 29 Mar 2016, at 16:45, Andriy Gapon wrote: > > I've noticed many messages like the following during amd64 buildworld with > very > recent head: > >> warning: DWARF2 only supports one section per compilation unit >> .section .note.GNU-stack,"",%progbits > > Reported

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: 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 24 Mar 2016, at 23:54, Dimitry Andric <d...@freebsd.org> wrote: > > On 24 Mar 2016, at 23:51, Bryan Drewery <bdrew...@freebsd.org> wrote: ... >> It fails without -std=c++11 (there's more discussion in that link and in >> PR 205453). > > Yeah, I also comme

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

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

[Differential] [Accepted] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

dim accepted this revision. dim added a comment. This revision has a positive review. For the rest, LGTM. REPOSITORY rS FreeBSD src repository BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D2690 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/

[Differential] [Commented On] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

dim added inline comments. INLINE COMMENTS usr.sbin/ypbind/ypbind.c:622 While we are here, can we please update this to a post-KR definition? E.g.: static bool_t broadcast_result(caddr_t out, struct sockaddr_in *addr) REPOSITORY rS FreeBSD src repository REVISION DETAIL

[Differential] [Commented On] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

dim added inline comments. INLINE COMMENTS usr.sbin/ypbind/ypbind.c:952 Missing an here? REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D2690 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rodrigc, bapt, emaste,

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

dim added a comment. @imp, so are your concerns now addressed? I didn't expect many ports to fail, and there were just a handful, three of which were actual errors (they indended to run ${CC}, but somebody typo'd CC instead). REPOSITORY rS FreeBSD src repository REVISION DETAIL

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

dim added a comment. An exp-run was requested in bug 200477 https://bugs.freebsd.org/200477. Out of ~25000 ports, only 5 failed, and those have been trivially fixed. The ports tree no longer requires CC to exist. REPOSITORY rS FreeBSD src repository REVISION DETAIL

[Differential] [Updated, 8 lines] D1932: Remove the non-standard CC alias for c++

dim updated this revision to Diff 5715. dim added a comment. This revision now requires review to proceed. Herald added a subscriber: imp. Updated for changes in ObsoleteFiles.inc. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE

[Differential] [Commented On] D2285: gcc 4.9.1 compilation fixes for aesni

dim added a comment. LGTM. REVISION DETAIL https://reviews.freebsd.org/D2285 To: rodrigc, jmg Cc: kostikbel, emaste, dim, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To

[Differential] [Changed Subscribers] D2285: gcc 4.9.1 compilation fixes for aesni

dim added a subscriber: dim. INLINE COMMENTS sys/crypto/aesni/aesni_wrap.c:49 This part seems to be superfluous, since aesencdec.h, just two files above this one, already defines _MM_MALLOC_INCLUDED. REVISION DETAIL https://reviews.freebsd.org/D2285 To: rodrigc, jmg Cc: dim,

[Differential] [Commented On] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

dim added inline comments. BRANCH /head INLINE COMMENTS Makefile.inc1:416 I just looked for the LD=${LD} assignments, and replaced them all. Maybe, for consistency, we should add OBJCOPY=${XOBJCOPY} for the powerpc case too, but I'm not sure if it's used at all in the powerpc build...

[Differential] [Updated, 38 lines] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

dim updated this revision to Diff 4577. dim added a comment. This revision now requires review to proceed. Add XOBJCOPY for powerpc too. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D2187?vs=4554id=4577 BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D2187 AFFECTED

[Differential] [Commented On] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

dim added inline comments. BRANCH /head INLINE COMMENTS Makefile.inc1:427 Btw, I'm not sure about AS here, since it might not even be used in the 32 bit stage, and also I'm not sure of the syntax. Is it -a32? REVISION DETAIL https://reviews.freebsd.org/D2187 To: dim, rodrigc, imp,

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

  1   2   >