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 wh
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 = c.end(
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
> t
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 our tree
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
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 < 0.6
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 symbol:
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
>
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
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 viola
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 c
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 -
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 == entity_addr_t::TYPE_LEGAC
On 18 Feb 2019, at 12:40, Charlie Li via freebsd-toolchain
wrote:
>
> On 11/12/2018 14:05, Dimitry Andric wrote:
>> head/contrib/libc++/include/type_traits
>>
> The change to the above named file breaks building any C++ code
> containing _Float16 with devel/llvm80-8.0.
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: Int
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 (e.
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 th
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 /us
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 ke
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
> -B/usr/home/imp/obj/usr/home/imp/git/h
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
>> r335799 / L
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
> r335799 / LLVM r335540). I don't see this issue in Clang 5 or in the
> version that ships with macOS
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 understan
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,
>
On 3 Apr 2018, at 22:32, Brooks Davis wrote:
>
> We (mostly Ali) are working on a patch to to split the actual syscalls
> (__sys_) out of libc and into a libsys. For dynamic linking,
> this is fairly straightforward (link libc against libsys, maybe as a
> filter). For static linking, I'm lookin
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 little direction would be he
On 12 Jan 2018, at 18:04, Shawn Webb 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 wrote:
>>>>
>>>> I know it'
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
> unresolved symbols. The log is
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 -p
> armv6
> $ echo
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 (all)
> Assertion fail
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*} && (!defined(CPUTYPE) || ${CPUTYPE:
On 7 Sep 2017, at 01:54, Mark Millard wrote:
>
> When is:
>
> head/lib/clang/freebsd_cc_version.h
>
> supposed to have:
>
> FREEBSD_CC_VERSION
>
> updated? Back on 2016-May-23 Bryan Drewery wrote on the lists:
>
>> A critical note to toolchain developers, or anyone who touches the Clang
>> o
On 14 Aug 2017, at 19:41, Shawn Webb wrote:
>
> On Mon, Aug 14, 2017 at 07:38:28PM +0200, Dimitry Andric wrote:
>> 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'
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
>>
>> Would you know what I am missi
On 29 Jul 2017, at 01:59, Tijl Coosemans wrote:
>
> On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric wrote:
>> On 28 Jul 2017, at 13:55, Tijl Coosemans wrote:
>>>
>>> On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote:
>> ...
>>>>
On 29 Jul 2017, at 18:14, Oleg Lelchuk wrote:
>
> libcxxrt seems to lack some features that are present in libc++abi. If I
> compile this code and link it against libcxxrt:
>
> #include
> #include
>
> int main()
> {
>int&& ref{4};
>std::cout <<
> boost::typeindex::type_id_with
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: expected expression
On 23 Jul 2017, at 11:17, Mark Millard wrote:
>
> [Linking lldb.full via 2.28 of /usr/local/powerpc64-freebsd/bin/ld
> also fails with "exit code 1" (using WIHTOUT_LLD so it gets that
> far). I'll continue via WITHOUT_LLDB.]
...
>
> Here is the lldb.full failure text:
>
> --- all_subdir_usr.bin
On 23 Jul 2017, at 02:02, Mark Millard wrote:
>
> On 2017-Jul-22, at 4:50 PM, Dimitry Andric wrote:
>> 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 -> -r
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
> /usr/src/contrib/llvm/lib/ToolDriver
On 29 Jun 2017, at 19:16, Mark Millard wrote:
>
> On 2017-Jun-29, at 5:54 AM, Konstantin Belousov
> wrote:
>>
>> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote:
>>> One nasty problem with this is that it is not possible to figure out at
>>&g
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, the FreeBSD META for
>
On 21 Jun 2017, at 02:15, Ryan Stone wrote:
>
> On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric wrote:
>
>> Solution B is problematic because arm_neon.h uses stdint.h types
>> extensively.
>>
>
> If I manually modify the arm_neon.h file to instead say this,
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 /usr/src/sys/crypto/armv8/armv8_
On 5 Jun 2017, at 13:09, Konstantin Belousov wrote:
>
> On Mon, Jun 05, 2017 at 01:03:24PM +0300, Konstantin Belousov wrote:
>> I think that toolchain@ is more suitable list for the discussion.
>>
>> On Sun, Jun 04, 2017 at 05:44:31PM -0500, Eric van Gyzen wrote:
>>> _thr_rtld_init() calls memcp
On 25 May 2017, at 23:59, Mark Millard wrote:
>
> Is llvm bugzilla's latest 26519 fix going to make it
> into release/11.1.0 ? This fixes the last known stack
> handling ABI violation for targeting powerpc FreeBSD
> (32-bit).
I just committed it in r318906. It should make 11.1-RELEASE. Would b
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 .
>
> On 2017-May-4, at 12:26
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. When set, these
>
On 5 Apr 2017, at 16:59, Ed Maste wrote:
>
> Here's a fresh update on LLVM's LLD linker in the base system,
> referencing the plan originally posted at the beginning of 2016. This
> work is primarily taking place on amd64 right now, and unless
> otherwise noted these results apply to amd64.
>
>
On 30 Mar 2017, at 19:55, Brooks Davis 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 build them with mu
On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote:
>
> On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
>>> ...
>>> Also interesting was:
>>>
>>> Installed packages to be REMOVED:
>
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 WITH_DEBUG= .
>> I'm more con
On 27 Mar 2017, at 23:11, Mark Millard 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 wrote:
>>>> On 26 Mar 2017, at 23:36, Mark Milla
On 27 Mar 2017, at 12:25, Mark Millard wrote:
>
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
...
>>> Installed packages to be REMOVED:
>>> llvm40-4.0.0.r4
>>>
>>> Number of packages t
On 26 Mar 2017, at 23:36, Mark Millard wrote:
>
> I upgraded from llvm40 r4 to final. An interesting result was
> its creation of a backup package for llvm40-4.0.0.r4:
>
> about 13 cpu-core-hours running pkg create
>
> (Remember: I've been building with WITH_DEBUG= ) Its
> single-threaded statu
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 stacks).
See these very old
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 -DSKEIN_LOOP=111
> -I/usr/s
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 compile yourself out of it,
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 template and trait
>> c
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?) contexts.
>
> Note: Krzyszt
On 06 Sep 2016, at 15:04, Mark Millard wrote:
>
> llvm's bugzilla reports that the stack-handling SVR4 ABI violation for
> TARGET_ARCH=powerpc has been fixed r280705 (likely on trunk)!
I merged the upstream fix to projects/clang390-import:
https://svnweb.freebsd.org/changeset/base/305686
-Dim
On 01 Sep 2016, at 16:58, Mark Millard wrote:
>
> __builtin_dwarf_cfa () is now listed at llvm as fixed for powerpc and
> powerpc64 (r280350, likely on trunk).
I merged the upstream fix to projects/clang390-import:
https://svnweb.freebsd.org/changeset/base/305683
-Dimitry
signature.asc
Des
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 projects/clang390-import:
http
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.
I merged the upstream
On 24 Aug 2016, at 16:30, Willem Jan Withagen 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
>> order. And most
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 solution.
...
>
> In f
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 => /usr/local/lib/gcc6/libgcc_s.so.1
>>
>> Clearly, ldd is looking for 735 but find
On 09 Jun 2016, at 00:30, Jung-uk Kim wrote:
>
> On 06/ 8/16 06:16 PM, Dimitry Andric wrote:
>> On 08 Jun 2016, at 23:54, Jung-uk Kim wrote:
>>>
>>> On 06/ 8/16 05:15 PM, Dimitry Andric wrote:
>>>> On 08 Jun 2016, at 21:11, Gerald Pfeifer wrote:
&
On 08 Jun 2016, at 23:54, Jung-uk Kim wrote:
>
> On 06/ 8/16 05:15 PM, Dimitry Andric wrote:
>> 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,
On 08 Jun 2016, at 23:15, Dimitry Andric wrote:
>
> On 08 Jun 2016, at 21:11, Gerald Pfeifer 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 phenomenon is explained here:
http://www.gnu.
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 $BUILDDIR/gcc/options.h such as
>
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]
> endian.h(127): warning:
On 27 May 2016, at 01:53, Mark Millard wrote:
>
> I do buildworld/buildkernel on a powerpc64 targeting itself via
> lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most part).
> [Getting that lang/powerpc64-gcc installed for self-hosted use does take some
> work-around activit
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 library path as far as I can tell. It's al
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 sections varied (e.g. the
On 25 Mar 2016, at 00:18, Bryan Drewery wrote:
>
> On 3/24/2016 4:16 PM, Dimitry Andric wrote:
>> On 24 Mar 2016, at 23:54, Dimitry Andric wrote:
>>>
>>> On 24 Mar 2016, at 23:51, Bryan Drewery wrote:
>> ...
>>>> It fails without -std=c++11 (the
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 /usr/local/include/boost/asio/ip/basic_resolve
On 24 Mar 2016, at 23:54, Dimitry Andric wrote:
>
> On 24 Mar 2016, at 23:51, Bryan Drewery wrote:
...
>> It fails without -std=c++11 (there's more discussion in that link and in
>> PR 205453).
>
> Yeah, I also commented on PR 205453 in the past, but I still
On 24 Mar 2016, at 23:51, Bryan Drewery 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 wrote:
>>>>
>>>> Is there any problem with forcing -std=c++1
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
> to build clang/libc++.
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 workaround for those.
>
> It'
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.
> Included in those is s
On 16 Mar 2016, at 23:36, Dimitry Andric wrote:
>
> On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder
> wrote:
...
>> Could anyone point me in a direction to resolve this?
...
> Last but not least, please ask about this on the Chromium mailing lists.
> There must be lots
On 15 Mar 2016, at 21:50, Willem Jan Withagen 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 that probably will st
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, std::__1::allocator >,
> std::__1::less,
> std::__1::alloca
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);
> } while(!fetestexcept(FE_OVERFLOW));
> if (feteste
On 13 Mar 2016, at 21:10, Steve Kargl 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 there was no underflow at
>> that poi
On 13 Mar 2016, at 19:25, Steve Kargl wrote:
>
> Consider this small piece of code:
>
> #include
> #include
>
> float
> foo()
> {
> static const volatile float tiny = 1.e-30f;
> return (tiny * tiny);
> }
>
> int
> main(void)
> {
> float x;
> feclearexcept(FE_ALL_EXCEPT);
>
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 in
> very complex
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 main(void) { return 0; }'
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 porting, usually the free
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 identifier 'corrupt'; did you mean
>> 'cry
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) (GCC)
>
> FreeBSD cla
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 into the
3.8 branch. T
On 24 Jan 2016, at 12:20, Mark Millard wrote:
>
> My current trial powerpc64-gcc based buildworld is well past where it stopped
> before (in a clang 3.8.0 part of the build). What I changed in libc++ was
> just a little of __config:
It appears upstream has done approximately the same thing her
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 source code
> mismatch. T
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 base/head’s -r294499 as part of
On 15 Jan 2016, at 23:15, Mark Millard wrote:
>
> My attempted buildworld of -r294096 from amd64 targeting arm for an rpi2
> stopped with:
>
>> --- all_subdir_usr.sbin ---
>> Assertion failed: (Offset <= PieceOffset && "overlapping or duplicate
>> pieces"), function finalize, file
>> /usr/src
On 09 Jan 2016, at 04:46, Mark Millard 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
>> r293384, it now uses the
On 05 Jan 2016, at 19:53, Ian Lepore wrote:
>
> On Tue, 2016-01-05 at 11:35 -0700, Warner Losh wrote:
...
>> There's a projects/clang-380-import that you might want to try...
>
> It's a non-starter for us, because unfortunately they appear to have
> removed support for the -arm-use-movt=0 comman
1 - 100 of 289 matches
Mail list logo
