Re: disable -Wtautological-compare for clang

Am 17.10.2011 17:25, schrieb Alexander Best: > any chance we could disable -Wtautological-compare for clang? i don't think > comparing an unsigned int against < 0 is worth a warning. actually it's always > nice to have such a seatbelt, in case somebody changes the type to int and > forgets to intr

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

Am 14.05.2013 02:35, schrieb Alexander K. Beros: > > I have just started using clang (on FreeBSD 9.1 AMD64) and encountered a > couple problems. I have worked around these points, but in case they > represent something unintentional (as opposed to some error on my part while > building from the p

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

Alexander, one more URL for you regarding c++11 on FreeBSD 9.1: ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to

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

[Please keep me in Cc:, I am not subscribed.] Greetings, I have recently spent some efforts getting rawtherapee to compile on 10-stable. I think I succeeded, and came across something I find worth investigating. For just one of rawtherapee's files, clang++ 3.3's compile time is excessively long

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

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 until I get around to it (is clang-devel good enough for a first attempt?)

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

Am 18.11.2013 23:30, schrieb Dimitry Andric: > On 18 Nov 2013, at 23:25, Matthias Andree wrote: >> Am 18.11.2013 23:04, schrieb Dimitry Andric: >> >>> I will have a look at the port meanwhile, I hope it does not pull in too >>> many dependencies? >> >&g

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

Am 19.11.2013 08:49, schrieb Dimitry Andric: > On 18 Nov 2013, at 23:54, Matthias Andree wrote: > ... >> Uploaded. http://people.freebsd.org/~mandree/ has: >> >> <http://people.freebsd.org/~mandree/ipsharpen.ii.xz>: the xzipped .ii >> file (unpacked: 6.5

C++ ABI library incompatibilities c++/stdc++ (was: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port))

Am 19.11.2013 08:39, schrieb Konstantin Belousov: > On Mon, Nov 18, 2013 at 11:54:00PM +0100, Matthias Andree wrote: >> Glib shares the fate, because it defers to std:: containers where possible. >> >> A nice way would require additional work and get the linkers to complain &g

Clang crash on i386 (Fwd: [REL - head-i386-default][graphics/rawtherapee] Failed for rawtherapee-4.0.11_2 in build)

Is this i386-specific compiler crash in clang a known issue? The amd64 build seems fine, by constrast: Can I, for bug reporting purposes, use a different OS or compiler version to derive the

11-CURRENT redports builders miscompiling? (was: svn commit: r370388 - in head: devel/e2fsprogs-libss misc/e2fsprogs-libblkid misc/e2fsprogs-libuuid sysutils/e2fsprogs sysutils/e2fsprogs/files)

Greetings, I have just updated sysutils/e2fsprogs and its slave ports(*), and test drove them on redports. The self-test suite is failing on 11-CURRENT i386 and amd64, but not on 10 or older releases. 11-amd64: https://redports.org/buildarchive/20141007190638-31576 11-i386: https://redports.org

Re: 11-CURRENT redports builders miscompiling?

Am 07.10.2014 um 21:32 schrieb Antoine Brodin: > On Tue, Oct 7, 2014 at 9:26 PM, Matthias Andree wrote: >> Greetings, >> >> I have just updated sysutils/e2fsprogs and its slave ports(*), and test >> drove them on redports. The self-test suite is failing on 11-CURRENT

Re: 11-CURRENT redports builders miscompiling?

Am 07.10.2014 um 22:17 schrieb Antoine Brodin: > So, the test fail on head, but if you look carefully, 1480342*1024 > = 0x5a5a... which looks like malloc junk. Bingo, thanks for the pointer. > But when I turn off malloc debugging ( ln -s 'abort:false,junk:false' > /etc/malloc.conf ) the tests

Re: 11-CURRENT redports builders miscompiling?

Am 07.10.2014 um 23:57 schrieb Matthias Andree: > Am 07.10.2014 um 22:17 schrieb Antoine Brodin: > >> So, the test fail on head, but if you look carefully, 1480342*1024 >> = 0x5a5a... which looks like malloc junk. > > Bingo, thanks for the pointer. > >> But

Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all > 'normal' RISC implementations. SPARCv9 ABI adds some 'special' > instructions (separate from the normal load/store instructions) for > unaligned access, but as said they come with cos

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

Greetings, 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). For rawtherapee in particular, the crash happens in one of the C+

Re: xmlcharent-0.3_2 and iso8879-1986_3 package reinstalls: "pkg: POST-INSTALL script failed"? vs. @xmlcatmgr and Keywords/xmlcatmgr.ucl

Am 11.10.18 um 17:39 schrieb Mark Millard via freebsd-toolchain: > In updating a powerpc64 context after a poudriere-devel bulk run, I > got the following from pkg upgrade . . . > > Installed packages to be REINSTALLED: xmlcharent-0.3_2 (ABI changed: > 'freebsd:12:powerpc:64' -> 'freebsd: