Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions?

This is a known problem with the GCC runtime libraries. GCC 4.3 and later have a much better exemption (which talks about any eligible compilation process, rather than being compiled with GCC), but those are GPLv3 and so unacceptable for FreeBSD. I don’t believe that we are using any of those

Re: 11.1-RELEASE has issue with system headers in pedantic mode (type nullability specifier)

On 7 Aug 2017, at 16:20, Maxim Sobolev wrote: > > One way to defeat this would be to mark those headers with the #pragma > clang system_header. As per: > > https://clang.llvm.org/docs/UsersManual.html#id27 That won’t fix the issue, because base (as you can see from the

Re: libcxxrt seems to lack some features that are present in libc++abi

On 29 Jul 2017, at 17:55, Dimitry Andric wrote: > > The demangler in libcxxrt is indeed rather old, and we should replace it > with something newer. I'm not sure if the demangler of libc++abi is the > right one yet, since upstream seems to still be discussing which of > their

Re: suggestion for toolchain to have its own directories

On 30 Jun 2017, at 21:35, Sid wrote: > > Wouldn't it make sense for toolchains, compilers and their libraries to have > their own dedicated top level directories like something under > /usr/toolchain/ and /usr/local/toolchain/ in the latest FreeBSD versions? It > would be

Re: Function attribute for optimization level

On 5 Jun 2017, at 20:57, Jilles Tjoelker wrote: > > I would prefer using -ffreestanding or -fno-builtin only for the files > which need it. For example, builtin memcpy() with a small constant size > is useful to read and write data regardless of alignment and type-based >

Re: status of WITH_SHARED_TOOLCHAIN

On 25 Dec 2016, at 19:21, Nikolai Lifanov wrote: > > Hi list, > > I would like to understand why WITH_SHARED_TOOLCHAIN is not the default. > My Raspberry Pi 3 is self-hosting with -j4 and doesn't run out of memory > if the toolchain is shared. Is there a downside to this

Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work?

On 2 Dec 2016, at 08:12, Mark Millard wrote: > > [Reminder of my context: these amd64 efforts are really > trying to make sure that I interpret powerpc family behavior > correctly for C++ exception handling. Still it may be that > there are other useful side-effects of my

Re: base/binutils (from ports/head -r424540) requires "gcc" to be a valid command on the host environment

On 9 Nov 2016, at 03:33, Mark Millard wrote: > > base/binutils for my attempted powerpc64 cross build target [from amd64 head > -r308247M] failed for lack of a "gcc”: OS X (sorry, macOS) works around this by installing gcc as a symlink to clang. I wonder if that’s

Re: Time to enable partial relro

On 26 Aug 2016, at 15:18, Warner Losh wrote: > > So what's the summary of why we'd want to do that? What benefit does it bring? > Sure, other folks do it, but why? It reduce the attack surface for code reuse attacks: non-PLT GOT entries are read-only and so can’t be

Re: Time to enable partial relro

On 26 Aug 2016, at 11:56, Konstantin Belousov wrote: > >> I think it's time to enable it be default in our base binutils. If >> there are no objections, I will just commit the attached patch over >> the weekend. > > There are objections, the change must be runtime tested on

Re: Problems with our libgcc_s.so in base [FYI: armv6 C++/g++6 example under stable/11 -r304029]

On 21 Aug 2016, at 22:23, Mark Millard wrote: > > On armv6 (an rpi2) C++ by itself can have /lib/libgcc_s.so.1 not being > sufficient, for example with g++6 being used: > >> # g++6 -std=c++14 -O2 cpp_clocks_investigation.cpp >> # ldd a.out >> a.out: >>

Re: Update on using LLVM's lld linker in the FreeBSD base system

On 2 Aug 2016, at 05:19, Ed Maste wrote: > >>> 6. Request ports exp-runs and issue a call for testing with 3rd party >>> software. Fix issues found during this process. >> >> Experience suggests this may be the long poll :) > > Indeed, and that's a big part of my motivation

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

On 18 Mar 2016, at 17:22, Dimitry Andric wrote: > > We > could enable this feature, but then we'd have to bump our libc++ > version, together with all the followup hassle. There are quite a few ABI-breaking changes in libc++. Some improve standards compliance and a few

Re: confusing messages from clang

C compilers are always doing best effort attempts to report when you feed them code that is not valid C. For example, in this case: On 20 Feb 2016, at 00:57, Steve Kargl wrote: > if (i > 0) > goto corrupt; This is valid, as long as you have a label

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

theraven added a comment. It is problematic for the compiler to differentiate between being invoked as CC and as cc (clang and gcc both have to work on case-insensitive filesystems). The convention to have CC as an alias for c++ comes from some SysV platforms (though not from Linux, which

Re: strtoll is not defined when compiling with -std=c++03

C++11 was the first version of C++ to include a long long type, so this doesn’t look like a bug. David On 6 May 2015, at 09:20, Gleb Popov 6year...@gmail.com wrote: Hello. I'm compiling following code #include stdlib.h int main() { strtoll(0,0,0); return 0; } with -std=c++03

Re: Compiling LLDB

On 31 Mar 2015, at 02:53, Ed Maste ema...@freebsd.org wrote: I'd suggest checking /var/log/messages for further information. Is this i386 or amd64, how much memory does your build host have, and are you compiling with debug information or no? If had to guess, you're running out of memory (or

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

theraven accepted this revision. theraven added a comment. This revision is now accepted and ready to land. Thank you! BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1932 To: dim, emaste, theraven Cc: freebsd-toolchain ___

Re: Migration to dynamic libs for llvm and clang

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 manually run make install after building). That's still potentially an

Re: llvm build error on ppc

On 13 Nov 2014, at 18:17, Konstantin Belousov kostik...@gmail.com wrote: Is ppc the only architecture where we do build clang, but with gcc ? Since the failure only occured on ppc/pcc64, and not on e.g. arm. It may be the only architecture where we build with gcc by default, but try to

Re: devel/mingw32-gcc problem

There have been some changes to how the ports tree handles libtool files recently, but I don't know the details. You'd be better off asking on the ports list or in #bsdports on EFNet. David On 10 Oct 2014, at 21:36, Naram Qashat cyberb...@cyberbotx.com wrote: Hi everyone, I've been

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

On 6 Sep 2014, at 06:47, Garrett Cooper yaneurab...@gmail.com wrote: Makes sense. I'll do some poking around and see if things could potentially be optimized with the clang build. On beefy machines it's not a big deal, but as we know on machines without a ton of memory or SSDs, it can become

Re: abi::__cxa_demangle provides invalid result on non-mangled symbols

On 11 Jun 2014, at 13:30, Kai Wang k...@freebsd.org wrote: On Tue, Jun 10, 2014 at 07:38:19AM +0100, David Chisnall wrote: On 10 Jun 2014, at 03:44, Ed Maste ema...@freebsd.org wrote: I had the same issue in LLVM, and as hacky as it seems, the solution is to check that the name starts

Re: abi::__cxa_demangle provides invalid result on non-mangled symbols

On 10 Jun 2014, at 03:44, Ed Maste ema...@freebsd.org wrote: I had the same issue in LLVM, and as hacky as it seems, the solution is to check that the name starts with _Z before passing it to __cxa_demangle. For reference the LLVM review for the change is here:

Re: LLVM bug WRT temporary files?

This looks like a bug, please file an llvm PR. The offending code seems to be createUniqueEntity() in lib/Support/Unix/Path.inc, which does... something. Something weird and convoluted that seems to try to implement mkstemp() / mkdtemp() in an incomprehensible way. David On 13 Feb 2014, at

Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

On 2 Jan 2014, at 20:22, Pedro Giffuni p...@freebsd.org wrote: The behaviour is consistent with llvm-gcc though, as explained here: https://bugs.launchpad.net/ubuntu/+source/llvm-gcc-4.2/+bug/483679 looking at the LLVM/Clang documentation

Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote: I have particular interest in -fwritable-strings and the block support, mostly with the idea of making our gcc somewhat more compatible to clang. I would absolutely love to see our GCC have blocks support. It would be very nice

Re: clang sanitizers (memory, address, etc)

On 24 Oct 2013, at 08:41, sq...@peralex.com wrote: On 2013-10-23 15:10, David Chisnall wrote: I had a chat with some of the *san people (mostly from Google Moscow) quite recently. They've refactored most of the code so it should be fairly obvious where the platform-specific bigs

Re: c99 support

On 29 Sep 2013, at 19:56, Eitan Adler li...@eitanadler.com wrote: On Sat, Jul 20, 2013 at 10:12 AM, Eitan Adler li...@eitanadler.com wrote: How much of this page is accurate? http://www.freebsd.org/projects/c99/ Can it be removed? Turned into a wiki page? I intend to remove this page in

Re: GCC withdraw

, at 16:11, David Chisnall thera...@freebsd.org wrote: I am not proposing: ... - To deprecate any architectures - To break any architectures If a platform ends up without a working toolchain in a few years and there is no way (LLVM, recent GCC, heavily patched old GCC, vendor-supplied

Re: GCC withdraw

On 31 Aug 2013, at 08:33, John-Mark Gurney j...@funkthat.com wrote: Why didn't this come up when John added XSAVE (a year ago) or Pedro Giffuni added amdfam10 support (3 months ago)? Plus, I've sent other patches earlier this year to -toolchain and made clear why I was adding them... Had I

Re: GCC withdraw

On 30 Aug 2013, at 08:18, Julian Elischer jul...@freebsd.org wrote: As far as I'm concerned we can even slate it for possible removal in 10.2-- if clang has proven up to the task I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point

Re: GCC withdraw

On 30 Aug 2013, at 08:56, Jonathan Anderson jonat...@freebsd.org wrote: Wouldn't this mean that we can't build base using the shipped-in-base g++? If we have C++ in base, we don't ship libstdc++ and g++ can't work with libc++, then people wanting to compile the base system with gcc/g++ will

Re: GCC withdraw

On 30 Aug 2013, at 15:41, John Baldwin j...@freebsd.org wrote: So my take away from this is that you have no plans to support any platform that doesn't support clang as you just expect ia64 and sparc64 to die and not be present in 11.0. That may be the best path, but I've certainly not seen

Re: GCC withdraw

On 30 Aug 2013, at 15:53, Nathan Whitehorn nwhiteh...@freebsd.org wrote: So the real driver here is switching to libc++. Is there really no way at all to use it with gcc? If, even with hacking, we could arrange that to work then it seems that all of our problems would go away. If we can make

Re: GCC withdraw

On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote: I have not seen any convincing argument as to why leaving GCC in the base for 10.x impedes anything. Because clang isn't sufficient for so many non-x86 platforms we can't really start using clang-specific features yet anyway.

Re: GCC withdraw

On 25 Aug 2013, at 00:06, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log

Re: patch to add AES intrinsics to gcc

On 23 Aug 2013, at 23:37, Warner Losh i...@bsdimp.com wrote: I'd dispute the 'and surely it seems like it does' part of this. Non x86 architectures will continue to use gcc because clang just isn't ready at this time for them. Some are very close (arm), some are close (powerpc64, mips*),

Re: GCC withdraw

On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible

Re: GCC withdraw

On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you

Re: GCC withdraw

On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ David signature.asc Description: Message signed with OpenPGP using GPGMail

Re: patch to add AES intrinsics to gcc

On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@freebsd.org wrote: I don't know if you are aware that IF you really do that we will have serious problems to ship packages for 10. USE_GCC=any is the fallback in the portstree for all ports that are unable to build with clang which was

Re: patch to add AES intrinsics to gcc

On 23 Aug 2013, at 11:42, Julian Elischer jul...@freebsd.org wrote: no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you.. even after it

Re: patch to add AES intrinsics to gcc

On 23 Aug 2013, at 13:26, Andriy Gapon a...@freebsd.org wrote: On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not

Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)

On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

On 12 Jul 2013, at 22:47, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Obviously not really fixed, but even worse: if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 revision 253287) isnan(x) where x is a const double, I receive now the following error (which doesn't

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

Hi Bruce, You're joining in this discussion starting in the middle, so you probably missed the earlier explanation. On 11 Jul 2013, at 05:21, Bruce Evans b...@optusnet.com.au wrote: I don't see how any conforming program can access the isnan() function directly. It is just as protected as

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

On 11 Jul 2013, at 13:11, Bruce Evans b...@optusnet.com.au wrote: math.h is also not required to be conforming C code, let alone C++ code, so there is only a practical requirement that it works when included in the C++ implementation. Working with the C++ implementation is the problem that we

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

On 11 Jul 2013, at 13:11, Bruce Evans b...@optusnet.com.au wrote: The error message for the __builtin_isnan() version is slightly better up to where it says more. The less-unportable macro can do more classification and detect problems at compile time using __typeof(). The attached patch

Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity

On 10 Jul 2013, at 17:33, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Hi David, thanks for the fast response. The code I was told to check with is this: #include iostream #include typeinfo #include cmath int main(void) { std::cout typeid(isnan(1.0)).name() \n; }

Re: Miscellaneous questions

On 3 May 2013, at 13:52, Erik Cederstrand e...@cederstrand.dk wrote: Not that I'm aware of. mclinker is work in progress and is not yet able to link the kernel. gold should work, but I'm not aware that LTO linking has been tested to work. I spoke to Diana Chen, who works on MCLinker, on

Re: c89 broken on head?

On 7 Mar 2013, at 19:28, Dimitry Andric d...@freebsd.org wrote: Also, I seem to remember a discussion about making -std=gnu89 the default for clang when run as cc, but nothing seems to have changed. Could this be picked up again, because there are in fact subtle semantic differences between

Re: base gcc and _GLIBCXX_USE_C99

On 4 Feb 2013, at 03:09, Pedro Giffuni p...@freebsd.org wrote: Those are surely in this list: https://wiki.freebsd.org/MissingMathStuff I think we are using stubs for libc++. We are using stubs for libc++, because libc++ is a C++11 standard library, which expects the C99 math functions.

Re: base gcc and _GLIBCXX_USE_C99

On 1 Feb 2013, at 13:31, Andriy Gapon wrote: cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined. This is entirely consistent with the standard. strtoull() should only be visible when compiling in C++11 mode, it is not part of C++98 / C++03. David

C++ runtime version patch for testing

Hi All, Here is a patch that, I believe, should fix the symbol version mismatches between the runtime and the STL implementation. I have run the exception tests from libcxxrt with this patch applied and: - libsupc++ libstdc++ - libcxxrt libstdc++ - libcxxrt libc++ All tests pass for me

Re: C++ runtime version patch for testing

On 27 Jan 2013, at 15:03, Konstantin Belousov wrote: On Sun, Jan 27, 2013 at 01:28:44PM +, David Chisnall wrote: + std::set_new_handler*; What are the symbols you assigning the version there ? I cannot find anything in the libstdc++.so export list which would match the line. std

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

On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: Yes, quite possible. AFAIR, the 'catch' code compares the exception classes by the shared object ownership. It might get confused due to filter providing some symbols. But I did not investigated the cause for real. I'm investigating

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

On 21 Jan 2013, at 16:54, Konstantin Belousov wrote: On Mon, Jan 21, 2013 at 04:12:00PM +, David Chisnall wrote: On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: Yes, quite possible. AFAIR, the 'catch' code compares the exception classes by the shared object ownership. It might get

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

On 21 Jan 2013, at 17:24, Konstantin Belousov wrote: So can you provide self-contained test.tgz with Makefile and neccessary .c files which demonstrate exactly the behaviour you see ? I don't have one, this is the behaviour that I see from C++ programs linked to libstdc++. David

Re: Fast sigblock (AKA rtld speedup)

On 14 Jan 2013, at 18:58, John Baldwin wrote: I'm less certain. Note that you can't inline mutex ops until you expose the mutexes themselves to userland (that is, making pthread_mutex_t not be opaque). This is one of the things that will be required anyway if we wish to support

Re: Fast sigblock (AKA rtld speedup)

On 14 Jan 2013, at 17:47, Jilles Tjoelker wrote: The code which does that check is actually under contrib/gcc. Problem is, they designed __gthread_active_p() to distinguish threaded and unthreaded programming environments -- it must be known in advance and cannot be changed later. The code

Re: Using non-standard linker

On 14 Dec 2012, at 08:15, Erik Cederstrand wrote: Would this be acceptable in FreeBSD if I created a patch, or are you just suggesting it for my local testing? I think that we will probably want to import MCLinker as soon as it is able to (correctly) link the base system, and at that point a

Re: Using non-standard linker

Hi Eric, The easiest way of doing this is to make /usr/bin/ld (in the host system and in the bootstrap) into a symbolic link that points to whatever the selected linker is. I had to do this when testing gold as well (we end up with ld-gold and ld-bfd and ld being a symlink to one of them).

Re: Using non-standard linker

On 13 Dec 2012, at 13:18, Erik Cederstrand wrote: The easiest way of doing this is to make /usr/bin/ld (in the host system and in the bootstrap) into a symbolic link that points to whatever the selected linker is. I had to do this when testing gold as well (we end up with ld-gold and

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

On 26 Nov 2012, at 20:11, Dimitry Andric wrote: On 2012-11-24 11:45, David Chisnall wrote: ... In theory, the libc++ headers that are part of the C++03 spec (i.e. not things like stdatomic) should work in C++98 / C++03 mode, however the implementation in libc++ must be compiled in C++11

Re: Clang as default compiler November 4th

On 12 Sep 2012, at 10:09, Doug Barton wrote: Also, users who actually are helping with testing clang for ports continue to report runtime problems, even with things that build fine. I hope that you are encouraging maintainers of ports that don't work as expected with clang to submit bug

Re: Clang as default compiler November 4th

I'd add one more thing that needs fixing: Clang should default to c89 mode when invoked as cc. I had a patch to do this, but I seem to have misplaced it. I'll try to find or rewrite it in the next couple of days. A lot of the ports failures I saw were due to ports using cc as the default C

Re: Clang as default compiler November 4th

On 11 Sep 2012, at 09:18, Dimitry Andric wrote: So I am a bit reluctant to change clang's default standard to c89, unless clang upstream agrees with this. In the interest of prodding people to update their software, I would rather have the default stay c99, personally. :) I'm not proposing

Re: BSD archive file formats

Hi Pete. The end of the man page says: This manual page documents the ar(1) archive formats used by the 4.4BSD and UNIX SVR4 operating system releases. I think it's probably safe to assume that the 4.4BSD format was dropped at some indeterminate point in the past, probably when

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

On 29 Jul 2012, at 16:08, Erik Cederstrand wrote: MCLinker seems to me like the most promising project at the moment. But in the end, working code is what counts :-) Agreed. The top requirement on my list was 'actually exists' for that exact reason: vapourware is of no interest.

Re: MCLinker and llvm-config

On 25 Jul 2012, at 10:22, Luba Tang wrote: Let me explain the status of MCLinker. MCLinker now is one of the standard system linkers in Android system. https://android.googlesource.com/platform/frameworks/compile/mclinker It looks like MCLinker has made a lot of progress since I last checked.

Re: gcc46 header search path

On 6 Jul 2012, at 23:29, Andriy Gapon wrote: I think that this is a dummy argument. One could easily want his LOCALBASE to be /opt and the real ports system should support that. So what ports currently do, they really have to do (assuming $LOCALBASE as opposed to /usr/local). That's

Re: [RFC] Un-staticise the toolchain

On 26 Apr 2012, at 12:38, Bob Bishop wrote: Hi, On 26 Apr 2012, at 10:35, Konstantin Belousov wrote: I think it is time to stop building the toolchain static. I was told that original reasoning for static linking was the fear of loosing the ability to recompile if some problem appears

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

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 list a few months ago, and I believe that it