Re: External GCC Update
On 22/02/2019 19:00, John Baldwin wrote: 3) I add support for an /etc/src.conf.d dir that can hold files that get treated as if they are part of /etc/src.conf. The current patch on github for this only fixes world and not yet kern.pre.mk and probably needs the most review if we want to go forward with this route. With this, I plan to have the base/* packages install suitable files in this dir that disable build of the src-based components and also set WITH_BASE_ to make sure 'delete-old' DTRT. Having a file outside of both the source and build directories that controls aspects of the build is already a cause of significant pain when building multiple different configurations of the FreeBSD base system. This sounds as if it would make things considerably worse. David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On 23 Nov 2018, at 16:23, Ed Maste wrote: > > For some time we have been incrementally working to retire the use of > obsolete GNU Binutils 2.17.50 tools. At present we still install three > binutils by default: > > as > ld.bfd > objdump We probably need to kill ld.bfd before 12.0. It predates ifunc and so interprets anything with an ifunc as requiring a copy relocation. This means that if you use it to link against any shared library (like, say, libc.so.7 in FreeBSD 12.0) that uses ifuncs then it will insert a relocation so that the ifunc resolver (which contains PC-relative addresses of other functions) will be copied into the main binary. This then causes your program to crash the first time anything calls memcpy, in a very difficult-to-debug way (it jumps into a random bit of your main binary, runs for a bit, and then dies). David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 files on platforms where clang is the default system compiler. LLVM’s libUnwind should be able to handle PowerPC on Linux, so it’s worth checking if this is the case on FreeBSD. David > On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain > wrote: > > While investigating powerpc64 C++ exception handling for > builds under devel/powerpc64-gcc I ran into the following > in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : > > /* As a special exception, if you link this library with other files, > some of which are compiled with GCC, to produce an executable, > this library does not by itself cause the resulting executable > to be covered by the GNU General Public License. > This exception does not however invalidate any other reasons why > the executable file might be covered by the GNU General Public License. */ > > So in contexts were clang/llvm is used to exclusion . . . are > any such files in use? (I happen to be using devel/powerpc64-gcc at > the moment.) > > For me this has no real implications: I do not distribute > my experiments. But I was surprised by what I read. > > Looking I find: > > # grep -r "some of which are compiled with GCC" /usr/src/* | more > /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/config/mips/mips16.S: some of which are compiled with > GCC, to produce an executable, > /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled with GCC, > to produce an executable, > /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled with GCC, > to produce an executable, > /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-rtems.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-vxworks.h: some of which are compiled with GCC, > to produce an executable, > /usr/src/contrib/gcc/gthr-dce.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-nks.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-tpf.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-aix.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-lynx.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-solaris.h: some of which are compiled with GCC, > to produce an executable, > /usr/src/contrib/gcc/gthr.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gcov-io.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-gnat.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-single.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/gthr-win32.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/tsystem.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/typeclass.h: some of which are compiled with GCC, to > produce an executable, > /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c: some of which are compiled > with GCC, to produce an executable, > /usr/src/contrib/gcc/unwind-dw2-fde-darwin.c: some of which are compiled > with GCC, to produce an executable, > > === > Mark Millard > marklmi at
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 passed compile command) is compiled with -Wsystem-headers, which issues warnings even in system headers. This is increasingly unhelpful and must, for example, be turned off when compiling anything written in C++ because of warnings in libc++ headers. David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 three (or thereabouts) demanglers should be *the* LLVM demangler. > > Ed, IIRC you had some looks at this before, do you have any preference? I spoke to the ELF Toolchain maintainer a little while ago and pointed out that the demangler that we got from there lacked some features. Maybe we can persuade him to add support for r-value references? Ideally, I’d like to make the one in libcxxrt a weak symbol and ship the LLVM one in a separate library - it’s very big, so linking it into things like devd would be silly, but anything that’s dynamically linking libc++ would probably not notice the increase in code size. David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: libstdc++ build failures on MIPS, PowerPC, Sparc
On 23 Jul 2017, at 23:54, Mark Millard wrote:
>
>>c++ -isystem ${OUTDIR}/tmp/usr/include/c++/v1 -std=c++11 -nostdinc++
>> -isystem ${OUTDIR}/tmp/usr/include -L${OUTDIR}/tmp/usr/lib
>> -B${OUTDIR}/tmp/usr/lib --sysroot=${OUTDIR}/tmp -B${OUTDIR}/tmp/usr/bin -O
>> -pipe -G0 -EB -mabi=32 -msoft-float -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H
>> -I${SRCDIR}/gnu/lib/libstdc++ -I${SRCDIR}/contrib/libstdc++/libsupc++
>> -I${SRCDIR}/contrib/gcc -I${SRCDIR}/contrib/libstdc++/include
>> -I${SRCDIR}/contrib/gcclibs/include -I${SRCDIR}/contrib/libstdc++/include
>> -I. -frandom-seed=RepeatabilityConsideredGood -fno-implicit-templates
>> -ffunction-sections -fdata-sections -Wno-deprecated -c
>> ${SRCDIR}/contrib/libstdc++/src/bitmap_allocator.cc -o bitmap_allocator.o
This is quite a surprising build command. It’s using usr/include/c++/v1 for
system includes, but usr/include/c++/v1 is the libc++ header directory.
libstdc++ shouldn’t need to be built with C++11 support, but libc++ does, so
this command looks like a combination of both libc++ and libstdc++ build flags
all mashed together.
David
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 easier for maintenance, and organization of compilers and toolchain > components. Debian does something like this, and it’s a huge pain to work with. The problem is that toolchains are not self-contained monolithic components (though gcc likes to pretend that they are). For example, we want gcc and clang to use the same linker, the same C and C++ standard library implementations, and the same system headers, irrespective of the compiler version. Things that actually are private to a compiler are in separate directories (see /usr/lib/clang, for example). David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 > aliasing restrictions. If the memcpy() becomes an external call, both > code size and speed will be affected and the programmer will probably > choose some other way such as unsafe pointer casts or reading one byte > at a time. In a non-freestanding environment, memcpy, memset, and memcmp calls are both translated early to LLVM intrinsics and then have special handling throughout the optimisation pipeline and in code generation. We’re likely to pay a noticeable penalty in code size and performance if we don’t allow the compiler to do these, above and beyond the cost of the call. David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 option? Yes, there is a noticeable performance hit. Buildworld takes 20-50% longer with a shared toolchain. I don’t know if anyone has done any profiling of rtld to see if there’s any space for optimisation there (I suspect very little). David smime.p7s Description: S/MIME cryptographic signature
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 investigations.] There are two complexities in the unwind implementation: the generic unwinder and the language-specific unwinder (the personality function and the associated data in the language-specific data area, along with how it uses these). The C++ implementation is probably the most complicated of all of these (Ada might be more complex, but let’s not go there). The C unwinder, which just implements __attribute__((cleanup)) is very simple in comparison and should give you easier code to debug (though you’ll need something higher up the stack that actually catches the exception, as the unwinder won’t enter a cleanup unless the exception is caught). The Objective-C implementation is somewhere in between the two in terms of complexity. David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 something that we should start doing. David smime.p7s Description: S/MIME cryptographic signature
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 manipulated by a memory safety bug. It doesn’t provide much mitigation, but it also doesn’t cost very much - some security for a negligible cost is probably a sensible thing to pick. When combined with RTLD_NOW, it provides more hardening, but at a much more significant cost (bigger startup times - much bigger for things like OpenOffice or Firefox, some forms of interposition break, and so on). That’s still probably worth it for some things (sshd, for example). David smime.p7s Description: S/MIME cryptographic signature
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 large and > representative set of real-world applications before turning the knob. Can portmgr create a temporary package set with the knob turned so that people can test easily? David smime.p7s Description: S/MIME cryptographic signature
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: >>libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x2010) >>libm.so.5 => /lib/libm.so.5 (0x20053000) >>libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20076000) >>libc.so.7 => /lib/libc.so.7 (0x2030) >> # ./a.out >> /usr/local/lib/gcc6/libstdc++.so.6: Undefined symbol "__aeabi_uldivmod" > The problem appears to be that we’ve not imported (all of?) the ARM-specific bits of compiler-rt. For example, this function is provided upstream: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/builtins/arm/aeabi_uldivmod.S?revision=273500&view=markup David smime.p7s Description: S/MIME cryptographic signature
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 for trying to make lld
> more readily available as early as possible, even if we're still
> waiting on some required features.
I believe that all of the base system clang’s for supported branches support
-fuse-ld=lld (perhaps 10.0 didn’t?), so if we have an lld candidate in ports
then it should be easy for user to test it by doing a pkg ins lld and setting
LDFLAGS. Failing that, the fallback to just replacing /usr/bin/ld with a
symlink to /usr/local/bin/ld.lld would probably work for ports testing.
We’re probably going to want a ‘needs bfd / gold instead of lld’ knob for a
while. We might need to patch the gcc versions in ports to accept
-fuse-ld=lld[1].
I suspect the longer tail for LTO. There is a bunch of low-hanging fruit in
the FreeBSD tree where LTO would likely be a win (I’d expect most of the
statically linked stuff to get smaller, if nothing else).
David
[1] gcc and clang interpret -fuse-ld differently. In clang, -fuse-ld={foo}
means ‘${PATH}/ld.{foo}’ is the linker and you should error out if it doesn’t
exist. gcc instead hard codes bfd and gold as the two valid options and rejects
anything else.
smime.p7s
Description: S/MIME cryptographic signature
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 improve performance. I’d like for us to enable them all (with associated so version bump) in 11. At this point, it might make sense to do the same for libc++ in ports and move ports over to depending on the ports version on <11. David ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 called corrupt to look for. You do
not, however, because:
> return;
>
> whoops:
> printf("whoops\n");
> return
>
> corrupt:
> printf("corrupt\n”);
The statement:
> return corrupt: printf("corrupt\n");
is just confusing. It appears to be trying to return the value in corrupt
(which is not an identifier that corresponds to any valid variable) and then
has some trailing characters after the end of the statement. Fortunately, the
compiler tells you exactly what is wrong:
First it says:
> foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you mean
> 'crypt'?
> corrupt:
> ^~~
Here, it is telling you that the value passed to your return statement is an
undeclared identifier. Then it tells you that you have more tokens after the
end of your return statement:
> foo.c:21:8: error: expected ';' after return statement
> corrupt:
> ^
> ;
I am slightly surprised that there’s no warning that a return statement with a
value is invalid in a function that returns void, but perhaps that’s because
after finding two things wrong with one statement it gives up.
The correct fix, of course, is to insert the missing semicolon after the return
at the end of line 19. If you had tried compiling the same thing with gcc 5,
then you would have noticed that you get very similar error messages (though
gcc doesn’t attempt to provide a fixit hint and does warn that you have a
return statement returning a value from a function that returns void).
David
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: powerpc64-xtoolchain-gcc/powerpc64-gcc gets libcxxrt/guard.cc:104:15: error: expected constructor, destructor, . . . for lib32 (clang 3.6.1 context)
On 12 Oct 2015, at 03:17, Mark Millard wrote:
>
> /usr/src/lib/libcxxrt/../../contrib/libcxxrt/guard.cc:104:15: error: expected
> constructor, destructor, or type conversion before '(' token
> _Static_assert(sizeof(guard_t) == sizeof(uint64_t), "");
I think that this is the error that you get with old gcc when a static assert
fails. What is the type of guard_t on PPC64? It may simply be that gcc isn’t
providing the correct #defines to let the file know that it’s a 64-bit target.
David
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[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 does not install the CC alias). On OS X, cc and CC are the same file, as the filesystem is case preserving but not case sensitive. As a result of this, we have been carrying around patches to clang to make it detect that it is being invoked as CC for a while, to avoid breaking every single cmake-built C++ program (a few hundred ports) that defaults to CC as the C++ compiler (for Solaris/IRIX compatibility), but will happily fall back to using c++ instead. Aside from the cost of maintaining this patch, this also adds a place where the obj dir / install sysroot must be on a case-sensitive filesystem, which harms attempts to make FreeBSD cross-buildable from OS X / Windows (we are careful to avoid this requirement for the src tree and have an svn hook to prevent it). The CC alias does not work on Linux or OS X, so the likelihood of this breaking third-party code is minimal and the pain that it has already caused is nontrivial. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1932 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: dim, emaste, theraven, imp Cc: kib, imp, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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
>
> int main()
> {
> strtoll(0,0,0);
> return 0;
> }
>
> with -std=c++03 and getting:
>
> tst.cpp:5:1: error: use of undeclared identifier 'strtoll'
> strtoll(0,0,0);
> ^
> 1 error generated.
>
> Preprocessing system headers with this flag shows that __LONG_LONG_SUPPORTED
> isn't defined. Is this a bug?
> ___
> freebsd-toolchain@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Compiling LLDB
On 31 Mar 2015, at 02:53, Ed Maste 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 running into ulimit) during linking, and the > process is being killed as a result. Ninja defaults to using a large number of concurrent processes, which can exacerbate this. If you are on a 32-bit system, or only have 4GB or so of RAM (or have <2GB per core), you may want to explicitly do ninja -j1 to get a serial build. Your best bet is probably something like: $ ninja -k100 $ ninja -j1 The first will do a parallel build of everything that doesn't crash. The second will do a serial build of whatever's left. It's also possible to configure different pools for Ninja, though I'm not sure that this is exposed via the CMake interface yet. This mechanism exists to allow you to say things like 'only run one link job at a time', which can improve matters. You may also find that using gold from ports (or possibly lld, which I believe can now link lldb) will improve matters. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 22:01, Craig Rodrigues wrote: > >> Volatile is not the solution, it is completely orthogonal. The correct >> way would be to use unsigned integers, for which wrapping is defined, >> then convert those back and forth when presenting the results to the >> user. >> > > OK, converting expr.y to use unsigned integers would require a bit of work. Note that clang has, for a few releases, had builtins that allow overflow-checked operations and will generate very efficient code. In op_times, I believe the following should work: long long mul; #if __has_builtin(__builtin_smulll_overflow) if (__builtin_smulll_overflow(a->u.i, b->u.i, &mul)) errx(ERR_EXIT, "overflow"); #else mul = a->u.i * b->u.i; #endif r = make_integer(mul); I don't know if recent versions of gcc implement these builtins yet. I think they were added to clang around 3.4, possibly slightly earlier. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Migration to dynamic libs for llvm and clang
On 16 Dec 2014, at 16:04, Dimitry Andric 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 issue if we add local tools that use libclang APIs (which we may well do). > I'm not sure we want to go the 'libbsdfoo.so' route again, as Baptiste > tried this before, and seems to have reversed it again. :) Upstream doesn't call it libclang (that's the name of the library with a stable C ABI, which is why I'd like us not to confuse it with something with a library with an unstable C++ API). They do produce a libLLVM.so from the LLVM builds and work is underway to have shared library builds for clang. libLLVM.so could potentially be in /usr/lib in 11 if we have a packaged base system, as it would allow us to have different .so versions installed if things demanded them. The point releases guarantee backwards ABI compatibility, so we can still upgrade to them if required. > That said, I agree with the general idea, but one of the first things > we should decide is whether this will be optional or not. Having to > maintain yet another WITH_CLANG_FOO option is burdensome... I agree. I'd quite like to see performance numbers for the compiler. I think I saw about a 10% overhead for buildworld last time I tried, but that was a couple of years ago. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Migration to dynamic libs for llvm and clang
Hi Ed, Please can we have a name other than libclang, to avoid name collisions and confusion with, uh, libclang? libcfe maybe? David On 16 Dec 2014, at 15:46, Ed Maste wrote: > One of goals for the toolchain prior to the FreeBSD 11 branch is to > create a libllvm.so and libclang.so for use by all of the LLVM family > tools installed in the base system. This message is just a heads-up in > case anyone has questions or comments on the idea. > > We currently build a large number of static libs for the llvm and > clang components, which are reused in a number of tools in the LLVM > family. The resulting binaries end up quite large, and as a group > require a lot of disk space. For example, LLDB includes a copy of > Clang, used as its expression parser. As a result, on my desktop > /usr/bin/clang and /usr/bin/lldb are both 27MB. > > Over time we may add additional LLVM family tools (e.g., > llvm-objdump), and this will help avoid excessive bloat as we do so. > > I expect libllvm.so and libclang.so will go in /usr/lib/private. > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang (both 3.3 and 3.4) OOM crashes on HEAD
On 19 Nov 2014, at 08:04, Dimitry Andric wrote: > As far as I know, Errata Notes are only issued for security issues (and > probably only severe ones, without a workaround). Security Advisories are for security issues. Errata Notes are for... errata. The confusion comes from the fact that ENs go via freebsd-update, which is managed by secteam, so using them for anything is a bit harder than it should be (should be fixed in 11). This seems like a fairly good candidate though. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: llvm build error on ppc
On 13 Nov 2014, at 18:17, Konstantin Belousov 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 install clang as well. PowerPC is very close to working with LLVM, but not quite there yet. I think everything else is either clang-is-default or clang-is-not-even-tried. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 wrote: > Hi everyone, > > I've been trying to push out an update to devel/mingw32-gcc, but ran into a > problem, and Rene suggested asking about it here. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191291 > > Long story short, some of the .a files installed by devel/mingw32-bin-msvcrt > get clobbered (their contents becomes nothing but NUL bytes) during the build > of mingw32-gcc. This only happens under 10.x and not under 9.x or earlier. > > I'm not subscribed to this mailing list, so please CC me on any replies. > > Thanks, > Naram Qashat > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary?
On 6 Sep 2014, at 06:47, Garrett Cooper 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 > painful, as expected. The build system for clang-in-base has improved a bit so, as you say, it is now reasonably fast on beefy machines (release clang build with the upstream build system takes 2-3 minutes on a fast machine, about 10 on my laptop, the one in buildworld isn't quite as good at extracting parallelism). On slow machines, it can be quite painful. The correct solution to this problem is likely to be to start creating bootstrap-toolchain packages. This is also likely to be necessary for architectures like MIPS and PowerPC before 11 anyway, because the host compiler doesn't have the C++11 support required for bootstrapping a newer LLVM and clang. We can work around that quite easily if we have package for the bootstrap toolchain (possibly cross-compiled from an x86 machine). David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: abi::__cxa_demangle provides invalid result on non-mangled symbols
On 11 Jun 2014, at 13:30, Kai Wang wrote:
> On Tue, Jun 10, 2014 at 07:38:19AM +0100, David Chisnall wrote:
>> On 10 Jun 2014, at 03:44, Ed Maste 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:
>>> http://reviews.llvm.org/D2552
>>>
>>> I didn't get around to testing it on Linux; since you have a test
>>> application ready it would be interesting to see the result of
>>> __cxa_demangle("f") there.
>>
>> If you know that the thing that you are demangling is a symbol name, then
>> you can use the _Z check, which isn't really a hack - it's a marker added to
>> identify C++ symbols. Note that, if you're writing portable code, you need
>> to remember that some systems prepend an underscore to all
>> compiler-generated symbols, so you may also need to check for __Z and trim
>> the leading _.
>>
>> The __cxa_demangle() function has to handle things that are not just symbols
>> (types and so on) and so can't do this test itself. Its most common use is
>> generating a human-friendly error for an uncaught exception, where it is
>> just parsing a type encoding.
>>
>> The demangler that we ship is from libelftc. It also fails on a number of
>> C++11 types and doesn't handle some complex template cases.
>
> Hi David,
>
> If possible, could you list a few examples that the demangler can not
> handle? Maybe we can fix this in libelftc and merge it back later.
Your best reference for this is the libc++abi test suite:
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/test_demangle.cpp?revision=208611&view=markup
New C++11 additions and template arguments that are forward references are not
very well handled. It would be great if there were any improvements.
It would also be good for libcxxrt if the demangler could avoid having to
allocate any memory except on the stack, as one of the places where it's used
is in reporting out-of-memory conditions.
David
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: abi::__cxa_demangle provides invalid result on non-mangled symbols
On 10 Jun 2014, at 03:44, Ed Maste 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:
> http://reviews.llvm.org/D2552
>
> I didn't get around to testing it on Linux; since you have a test
> application ready it would be interesting to see the result of
> __cxa_demangle("f") there.
If you know that the thing that you are demangling is a symbol name, then you
can use the _Z check, which isn't really a hack - it's a marker added to
identify C++ symbols. Note that, if you're writing portable code, you need to
remember that some systems prepend an underscore to all compiler-generated
symbols, so you may also need to check for __Z and trim the leading _.
The __cxa_demangle() function has to handle things that are not just symbols
(types and so on) and so can't do this test itself. Its most common use is
generating a human-friendly error for an uncaught exception, where it is just
parsing a type encoding.
The demangler that we ship is from libelftc. It also fails on a number of
C++11 types and doesn't handle some complex template cases.
David
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: ctfconvert broken for C++ objects?
We're likely to keep hitting these. Ideally, we should replace the libdwarf usage in ctfconvert with either the LLVM or LLDB dwarf parsing, which is getting to be quite mature now and can handle complex encodings. The DWARF5 spec is due out this year and LLVM is already implementing (disabled by default) several of the proposed extensions to DWARF4 that are likely to make it into DWARF5. David On 20 Feb 2014, at 00:16, Justin T. Gibbs wrote: > I noticed that ctfmerge was warning about missing CTF data when compiling > “PROG_CXX” programs. I tracked this down to missing ctfconvert calls when > compiling C++ objects. Unfortunately, ctfconvert segfaults in libdwarf on > all of the C++ code I tried. Attached is a quick hack to avoid the segfault, > but I’m hoping someone here with more dwarf experience can point me in the > right direction for a real fix. Is this a known issue? > > I’m testing this on a FreeBSD stable/9 from ~November of last year. > > Thanks, > Justin > > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 17:33, Marcel Moolenaar wrote:
> Guys,
>
> I'm running into a build break that relates to the temporary files
> that LLVM creates:
>
> svl-junos-j019% cc --version
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> Target: arm--freebsd10.0-gnueabi
> Thread model: posix
>
>
> On a build machine /tmp/b is a directory and created by user X.
> I am doing a buildworld on that machine as user Y (Y=marcelm) and
> I don't have permissions in /tmp/b. The build gets to usr.bin/awk
> and it has a source file called b.c
>
>
> The build fails with:
>
> --- b.o ---
> cc -O -pipe -DHAS_ISBLANK -I.
> -I/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk
> -DFOPEN_MAX=64 -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter -Wno-parentheses -c
> /b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk/b.c
> cc: error: unable to make temporary file: /tmp/b: can't make unique filename:
> Permission denied
> *** [b.o] Error code 1
>
>
> Running truss shows:
>
> access("/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk/b.c",0)
> = 0 (0x0)
> stat("/tmp/b",{ mode=drwxr-xr-x ,inode=235520,size=512,blksize=16384 }) = 0
> (0x0)
> open("/dev/random",O_RDONLY,00)= 3 (0x3)
> read(3,"\M^S\M^H\^S65S'*\M-T\M-r\^A9\M-K"...,128) = 128 (0x80)
> close(3) = 0 (0x0)
> stat("/tmp/b",{ mode=drwxr-xr-x ,inode=235520,size=512,blksize=16384 }) = 0
> (0x0)
> open("/tmp/b/B8owDb",O_RDWR|O_CREAT|O_EXCL,0600) ERR#13 'Permission denied'
>
>
> Now, if I compile another file, I get:
>
> access("/b/marcelm/buildbot/FreeBSD_arm_arm/build/usr.bin/awk/../../contrib/one-true-awk/lex.c",0)
> = 0 (0x0)
> stat("/tmp/lex",0x7fffbab0)ERR#2 'No such file or
> directory'
> open("/dev/random",O_RDONLY,00)= 3 (0x3)
> read(3,"\^F\r\M-J\M-5Z\M-fK\^E\M-2'\M-1"...,128) = 128 (0x80)
> close(3) = 0 (0x0)
> stat("/tmp",{ mode=drwxrwxrwt ,inode=2,size=9728,blksize=16384 }) = 0 (0x0)
> open("/tmp/lex-pDQnPA",O_RDWR|O_CREAT|O_EXCL,0600) = 3 (0x3)
> close(3) = 0 (0x0)
>
>
> So for some reason when /tmp/ exists and is a directory, then the
> compiler wants to create a temporary file underneath that directory. That
> looks like a bug to me. Do people concur and thus shall I file a PR?
>
> --
> Marcel Moolenaar
> mar...@xcllnt.net
>
>
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [CFT] Update to clang 3.4
On 7 Jan 2014, at 06:49, Rui Paulo wrote: > On 5 Jan 2014, at 05:00, Dimitry Andric wrote: > >> I need some assistance with this, from somebody who knows exactly how >> CTF and DTrace work together. Our CTF tools use libdwarf in base, which >> is also quite old, and seems to be largely unmaintained. It does not >> seem to support anything beyond DWARF2. I think it would be worthwhile >> to upgrade this library from upstream ASAP. > > Our libdwarf was a from scratch implementation and we never used the LGPL > libdwarf. I don't know if it's worth investing time upgrading our BSD > licenced libdwarf or importing the LGPL libdwarf. Given the push to keep the > tree mostly BSD licenced, I would say the former. LLVM now has fairly complete DRAWF4 parsing support. What interfaces do the ctf tools need, and are they the only consumers of libdwarf? David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On 2 Jan 2014, at 20:22, Pedro Giffuni 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
> (http://clang.llvm.org/doxygen/InitPreprocessor_8cpp-source.html) shows that
> __block is not actually a keyword, but a macro that is defined to be
> __attribute__((__blocks__(byref)))."
>
> Not sure what to do about it, I had added a #define for it in Block.h since
> you have to link with -lBlocksRuntime anyways, but not everything includes
> Block.h (surely not the libdispatch tests).
Probably the best solution is to put this in cdefs.h:
#if defined(__BLOCKS__) && !defined(__block)
# define __block __attribute__((__blocks__(byref)))
#endif
(With the indentation changed to make it harder to read, as per style(9)). I
believe __BLOCKS__ is supported by clang, although testing for it is
discouraged in favour of the __has_{feature,extension} mechanism.
David
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).
On 23 Nov 2013, at 22:11, Pedro Giffuni 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 to be able to use blocks in libc. I have some macros that allow code to call blocks even when compiled with a compiler that doesn't support them, but having native blocks support would be fantastic. It's worth noting that Apple's libc includes a few _b variants of standard library functions: scandir_b err_set_exit_b fts_open_b glob_b atexit_b bsearch_b heapsort_b mergesort_b psort_b qsort_b These all do the same as their non-_b-suffixed equivalents, but take a block as an argument instead of a function pointer. Adding them has been on my todo list for a while, and this would give me a strong incentive to do so... David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 are. In most cases, it's just some >> interposition on malloc() and friends, which should be relatively easy to >> port. >> >> I'd love for us to have this stuff in the base system, and even versions of >> the base libraries (and programs) compiled to use them. >> > > Thanks, I'll have a look. Where can I find the sanitizer runtime library > code? The sanitizer runtimes are all part of compiler-rt: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/ David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang sanitizers (memory, address, etc)
On 23 Oct 2013, at 07:17, sq...@peralex.com wrote: > Thanks. I look forward to that. I'll have a look myself, but I suspect > the work involved is beyond my skill set. 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 are. In most cases, it's just some interposition on malloc() and friends, which should be relatively easy to port. I'd love for us to have this stuff in the base system, and even versions of the base libraries (and programs) compiled to use them. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang's scan-build tool?
Hi Kurt, On 4 Oct 2013, at 03:50, Kurt Lidl wrote: > However, I don't get the "scan-build" tool that is one of > clang's tools - it doesn't look like it got imported into > the contrib/llvm/clang/tools directory. > > Given the usefulness of this tool, is there any chance it > could be included under the aegis of WITH_CLANG_EXTRAS? The scan-build tool (and scan-view) is a Python script, so putting it in the base system without Python being in the base system wouldn't be much help. It would make a bit more sense to have the scan-view script from the base system as a stand-alone port, with an explicit Python dependency, so that it could be installed easily and Just Work™, rather than having something in the base system that required a port to be installed before it would actually work. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: c99 support
On 29 Sep 2013, at 19:56, Eitan Adler wrote: > On Sat, Jul 20, 2013 at 10:12 AM, Eitan Adler 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 the next few days unless someone > mentions that is still needed. I think it can go. It might be nice to have a public C11 page though, because most of the boxes on it would already be ticked... David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On 1 Sep 2013, at 19:03, Mark Linimon wrote: > If this is the case, IMHO: I was going to quote the whole mail, but actually this is enough. As I have already said in this thread, there is no such plan. I repeat, for those who missed it the first time: On 30 Aug 2013, at 16:11, David Chisnall 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 toolchain) of building it, then we will have to make the decision about its future. Whether that means getting the Foundation and / or some other interested body to pay for someone to work on a toolchain or dropping support is an issue for stakeholders in the platform. We will probably have to make this call about at least IA64 in a couple of years, and possibly some PowerPC and SPARC variants, but it's not a decision that needs to be made any time soon. I know SemiHalf does a lot of embedded FreeBSD work with PowerPC and a few people do with SPARC, so there are definitely people with vested interests in maintaining those two platforms. I'd honestly be surprised if IA64 is around in two years (mind you, I've been expecting it to die for the last five, so I'm willing to be surprised again), but maybe there will be a lot of cheap second-hand IA64 hardware on the market as all of the big customers switch to something else reviving interest in the platform... David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On 1 Sep 2013, at 02:53, Benjamin Kaduk wrote: > I am worried about the definition of "polished". I held my tongue in Ottawa > in 2011 when Kirk wanted to turn SU+J on by default, since I figured he knew > what was going on much better than I did. Then, we discovered the bad > interactions between SU+J and snapshots. If memory serves, things like > sparc64 and mips64 support for clang/llvm and XCC suppor are being described > as only "a few man-months work away". But that seems to be just to get > something which is working ... I fear that to get it truly "polished" will be > another 2-3 years on top of those man-months. If we are in agreement about > what "polished" means, then by all means announce with 10.0 that gcc's days > are numbered and drop it at the appropriate 10.x. I just don't want us to > discover terrible bugs a few months after we make a switch, due to being > wrong about "polished". We are using XCC to build FreeBSD today, on x86 with experimental tools and on MIPS with the compiler in base. It works, but it could do with better documentation. That's what I mean by polishing: making sure that it doesn't just work, it works and is easy to use. Part of this will involve ensuring that we have packages for cross compilers for various platforms so that it's really easy to just install a package with the cross toolchain you want and point your already-installed source tree at it to get a cross-build environment. Many of us have been running clang-is-cc for a long time and we're now seeing more port build failures on 10-with-gcc than 10-without-gcc. That's what I mean by polished. The SPARC back end in LLVM is marked as experimental. Looking over the code, it's actually in a better state than I thought it would be. Some people seem to be working on it. It's not something I would count on getting to a useable state though. If SPARC is to remain a supported architecture, then we'll probably be using an external toolchain for it, unless someone wants to spend a couple of months chasing bugs in the LLVM SPARC back end. Oracle seems to be being quite effective at killing SPARC64 as an architecture for running anything other than Oracle appliances, but SPARC32 is still quite popular in aerospace so it may still be an interesting platform in a few years. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On 31 Aug 2013, at 08:33, John-Mark Gurney 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 known that the policy was gcc was > dead for HEAD (which btw, I was told multiple times that we were keeping > gcc for 10 for i386/amd64), I would have just committed my kernel changes > by now, but didn't want to break a (what I thought was) supported > configuration... gcc is not dead for 10.0, we're simply wanting to not ship it in binary form by default. There is a BIG difference between saying 'if you want gcc then you must explicitly opt in and build it yourself and it may not be there for the entire 10.x series' and saying 'gcc is gone now, don't expect any of FreeBSD to build with it'. We are absolutely not proposing the latter for 10.0. We still expect the 10.0 kernel and most of the userland (libc++ excepted) to build with gcc. We expect this to be true for 10.1, and probably 10.2, possibly even 10.3. I'd probably expect that at least the kernel will build with gcc 4.2.1 for the entire timeframe. Some modules may not, although for ease of debugging compiler bugs I'd recommend that if they don't build with gcc 4.2.1 then at least they build with upstream gcc. However, we want to be able to make it unsupported at some point in the 10.x series when there is a polished alternative for every supported architecture (either when they've moved to clang or when the XCC stuff is fully documented in the handbook and tested in a large variety of configurations and once our forked binutils and is available as a package and we have cross-gcc that uses it). If this doesn't happen by the time 10.x is EOL'd then I'll be sad, but we still have the fall-back position of gcc in base for the entire 10.x. If it does happen, then we can start more aggressively phasing out gcc in the base system. > We need to communicate better on issues like these, since this isn't the > first time one group of people made a decision w/o telling the rest > of the community... For major items like this, we need to make sure > the road map is published, either on www.freebsd.org or on the wiki and > gets kept up to date... I agree. This is why I made sure that at the BSDCam DevSummit all of the sessions had someone who was taking notes for their sessions on the wiki: https://wiki.freebsd.org/201308DevSummit#Schedule-1 (Well, except, somewhat ironically, the docs team, who still haven't put their notes on the wiki) It's also why I've taken charge of putting out special status reports for each DevSummit for wider public consumption, like this one: http://www.freebsd.org/news/status/report-2013-05-devsummit.html I'd be interested in hearing any more suggestions about how we can improve this. > For example, the release schedule for 10 wasn't posted till over a week > after the code slush was announced (which caught people, like myself, by > surprise)... That's kinda the wrong order to do it in, the schedule > should be posted well in advance so people know what to expect... This one you'll have to discuss with re@. I think that after 10.0 there will be some more discussion about our release policy. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On 30 Aug 2013, at 15:53, Nathan Whitehorn 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 our g++ compile C++11 code, then we can compile libc++ with g++. This support requires significant modifications to the parser (it adds a second Turing-complete compile-time language, for one...) and so retrofitting C++11 support to g++ 4.2.1 is not going to happen. It's taken upstream gcc a couple of years to get to the required level of support. We don't have the manpower to replicate this. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On 30 Aug 2013, at 15:41, John Baldwin 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 that > goal discussed publically. I expect that platforms that don't have support from clang or some external toolchain will die. If people care about IA64, then getting Intel's compiler working as an external toolchain would probably be a good idea (it generates vastly better code than gcc). If people care about SPARC64, then either gcc from ports as an external toolchain, or finishing up the SPARC64 back end in LLVM are options. Finishing the SPARC64 back end is not that much effort (it's probably a couple of person-months of work - getting the calling conventions right does require some small tweaks to LLVM IR that I think someone's working on), but it hasn't been done because no one appears to care quite enough to make it a priority. >>> Don't get me wrong, I don't love GCC per se, and on my laptop I've hacked >>> the relevant ports so that everything is built with clang. I would also >>> love to be able to build the base system with GCC 47 instead of 42, it just >>> doesn't seem that we are there yet. >> >> The time to raise objections for this was when the plan was originally >> raised over a year ago, or at any of the points when it's been discussed in > between. It is not after we're ready to flip the switch. > > So I think the crux of the issue might be this: > > I have no doubt that this has been discussed extensively on toolchain@ and in > toolchain-specific devsummit sessions. The proposal to disable GCC by default > does not appear to have been discussed in a wider audience from what I can > tell. (I can't find any relevant threads on arch@ or current@ prior to this > one.) While this is a toolchain-specific decision, it is a very broad > decision. Also, we aren't here because of a new thread started intentionally > to say "Hey, we as the toolchain folks think we should disable GCC by default > on 10 for x86". Instead, we started off in a thread about adding AES > instructions to our binutils and out of left field there is an e-mail of > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). Can you > appreciate at all that this is a total surprise to people who aren't > subscribed to toolchain@ and haven't been to a toolchain session at a > devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the impression that this was widespread common knowledge and something I've personally discussed with various people including ports people on several occasions. I would have made the commit a couple of months ago, but getting the ports infrastructure back up to a state where it's easy to test has been a blocker there. If removing gcc from the standard install is going to cause major pain for people, then we can leave it in for 10.0. I'm currently doing a make tinderbox on the removal patch, modified to leave gcc in, and only remove libstdc++, which is something that we definitely need to do because it's causing an amount of pain that is only going to increase. I have no plans to make anything in the base system (other than clang itself, when 3.4 is imported) depend on libc++-only features (I'd love to do it for dtc, but it has to run on embedded platforms that are going to be stuck with libstdc++ in base for a while - at least a year, and that's if we're lucky). Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've already agreed not to commit this part, since it seems very controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system compiler - On platforms where clang is not cc, leave libstdc++ as the default system STL, but encourage ports to start depending explicitly on ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then you are free to install it, clang will still use it if you specify -stdlib=libstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you will see no difference. If you need to test whether building the base system or kernel with gcc fixes thing
Re: GCC withdraw
On 30 Aug 2013, at 08:56, Jonathan Anderson 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 have to > install a libstdc++ package. People wanting to build base with g++ will still have to explicitly enable the build of libstdc++, yes. That's only really an issue for 10.0 though, because in 10.1 we won't be able to build clang (or lldb) with either g++ from base or our libstdc++ from base, as both use C++11 features. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On 30 Aug 2013, at 08:18, Julian Elischer 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 in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On 29 Aug 2013, at 18:44, John Baldwin wrote: > How does removing GCC from base change this? I already deal with having > 3 different GCC versions at work by building them from ports and building > things with the right rpath, etc. so I am familiar with this, and having > GCC in the base doesn't make that problem any worse. In fact, I'd argue > that this is an argument for not shipping an STL in the base system at all > (though I'd be loathe to do that) if it is an argument for disabling GCC. It means that you don't need to patch configure scripts to tell them to ignore gcc even if they find it. Please talk to port maintainers about the amount of effort that they're being forced to put into this. They'll still have to keep doing this until 9.x is EOL'd, but it would be nice if they could then stop, rather than having to wait for 10.x to also be EOL'd. >> Maintaining our libstdc++ is not a zero-effort operation. We have to modify > it whenever libc gains new features (e.g. POSIX2008 locales, new libm > functions) and this requires developer time tracking down the new bugs > (because the static configuration files no longer match the included headers) > and fixing them. > > Strictly speaking you do not have to modify it in all cases. The recent > change to make it work with log10 does not appear to have been a requirement > to fix anything (at least judging from the log message). There does seem to > have been about 10 changes to libstdc++ in the past year, though a few were > 2-3 line changes in config.h which isn't but so earth-shattering. And each libc change that exposes anything that is used by libstdc++ goes through the same cycle: - Commit - Wait for bug reports - Spend a few hours trying to work out why C++ programs are failing to run or compile in odd ways - Commit a libstdc++ fix And, once again, the people who are advocating for gcc to remain in the default install are not the ones doing this work. > Also, unless you plan on desupporting all non-x86 platforms, you _still_ > have to do all this work while those platforms require GCC anyway. Just > turning off GCC on x86 doesn't change this problem one iota. And that point > is actually relevant to many of the other concerns you raised. It's not at > all clear what disabling GCC on x86 will buy you unless you are intending on > short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are best effort. We don't need to be quite as careful to ensure that they build with the base system compiler on tier-2 architectures. We don't make as strong guarantees about compatibility on tier-2 architectures, so removing gcc from their build at some point over the next five years is fine, but this is not the case for tier 1 architectures, where we can be reasonably expected to support anything that is in the base system for the next five years. If we remove it from the default install now, users don't expect it to keep working for the lifetime of the 10.x branch. If we leave it in, then they do. If tier-2 architectures are still using it for 10.0, that's fine, because users of tier-2 architectures don't expect everything to remain stable over the span of a release. ARM is technically Tier-2, but for the purpose of this I'm including modern ARM platforms (i.e. things like the Efika and Raspberry Pi, where we hope to get re@-supported images soon - by 10.1 if not by 10.0), but ARM EABI Hard-Float (the platform in question) is already supported by clang and so has the same level of support as x86. So let's be absolutely clear what we mean by non-x86: - Old ARM (ARMv4/ARMv5), most commonly used in microcontrollers which don't have the power to run a full base system or arbitrary ports anyway. - MIPS, which is a few months of effort in LLVM to get completely working. LLVM on MIPS is already self-hosting and I'm currently chasing the remaining issues. We are planning on releasing an open source MIPS64 implementation soon, and gcc will be the system compiler for the first release, but we'll be switching to clang very soon for that - long before 10.x goes EOL. MIPS has other serious issues (for example, gdb doesn't work at all - it can't even find the memory regions that contain the binary) and our ld is too old to support several of the GOT-related optimisations required to build large programs, so gcc is the least of its concerns, toolchain-wise. The MIPS binutils changes have not been upstreamed, so this is somewhat problematic as we don't have any useable toolchains for MIPS64, including gcc in base, for moderately-sized applications. This should be addressed some time over the next 6-12 months by switching MIPS over to LLVM / MCLinker. MIPS is perhaps the m ost important one because the new owners of MIPS are investing in LLVM quite heavily (they've been ramping up their LLVM development a lot over the last year even before the p
Re: GCC withdraw
On 29 Aug 2013, at 15:57, John Baldwin 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. Apparently I haven't been good at communicating, so I'll try to here. I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit. The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki. You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base). This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC. To summarise the current issues: Our libstdc++ is ancient. It supports C++98 well, it kind-of supports C++03. It doesn't support C++11 at all and never will, nor does it support C++14. An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build. Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions. This problem will only get worse over the coming years. An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time. Maintaining our libstdc++ is not a zero-effort operation. We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them. Maintaining out gcc is also not a zero-effort operation. Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture. Our g++ in base can only work with libstdc++, not libc++. This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs. This is setting us up for a world of pain. When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++). This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default). Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build). Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place. Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports. According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed. Our gcc does not support the ARM EABI hard float variant. I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float. This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers. This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications. We want to start shipping binary packages f
Re: GCC withdraw
On 25 Aug 2013, at 00:06, Steve Kargl wrote: > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov 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/ >> > > As if this is going to help. > > http://llvm.org/bugs/show_bug.cgi?id=8532 > > 2 years, 9 month and counting. This bug relates to a corner case in complex floating point support, which GCC in base doesn't get right either, and which affects a tiny proportion of users and which comes with a hypothetical test case but no evidence that any real-world code is affected by it. If you have some real-world code that is compiled correctly by GCC but incorrectly by clang as a result of this, then please update the bug. Oh, and it's worth noting that clang, as an extension, supports using initialiser lists to create complex values and so this particular case is trivial to avoid if you use this feature, which you will if you create complex numbers using the macro that the C specification introduced specifically to avoid this case. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov 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: GCC withdraw
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov 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 point me to the relevant LLVM bug report and I will investigate it. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw
On 24 Aug 2013, at 11:30, "Sam Fourman Jr." 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 for maintaining a fork of a 2007 release of gcc and libstdc++? David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 23:37, Warner Losh 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*), > some are no where near ready, or will never be ready (sparc64, ia64). There's > no coherent, documented plan for these absent gcc at the moment. There are > lots of pieces there, and those pieces will form the basis of the solution > (+handbook updates) for the removal of gcc in 11, but we just aren't there > yet. The plan, which has been discussed on mailing lists, on IRC, and at DevSummits is for tier 2 ports to depend on an external toolchain. For those vendors that are not prevented from using GPLv3 compilers, this means that they will be able to take advantage of, for example, the significant improvements to the MIPS and PowerPC back ends that gcc has had over the last 6 years. For everyone else, it will mean installing a compiler from ports. For now, tier 2 architectures will continue to build a toolchain from the src tree and use that. By 11.0, gcc will be gone from the base system and they will be required to use something external if they are not supported by clang. Brooks has been working hard on making this easy, and it is generally an improvement for cross-building embedded systems as the cross-compile toolchain is no longer rebuilt every time you change a file in the kernel, resulting in faster builds. It is also easier to use toolchains provided by chip vendors, which is something that MIPS and ARM vendors have been asking for for a very long time. For x86 and ARMv6/7, Clang has been the default compiler for a long time and gcc has been increasingly problematic (for example, our gcc does not support ARM EABI, which will be the default in 10.0 for ARMv6 and later, so if you want to build for a modern ARM chip then you need either clang or a more recent gcc than we ship). Claiming that this is something done at the expense of non-x86 architectures is highly misleading, as improving ARM support is one of the driving factors behind the switch. If you are shipping a product that relies on gcc, then for the 10.x timeframe, you are free to build and use the gcc from the base system, and the tinderboxes will prevent any non-optional components from being modified in such a way that they can't build with this gcc. In the 11.x timeframe, architectures that aren't supported by clang will need an external toolchain. AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing to LLVM and Clang, so the only platform that is unlikely to have an LLVM back end in the 11.0 timeframe is IA64, and if you really care about IA64 then Intel will happily sell you a compiler that does a much better job than GCC of targeting this architecture. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 13:30, Bernhard Fröhlich wrote: > lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need > to fix it first to be able to compile it with clang 3.3 from base. What is the issue with the gcc 4.2.1 build (aside from the fact that it has a terrifying number of warnings when built with any recent compiler)? The gcc 4.2.1 in base builds with clang - that's how we currently build it in head... David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On 23 Aug 2013, at 14:52, Warner Losh 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 there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 13:26, Andriy Gapon 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 yet confident in it as a > FreeBSD development tool. Nathan has already dealt with this. > I do not care about C11, C++11 and modern C++ codebases. I care about what's > in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, > of course. But, OTOH, those who care modern C++ codebases should be perfectly > capable to install a compiler from ports or switch to clang as their default > compiler. So you don't want a working debugger? Our gdb doesn't work at all on MIPS and barely works with code compiled with clang or a recent gcc. We are planning on importing LLDB soon (Ed Maste has been working on it, funded by the FreeBSD Foundation), and it is a C++11 code base. It will not build with our gcc or with our libstdc++ (and, in fact, since it uses the LLVM libraries, will require LLVM in base to link libc++). Or perhaps you don't care about flattened device trees. The device tree compiler that we have in base is written in C++ and contains numerous occurrences of ugly code to make it work with old compilers. I will be very happy to remove a load of hacks once C++11 support is available in the base system (not for 10.0, as dtc is used on a lot of tier 2 archs where gcc is still default). David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 11:42, Julian Elischer 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 is > gone we will need to support those who will be replacing clang with newer > versions of gcc in hteir own products. The plan is not to delete gcc from the tree, it is to disable building gcc by default when clang is the system compiler. If you are building products then you are perfectly at liberty to set WITH_GCC=yes in your src.conf. Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. Putting them in the base system means that people will use them. If anyone wants them to remain, then speak now and this will be taken as your volunteering to: - Maintain our forks of both gcc and libstdc++ - Handle every single PR that is filed by people using these If you are willing to do this, then that's great. If not, then you are asking other people to support ancient codebases that they are not using. 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 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 > introduced > when HEAD switched to clang as default cc. Right now there are 150 ports in > the tree that use this fallback and quite a few of them are high profile > ports: > > the highlights: > audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose > emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine > multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264 > security/clamav > > the full list: > http://dpaste.com/1354075/ > > A possible hack could be to add a check for USE_GCC=any to behave like > a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc > from ports for a lot of people on HEAD I suppose. > > We certainly need to do that switch to remove the ancient gcc from base > some time but with my portmgr hat on I can only say we don't plan to do that > before 10.0 especially not if we are only talking about a few weeks time > window. That is unfortunate. We have said for over a year that 10.0 should not ship with gcc. I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1). David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: patch to add AES intrinsics to gcc
I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. David On 22 Aug 2013, at 21:09, John-Mark Gurney wrote: > In my work to get AES-NI performance in a better state and the fact > that we haven't deprecated gcc yet, I have developed another patch to > add the appropriate AES intrinstic headers to gcc. > > The patch is available at: > https://people.freebsd.org/~jmg/gcc.aes.intrin.patch > > I did have to change the opth-gen.awk script, since it wouldn't let > me use bit 31, and recent changes to gcc used up all the remaining > bits. I also was unable to add the -mpclmul option because of running > out of these bits. > > Thanks. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 28 Jul 2013, at 22:27, Raphael Kubo da Costa wrote: > This seems to have been committed in r253321, and broke some code that > was working with r253320; namely, some code in x11/kde4-workspace > includes math.h and calls isnan() with a const double. Please provide a test case. Specifically, I need to know what language dialect this is using, because I have tested including math.h and calling isnan(double) with c89, gnu89, c99, c11, c++03 and c++11 on gcc (for the modes that it supports) and clang. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 12 Jul 2013, at 22:47, "O. Hartmann" 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 appear on previous versions): Thanks. This is now fixed, however the _Generic() usage that we had there is also present in tgmath.h, and so this file will also need to be fixed in the same way. I've now tested the macros with clang/c99, clang/c11, clang/c++98 and clang/c++11, and gcc/c89 and they all seem to work for unqualified, const, volatile, and const-volatile qualified types. I've added Ed to the cc: list, as he wrote this code in tgmath.h. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 11 Jul 2013, at 13:11, Bruce Evans 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 fixes the related test cases in the libc++ test suite. Please review. This does not use __builtin_isnan(), but it does: - Stop exposing isnan and isinf in the header. We already have __isinf in libc, so this is used instead. - Call the static functions for isnan __inline__isnan*() so that they don't conflict with the ones in libm. - Add an __fp_type_select() macro that uses either __Generic(), __builtin_choose_expr() / __builtin_choose_expr(), or sizeof() comparisons, depending on what the compiler supports. - Refactor all of the type-generic macros to use __fp_type_select(). David isnan.diff Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 11 Jul 2013, at 13:11, Bruce Evans wrote:
> 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 are trying to solve.
> The compatibility that I'm talking about is with old versions of FreeBSD.
> isnan() is still in libc as a function since that was part of the FreeBSD
> ABI and too many things depended on getting it from there. It was recently
> removed from libc.so, but is still in libm.a. This causes some
> implementation problems in libm that are still not completely solved. I
> keep having to edit msun/src/s_isnan.c the msun sources are more portable.
> Mostly I need to kill the isnan() there so that it doesn't get in the
> way of the one in libc. This mostly works even if there is none in libc,
> since the builtins result in neither being used. isnanf() is more of a
> problem, since it is mapped to __isnanf() and there is no builtin for
> __isnanf(). The old functions have actually been removed from libc.a
> too. They only in libc_pic.a. libc.a still has isnan.o, but that is bogus
> since isnan.o is now empty.
I don't see a problem with changing the name of the function in the header and
leaving the old symbol in libm for legacy code.
>> It would also be nice to implement these macros using _Generic when
>> compiling in C11 mode, as it will allow the compiler to produce more helpful
>> warning messages. I would propose this implementation:
>
>> #if __has_builtin(__builtin_isnan)
>
> This won't work for me, since I develop and test msun with old compilers
> that don't support __has_builtin(). Much the same set of compilers also
> don't have enough FP builtins.
Please look in cdefs.h, which defines __has_builtin(x) to 0 if we the compiler
does not support it. It is therefore safe to use __has_builtin() in any
FreeBSD header.
> It also doesn't even work. clang has squillions of builtins that
> aren't really builtines so they reduce to libcalls.
Which, again, is not a problem for code outside of libm. If libm needs
different definitions of these macros then that's fine, but they should be
private to libm, not installed as public headers.
> The msun implementation knows that isnan() and other classification
> macros are too slow to actually use, and rarely uses them.
Which makes any concerns that only apply to msun internals irrelevant from the
perspective of discussing what goes into this header.
>> #define isnan(x) __builtin_isnan(x)
>> #else
>> static __inline int
>> __isnanf(float __x)
>> {
>> return (__x != __x);
>> }
>
> Here we can do better in most cases by hard-coding this without the ifdef.
They will generate the same code. Clang expands the builtin in the LLVM IR to
a fcmp uno, so will generate the correct code even when doing fast math
optimisations.
>> static __inline int
>> __isnand(double __x)
>> {
>> return (__x != __x);
>> }
>
> __isnand() is a strange name, and doesn't match compiler conventions for
> builtins. Compilers use __builtin_isnan() and map this to the libcall
> __isnan().
That's fine.
>> static __inline int
>> __isnanl(long double __x)
>> {
>> return (__x != __x);
>> }
>> #if __STDC_VERSION__ >= 201112L
>> #define isnan(x) _Generic((x), \
>> float: __isnanf(x),\
>> double: __isnand(x), \
>> long double: __isnanl(x))
>
> Does _Generic() have no side effects, like sizeof()?
Yes.
>> #else
>> #define isnan(x)\
>> ((sizeof (x) == sizeof (float)) ? __isnanf(x) \
>>: (sizeof (x) == sizeof (double)) ? __isnand(x)\
>>: __isnanl(x))
>> #endif
>> #endif
>
> Both cases need to use __builtin_isnan[fl]() and depend on compiler
> magic to have any chance of avoiding side effects from loads and
> parameter passing.
> Generic stuff doesn't seem to work right for either isnan() or
> __builtin_isnan(), though it could for at least the latter. According
> to a quick grep of strings $(which clang), __builtin_classify() is
> generic but __builtin_isnan*() isn't (the former has no type suffixes
> but the latter does, and testing shows that the latter doesn't work
> without the suffices).
I'm not sure what you were testing:
$ cat isnan2.c
int test(float f, double d, long double l)
{
return __builtin_isnan(f) |
__builtin_isnan(d) |
__builtin_isnan(l);
}
$ clang isnan2.c -S -emit-llvm -o - -O1
...
%cmp = fcmp uno float %f, 0.00e+00
%cmp1 = fcmp uno double %d, 0.00e+00
%or4 = or i1 %cmp, %cmp1
%cmp2 = fcmp uno x86_fp80 %l, 0xK
...
As you can see, it parses them as generics and generates different IR for each.
I don't believe that there's a way that these would be translated back into
libcalls in the back end.
>> For a trivial example of why this
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 wrote:
> I don't see how any conforming program can access the isnan() function
> directly. It is just as protected as __isnan() would be. (isnan)()
> gives the function (the function prototype uses this), but conforming
> programs can't do that since the function might not exist. Maybe some
> non-conforming program like autoconfig reads or libm.a and
> creates a bug for C++.
The cmath header defines a template function isnan that invokes the isnan
macro, but then undefines the isnan macro. This causes a problem because when
someone does something along the lines of using namespace std then they end up
with two functions called isnan and the compiler gets to pick the one to use.
Unfortunately, std::isnan() returns a bool, whereas isnan() returns an int.
The C++ headers are not required to be conforming C code, because they are not
C, and our math.h causes namespace pollution in C++ when included from .
> The FreeBSD isnan() implementation would be broken by removing the
> isnan() function from libm.a or ifdefing it in . Changing the
> function to __isnan() would cause compatibility problems. The function
> is intentionally named isnan() to reduce compatibility problems.
On OS X this is avoided because their isnan() macro expands to call one of the
__-prefixed inline functions (which adopt your suggestion of being implemented
as x != x, for all types). I am not sure that this is required for standards
conformance, but it is certainly cleaner. Your statement that having the
function not called isnan() causes compatibility problems is demonstrably
false, as neither OS X nor glibc has a function called isnan() and, unlike us,
they do not experience problems with this macro.
It would also be nice to implement these macros using _Generic when compiling
in C11 mode, as it will allow the compiler to produce more helpful warning
messages. I would propose this implementation:
#if __has_builtin(__builtin_isnan)
#define isnan(x) __builtin_isnan(x)
#else
static __inline int
__isnanf(float __x)
{
return (__x != __x);
}
static __inline int
__isnand(double __x)
{
return (__x != __x);
}
static __inline int
__isnanl(long double __x)
{
return (__x != __x);
}
#if __STDC_VERSION__ >= 201112L
#define isnan(x) _Generic((x), \
float: __isnanf(x),\
double: __isnand(x), \
long double: __isnanl(x))
#else
#define isnan(x)\
((sizeof (x) == sizeof (float)) ? __isnanf(x) \
: (sizeof (x) == sizeof (double)) ? __isnand(x)\
: __isnanl(x))
#endif
#endif
For a trivial example of why this is an improvement in terms of error
reporting, consider this trivial piece of code:
int is(int x)
{
return isnan(x);
}
With our current implementation, this compiles and links without any warnings,
although it will have somewhat interesting results at run time. With the
__builtin_isnan() version, clang reports this error:
isnan.c:35:15: error: floating point classification requires argument of
floating point type (passed in 'int')
return isnan(x);
^
(and then some more about the macro expansion)
With the C11 version, it reports this error:
isnan.c:35:15: error: controlling expression type 'int' not compatible with any
generic association type
return isnan(x);
^
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 10 Jul 2013, at 17:33, "O. Hartmann" wrote:
> Hi David,
>
> thanks for the fast response.
>
> The code I was told to check with is this:
>
> #include
> #include
> #include
>
> int
> main(void)
> {
>
>std::cout << typeid(isnan(1.0)).name() << "\n";
>
> }
>
>
> If I compile it with
>
> c++ -o testme -std=c++11 -stdlib=libc++ source.cc
>
> and run the binary, the result is "i" which I interpret as "INT".
I believe there is a bug, which is that the math.h things are being exposed but
shouldn't be, however it is not the bug that you think it is. Try this line
instead:
std::cout << typeid(std::isnan(1.0)).name() << "\n";
We have a libm function, isnan(), and a libc++ function, std::isnan(). The
former is detected if you do not specify a namespace. I am not sure what will
happen if you do:
#include
#include
#include
using namespace std;
int
main(void)
{
cout << typeid(isnan(1.0)).name() << "\n";
}
This is considered bad form, but does happen in some code. I am not certain
what the precedence rules are in this case and so I don't know what happens.
To properly fix this, we'd need to namespace the libm functions when including
math.h in C++. This would also include fixing tweaking the macros.
A fix for your code is to ensure isnan() and isinf() are explicitly namespaced.
Potentially, this may also work:
using std::isinf;
using std::isnan;
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Hi,
On 10 Jul 2013, at 14:58, "O. Hartmann" wrote:
>
> Whe I try to compile the sources of a port in spe (devel/pocl), which
> is now out as RC6, I receive this error shown below:
>
> [...]
> ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> conversion from 'int' to 'boolvec_t' (aka 'boolvec') is
> ambiguous boolvec_t isinf() const { return std::isinf(v); }
> ^ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
> candidate constructor boolvec(bvector_t x): v(x) {}
>^
> ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
> constructor boolvec(bool a): v(a) {}
> [...]
>
> Compilation is performed on the most recent CURRENT with CLANG 3.3 and
> devel/llvm (which is obviously stuck with 3.2 for now) and option
> switches -std=c++11 -stdlib=libc++.
>
> As I was told, in standard C++11, isnan(), isinf() and fellows now
> should return "bool", not int as this seems obviously the case as the
> error documents and I was able to check with a small program.
>
> Is this a bug in FreeBSD's implementation of libc++? Or am I doing
> something wrong?
>
> I'm new to C++/C++11.
>
>
> Some advice or explanation could be helpful.
I believe that this is also causing some failures in the libc++ test suite and
is due to some interaction between our headers and the libc++ headers, but I
don't see where it is.
Our isnan implementation is a really ugly macro that looks like this:
#define>isnan(x)\
((sizeof (x) == sizeof (float)) ? __isnanf(x) \
: (sizeof (x) == sizeof (double)) ? isnan(x)\
: __isnanl(x))
The definition in the libc++ cmath header is:
#ifdef isnan
template
_LIBCPP_ALWAYS_INLINE
bool
__libcpp_isnan(_A1 __x) _NOEXCEPT
{
return isnan(__x);
}
#undef isnan
This should work correctly.
However...
I wonder if you are including math.h instead of ? That would show the
result that you appear to be seeing, which looks like the result of using the
isnan() macro rather than the isnan() function. If you have included
then the isnan() macro will have been defined.
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [CFT] gcc: support for barcelona
On 29 May 2013, at 09:51, Andriy Gapon wrote: > > Yes, that bug breaks some DTrace scripts that are critical to me. > Otherwise I would not have noticed the issue. Looking at the bug report, you filed it against clang 3.2, just after 3.3 was branched. Did you test 3.3? Is it fixed? I can only assume that, since the bug has been present in the system compiler for 6 months without your noticing that it can't be that critical... David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [CFT] gcc: support for barcelona
On 29 May 2013, at 07:57, Andriy Gapon wrote: > In fact, I am of opinion that while such bugs exist gcc should be crowned back > as a default compiler. Seriously? Your show stopper bug is that, very occasionally, clang emits incorrect debug info? And Steve's is that clang emits code that is fully compliant with the C standard, but gives more floating point precision than he wanted? If those are the most serious problems we have with clang, then it's time to remove gcc 4.2.1 from the tree right now. I wish the problems that we had with it were so trivial... David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [CFT] gcc: support for barcelona
On 28 May 2013, at 18:40, Warner Losh wrote: > That's not going to happen soon. While it works OK for amd64, there's still > many bugs in its ARM support and even more in its MIPS support. There's 0 > chance it will be gone in 10... I disagree. There is a significant chance that gcc in base will be gone for all Tier 1 platforms in 10.0. There are still some reasons to want gcc installed, but there are no compelling reasons to want an ancient version of gcc installed on x86[-64] or ARM. For people who need gcc, the ports collection provides a selection of recent versions. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: patch to add AES & PCLMUL intrinsics to gcc
On 6 May 2013, at 01:27, John-Mark Gurney wrote: > One question I have is that I copied wmmintrin.h from clang... It has a > license statement, but no copyright statement... Do I need to add one > from somewhere? The clang headers are all supposed to have a UIUC license header. If you find one that is missing, then file a bug report upstream. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Miscellaneous questions
On 3 May 2013, at 20:03, Pedro Giffuni wrote: > FWIW, The Solaris people have lived with the problem of supporting > alternative linkers for a while and they came up with LD_ALTEXEC: > > http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-solaris/ > > There even appears to be a proof-of-concept patch for binutils: > http://sourceware.org/bugzilla/show_bug.cgi?id=13863 > > Again FWIW, one of our linker experts says the patch is ugly but I > wouldn't spend time beautifying GNU ld anyways ;). The patch itself isn't ugly. The concept is, but it's probably sensible to support something like that. I'm a bit hesitant about that exact solution, because I don't like the idea of a random environment variable being able to break (or fix) kernel / world / ports builds. >> >>> 4.) lldb status >>> >>> Is this described in detail anywhere? > > I heard good things about it from a Mac developer but I haven't tried > it. We should look at it. I've used LLDB on OS X, and it is a much nicer experience than gdb. It does, however, currently lack thread and core dump support on FreeBSD. We were hoping that Cherry Mathews would work on that, but he is doing Xen stuff instead. If anyone else is interested, then we have a proposal that the FreeBSD Foundation has already agreed to fund that it would be great for someone else to pick up. The proposal is for a bit more than just finishing the LLDB port, it also includes adding a less-ugly kernel API for debuggers, replacing ptrace (extending the process descriptors that were added for capsicum to allow process control, mmap()ing of a process's address space, and creating thread descriptors, avoiding some of the race conditions that ptrace has and providing a cleaner way of copying largish quantities of data to and from the debugged process and allowing lldb to run in capability mode). > We should also start considering merging the elftoolchain. I'm a bit hesitant about pulling in too much of their stuff, because we're going to end up with a lot of code duplication if we do. Most of their utilities have LLVM equivalents, and we're already building all of the libraries that the LLVM tools depend on. At BSDCan, I'd like to spend some time in the hacker lounge on the first day with anyone who is interested going through the source tree, looking at all of the GNU stuff that we have, and checking what the replacements are going to be. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Miscellaneous questions
On 3 May 2013, at 13:52, Erik Cederstrand 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 Monday and apparently they do have enough linker script support to link the FreeBSD kernel now, but not the Linux kernel. They're currently missing version scripts (Luba Tang is working on that). They were aiming to deliver a linker that can link kernel + world with all of the options that we need for BSDCan, but apparently their schedule has now slipped by about two weeks. > Apart from this, we need a general solution to having multiple linkers > installed and choosing which one to use in general, during buildworld, for > ports etc. I plan on adding a --linker= option to clang for this. We can also start installing BDF linker as ld-bfd and mclinker as ld-mclinker (or similar) and have /usr/bin/ld be a symlink to one or the other. I think shipping a GPL-free 10.0 (with adequate testing) is not feasible in the current timeline, however I would like to have replacements for all of the GPL'd components in tree, even if not used by default, so that downstream people who really care about not having GPL'd stuff can just tweak a build knob. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: c89 broken on head?
On 7 Mar 2013, at 19:28, Dimitry Andric 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 gnu89 inline and c99 inline that old code may rely on. cc was deprecated in POSIX1997. I would be more in favour of removing it entirely than of making it default to anything other than C11. I do have a patch for clang that makes it select a more sensible default dialect when invoked as gcc, c89, c99, or c11. I'll try to push this upstream soon. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: base gcc and _GLIBCXX_USE_C99
On 4 Feb 2013, at 03:09, Pedro Giffuni 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. The libstdc++ in base is a C++03 library, and the C++03 standard does not include a long long type, nor any of the related functions. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [patch]r246028, libcxxrt's Version.map is broken
Looks good to me. I probably won't have time to do adequate testing until next week (just about to leave for FOSDEM), but I'm perfectly happy for someone else to do it before then. David On 31 Jan 2013, at 23:03, Yamaya Takashi wrote: > Hi > > After r246028, make buildworld with -stdlib=libc++ -std=c++11 is failed. > libcxxrt's Version.map is broken, because some needed symbols are removed. > > > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: C++ runtime version patch for testing
On 27 Jan 2013, at 15:52, Konstantin Belousov wrote: > On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote: > > Apparently c++filt from 2.23.1 binutils has bug, c++filt is > not able to demangle the set_new_handler. I'm using the one from head, which may be the elftoolchain project one? It seems to be missing a man page... > You need to add 'std::bad_typeid::what() const' to 3.4.9 as well, it > seems. Added > Do readelf -d and look for the needed tags. If libcxxrt > is not passed on the linker command line and not recorded as needed > in the libc++/libstdc++, it should be fine. 0x0001 (NEEDED) Shared library: [libcxxrt.so.1] This is with something compiled with -stdlib=libc++. It seems the (NEEDED) is there even if I compile with clang -lc++, instead of clang++, so the linker is adding it via the indirect dependency? Or does it show up because libc++ has that line too? > Your changes to libcxxrt obviously break the ABI, removing the symbols > from the version namespace, but my hope is that namespace for libcxxrt > is actually not part of the _system_ ABI. Thus the question. I'm okay with breaking the libcxxrt ABI at this point. libc++ is not part of the standard install, and is there for testing in 9.1. libcxxrt isn't linked against anything unless you use libc++ (or libstdc++ and a line in libmap.conf) so nothing non-experimental should use it. For 9.2, I'd like to have an ABI that we can support long term. David signature.asc Description: Message signed with OpenPGP using GPGMail
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 +0000, 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::set_new_handler(void (*)())
# objdump -T /usr/lib/libsupc++.so | c++filt | grep new_h
9010 __float128DF .text 000e GLIBCXX_3.4
std::set_new_handler(void (*)())
>> + std::set_terminate*;
>> + std::set_unexpected*;
>> + std::bad_alloc*;
>> +
>> + std::bad_alloc*;
> std::bad_alloc seems to be duplicated.
Thanks, removed.
> Besides that, pristine libstdc++.so exports 'std::bad_alloc::what() const'
> at the GLIBCXX_3.4.9 namespace. You did this for the *::what()' from
> libcxxrt but not for the libsupc++.
Ooops. I wrote a script that checked for version mismatches, but for some
reason I missed this one. Running it again, it shows two mismatches, both
fixed in the new version of the diff.
>> + std::bad_cast*;
>> + std::exception*;
>> +
>> + "typeinfo for std::bad_alloc";
>> + "typeinfo for std::bad_cast";
>> + "typeinfo for std::exception";
>> +
>> + "typeinfo name for std::bad_alloc";
>> + "typeinfo name for std::bad_cast";
>> + "typeinfo name for std::exception";
>> +
>> + "vtable for std::bad_alloc";
>> + "vtable for std::bad_cast";
>> + "vtable for std::exception";
>> +};
>> };
>>
>> CXXABI_1.3.1 {
>> Index: lib/libcxxrt/Version.map
>> ===
>> --- lib/libcxxrt/Version.map (revision 245840)
>> +++ lib/libcxxrt/Version.map (working copy)
>> @@ -209,18 +209,7 @@
>>
>> "std::type_info::type_info(std::type_info const&)";
>> "std::type_info::type_info(std::type_info const&)";
>> -"std::type_info::~type_info()";
>> -"std::type_info::~type_info()";
>> -"std::type_info::~type_info()";
>> "std::type_info::operator=(std::type_info const&)";
> [omitted]
>
> Do applications record the dependency on the libcxxrt directly,
> using the DT_NEEDED tag ?
I don't believe so, they get it indirectly via libc++ or libstdc++. How can I
check?
David
Index: gnu/lib/libsupc++/Version.map
===
--- gnu/lib/libsupc++/Version.map (revision 245840)
+++ gnu/lib/libsupc++/Version.map (working copy)
@@ -130,6 +130,13 @@
*;
};
+GLIBCXX_3.4.9 {
+extern "C++" {
+"std::bad_alloc::what() const";
+"std::bad_cast::what() const";
+};
+};
+
GLIBCXX_3.4 {
# operator new and new[]
_Znai[jm];
@@ -142,6 +149,27 @@
_ZdaPvRKSt9nothrow_t;
_ZdlPv;
_ZdlPvRKSt9nothrow_t;
+extern "C++" {
+ std::set_new_handler*;
+ std::set_terminate*;
+ std::set_unexpected*;
+
+ std::bad_alloc*;
+ std::bad_cast*;
+ std::exception*;
+
+ "typeinfo for std::bad_alloc";
+ "typeinfo for std::bad_cast";
+ "typeinfo for std::exception";
+
+ "typeinfo name for std::bad_alloc";
+ "typeinfo name for std::bad_cast";
+ "typeinfo name for std::exception";
+
+ "vtable for std::bad_alloc";
+ "vtable for std::bad_cast";
+ "vtable for std::exception";
+};
};
CXXABI_1.3.1 {
Index: lib/libcxxrt/Version.map
===
--- lib/libcxxrt/Version.map(revision 245840)
+++ lib/libcxxrt/Version.map(working copy)
@@ -209,18 +209,7 @@
"std::type_info::type_info(std::type_info const&)";
"std::type_info::type_info(std::type_info const&)";
-"std::type_info::~type_info()";
-"std::type_info::~type_info()";
-"std::type_info::~type_info()";
"std::type_info::operator=(std::type_info const&)";
-"std::unexpected()";
-"std::get_terminate()";
-"std::set_terminate(void (*)())";
-"std::get_unexpected()";
-"std::set_unexpected(void (*)())";
-"std::set_new_handler(void (*)())";
-"std::uncaught_exception()";
-"std::terminate()";
# Extensions
@@ -243,70 +232,25 @@
CXXRT_1.0 {
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 now. Please let me know if there are any problems with
this, otherwise I'll aim to commit it today or tomorrow with a 1-week MFC.
David
Index: gnu/lib/libsupc++/Version.map
===
--- gnu/lib/libsupc++/Version.map (revision 245840)
+++ gnu/lib/libsupc++/Version.map (working copy)
@@ -142,6 +142,28 @@
_ZdaPvRKSt9nothrow_t;
_ZdlPv;
_ZdlPvRKSt9nothrow_t;
+extern "C++" {
+ std::set_new_handler*;
+ std::set_terminate*;
+ std::set_unexpected*;
+ std::bad_alloc*;
+
+ std::bad_alloc*;
+ std::bad_cast*;
+ std::exception*;
+
+ "typeinfo for std::bad_alloc";
+ "typeinfo for std::bad_cast";
+ "typeinfo for std::exception";
+
+ "typeinfo name for std::bad_alloc";
+ "typeinfo name for std::bad_cast";
+ "typeinfo name for std::exception";
+
+ "vtable for std::bad_alloc";
+ "vtable for std::bad_cast";
+ "vtable for std::exception";
+};
};
CXXABI_1.3.1 {
Index: lib/libcxxrt/Version.map
===
--- lib/libcxxrt/Version.map(revision 245840)
+++ lib/libcxxrt/Version.map(working copy)
@@ -209,18 +209,7 @@
"std::type_info::type_info(std::type_info const&)";
"std::type_info::type_info(std::type_info const&)";
-"std::type_info::~type_info()";
-"std::type_info::~type_info()";
-"std::type_info::~type_info()";
"std::type_info::operator=(std::type_info const&)";
-"std::unexpected()";
-"std::get_terminate()";
-"std::set_terminate(void (*)())";
-"std::get_unexpected()";
-"std::set_unexpected(void (*)())";
-"std::set_new_handler(void (*)())";
-"std::uncaught_exception()";
-"std::terminate()";
# Extensions
@@ -243,70 +232,25 @@
CXXRT_1.0 {
extern "C++" {
-"std::bad_cast::what() const";
-"std::bad_typeid::what() const";
-"std::bad_alloc::what() const";
-"std::exception::what() const";
"std::type_info::name() const";
"std::type_info::before(std::type_info const&) const";
"std::type_info::operator==(std::type_info const&) const";
"std::type_info::operator!=(std::type_info const&) const";
-"std::bad_typeid::bad_typeid(std::bad_typeid const&)";
-"std::bad_typeid::bad_typeid()";
-"std::bad_typeid::bad_typeid(std::bad_typeid const&)";
-"std::bad_typeid::bad_typeid()";
-"std::bad_typeid::~bad_typeid()";
-"std::bad_typeid::~bad_typeid()";
-"std::bad_typeid::~bad_typeid()";
-"std::bad_typeid::operator=(std::bad_typeid const&)";
"std::bad_cast::bad_cast(std::bad_cast const&)";
"std::bad_cast::bad_cast()";
"std::bad_cast::bad_cast(std::bad_cast const&)";
"std::bad_cast::bad_cast()";
-"std::bad_cast::~bad_cast()";
-"std::bad_cast::~bad_cast()";
-"std::bad_cast::~bad_cast()";
"std::bad_cast::operator=(std::bad_cast const&)";
-"std::bad_alloc::bad_alloc(std::bad_alloc const&)";
-"std::bad_alloc::bad_alloc()";
-"std::bad_alloc::bad_alloc(std::bad_alloc const&)";
-"std::bad_alloc::bad_alloc()";
-"std::bad_alloc::~bad_alloc()";
-"std::bad_alloc::~bad_alloc()";
-"std::bad_alloc::~bad_alloc()";
-"std::bad_alloc::operator=(std::bad_alloc const&)";
"std::exception::exception(std::exception const&)";
"std::exception::exception()";
"std::exception::exception(std::exception const&)";
"std::exception::exception()";
-"std::exception::~exception()";
-"std::exception::~exception()";
-"std::exception::~exception()";
"std::exception::operator=(std::exception const&)";
-"vtable for std::bad_typeid";
-"vtable for std::bad_cast";
-"vtable for std::bad_alloc";
-"vtable for std::exception";
-"vtable for std::type_info";
-"typeinfo for std::bad_typeid";
-"typeinfo for std::bad_cast";
-"typeinfo for std::bad_alloc";
-"typeinfo for std::exception";
-"typeinfo for std::type_info";
-"typeinfo name for std::bad_typeid";
-"typeinfo name for std::bad_cast";
-"typeinfo name for std::bad_alloc";
-"typeinfo name for std::exception";
-"typeinfo name for std::type_info";
-"std::type_info::__is_function_p() const";
-"std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*,
void**) const";
-"std::type_info::__is_pointer_p() con
Re: Removing default build of gcc
On 26 Jan 2013, at 15:22, Konstantin Belousov wrote: > Your initial assesment of the problem as a misbehaviour of the combination > of filtering and versioning made no sense to me, I asked you to provide > the isolated test case, which you did not. The test case in the PR was such a test case. libstdc++ and libsupc++ export a few symbols (including the ones that I mentioned in the email that you are replying to) with different versions. The end result is that you get some cases where some code (typically in libsupc++) I am not claiming that this is an rtld bug, so I don't know why you keep going on about it as if I am. I do not know why you want me to provide you with an isolated test case for a bug that is assigned to me and that I am in the process of fixing. > Our implementation of filters indeed only allows for the filtered > symbol to have the same version as the filtee symbol. I re-read the > SUN documentation about filters (who had designed them), and looked at > what Linux does there. It seems to me that Sun document spirit forces > us to behave in a way which our rtld currently does. Linux behaviour is > useless there, IMHO, since their rtld just inserts filtee before filter > in the global lookup order (I may be wrong there). This is COMPLETELY IRRELEVANT to the bug in question, which is that our libcxxrt and libsupc++ version scripts have some incorrect symbol versions. > I do suggest (again) that the way to fix the issue is to provide the > isolated test-case and decide if the behaviour of rtld is right. It is correct. I am not claiming it is incorrect. I don't know why you keep repeating that I am. > If we > conclude that the problem is not in rtld but in the versioning mismatch > between libraries (libstdc++ and libsupc++), I again suggest to provide > the patch for review first. The ABI seems to become too unwieldly, and > making ad-hoc changes there could paint us into the corner. I have a patch, which fixes it in some cases and has been tested, but misses some others. I am preparing a patch that fixes the versioning consistently across libsupc++ and libcxxrt to match libstdc++. I want to do this as a single patch, rather than an ad hoc series of changes. My aim is, as it has always been, to preserve the existing ABI. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Removing default build of gcc
On 25 Jan 2013, at 19:59, Konstantin Belousov wrote: > I am really tired of the constant struggle against the consumation of > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > are we fine with broken C++ runtime in 9 ? Please can you stop the FUD here? It really isn't helpful. We have a working C++ runtime in 9.1: libcxxrt. In fact, we have a working C++11 stack in 9.1, with the combination of libcxxrt, libc++, and clang++. Unfortunately, the filter library configuration for libsupc++ left some symbols in the wrong symbol version (the ABI library version instead of the STL library version) and so there are some issues in corner cases[1], which I am working on fixing. I have a fix for the most common corner cases, but I want to make sure that I have caught all of them before I commit. This will happen tomorrow. The filter library is very important to have working for 10.0, because we will need the ports and compat versions of libstdc++ to use it if we want to be able to mix code that uses libstdc++ (i.e. any ports that don't work correctly with libc++) and libc++ (i.e. any ports that use C++11, which is going to be an increasing number over the next few years). David [1] In particular, terminate handlers are not correctly set, and exceptions thrown from the runtime library are not of the expected type. This means that C++ code that calls std::set_terminate() will not work and neither will code that calls __cxa_bad_alloc() and friends and then tries to catch the resulting exception. The only code I have seen that actually does this is a test case that I wrote for libcxxrt. In general, code encountering either of these problems is already in a very broken state and the only difference you will see is a less helpful error message before it crashes. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Removing default build of gcc
On 25 Jan 2013, at 14:03, Andriy Gapon wrote: > on 25/01/2013 15:21 David Chisnall said the following: >> This is something that has been said on mailing lists, at BSDCan and at >> DevSummits in the past, without any objections being raised. > > A simple test - has there been a core decision that no GPL software must be > shipped with 10.x? There can be no such decision until it's all of the bits of GPL'd code in base have replacements in and testing has happened. That is why it is a plan, not an accomplished goal. This is why we have the wiki page tracking the progress of replacements: https://wiki.freebsd.org/GPLinBase David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing default build of gcc
On 25 Jan 2013, at 11:31, Konstantin Belousov wrote: > To clarify: there is no plans to not ship any GPLed code for 10.x. This is something that has been said on mailing lists, at BSDCan and at DevSummits in the past, without any objections being raised. If this is no longer a goal, then that is very sad, because we have currently a window in which a lot of potential downstream users are looking for a GPL-free stack and are put off FreeBSD and towards proprietary solutions because we still require GPL'd code for a working base system. If we put off this goal for another two years, we are likely to lose a lot of potential corporate contributors, who will invest in in-house and proprietary systems instead. > Instead, there are still plans to ship working 10.x. I don't believe that these are contradictory goals and would certainly not ever prefer a non-working system to a working one. Indeed, in many cases the alternative is a non-working system. For example, the debugger that we ship doesn't understand DWARF4 generated by any modern compiler (including gcc or clang). David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Removing default build of gcc
Hi All, In 10.0, the plan is not to ship any GPL'd code, so I'd like to start disconnecting things from the default build, starting with gcc. I've been running a gcc-free system for a while, and I think all of the ports that don't build with clang are now explicitly depending on gcc. Does anyone have strong opinions on when would be a good time for head on x86 and x86-64 to default to not building gcc? David signature.asc Description: Message signed with OpenPGP using GPGMail
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 signature.asc Description: Message signed with OpenPGP using GPGMail
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 +0000, 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 confused due to filter >>> providing >>> some symbols. >>> >>> But I did not investigated the cause for real. >> >> The issue appears to be that the libstdc++ exports a few functions[1] that >> libsupc++ exports, but with different symbol versions. Unfortunately, these >> are things that set handlers that are then called from libsupc++ / libcxxrt >> when, for example, an exception specification violation is encountered. >> >> I'm not sure what the solution is here. Is there some version-script-foo >> that we can do to say 'filter this symbol with this version as if it were >> this one with this version'? We ideally want to keep them with the current >> version in libcxxrt / libsupc++, but not introduce linker errors. >> >> David >> >> [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected() > > Can you prepare the minimal isolated test case which demostrates the > behaviour ? A plan would be to ask somebody to run the test on the linux. > I think we must be bug-to-bug compatible with glibc in regard to the > filters quirks. I'm not sure what you want the test case to demonstrate. I have a reduced form of the exception test case, but it only fails for us because of the symbol versioning issue. Moving the relevant symbols into the same version in our libsupc++ and libcxxrt as in libstdc++ fixes it (and is probably the right thing to do. On closer inspection both already expose new and delete in this symbol version namespace, so it's fine to add a few more). > Gnu filters work only on the whole object scope. Solaris linkers do > have per-symbol filtering, but Solaris does not implement per-symbol > versioning, on the other hand. If you want a simple test case for the filter behaviour, the recipe is: Symbol X in filter with version A Symbol X in filtee with version B Symbol Y in program uses symbol X Program sees version A, filtee sees version B. David signature.asc Description: Message signed with OpenPGP using GPGMail
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. The issue appears to be that the libstdc++ exports a few functions[1] that libsupc++ exports, but with different symbol versions. Unfortunately, these are things that set handlers that are then called from libsupc++ / libcxxrt when, for example, an exception specification violation is encountered. I'm not sure what the solution is here. Is there some version-script-foo that we can do to say 'filter this symbol with this version as if it were this one with this version'? We ideally want to keep them with the current version in libcxxrt / libsupc++, but not introduce linker errors. David [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected() signature.asc Description: Message signed with OpenPGP using GPGMail
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 this. It seems that the issue still appears when using libcxxrt instead of libsupc++ with libstdc++ (the test cases work fine with libc++ and libcxxrt), so it is likely some symbol confusion in libstdc++. My guess would be that it's using pointer comparison for the exception type info names and these are somehow different as a result of the filter library mode. I'll investigate further later today. David signature.asc Description: Message signed with OpenPGP using GPGMail
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
process-shared mutexes (they've been in POSIX since 1997, so it's probably
getting on for time we did), as the current mutex-is-a-pointer implementation
depends on the virtual address space of the creator, and so does not work if
the mutex is created in a shared memory segment.
That said, even with the current implementation we wouldn't need to expose the
entire mutex structure, just the word that is used as the fast path. The
inline version would be something like:
struct pthread_mutex_header
{
_Atomic(long) lock_word;
// other private fields not exposed in header;
};
typedef struct pthread_mutex_header *pthread_mutex_t;
// Implementation in libthr / libc, which calls into the kernel.
int pthread_mutex_lock_slowly(pthread_mutex_t*);
inline int pthread_mutex_lock(pthread_mutex_t *mutex)
{
int desired = 0;
if (atomic_compare_exchange_weak_explicit(&(*mutex)->lock_word,
&desired, 1, memory_order_acquire, memory_order_relaxed))
return 0;
return pthread_mutex_lock_slowly(mutex);
}
The slow path is only needed when the mutex can't be acquired trivially in
userspace. On x86, the fast path adds 6 extra instructions, including a branch
that can be statically hinted if we want (assume that we won't be going down
the slow path, because a mispredicted branch doesn't add much to the cost of
the syscall if we are).
The corresponding saving is that we get to delete a massive pile of
conditionals that we currently have for __is_threaded. We'd also completely
avoid the function call (which is actually two function calls, as we do some
trampoline things in libc) in the fast-path case for threaded applications.
A similar saving is possible with read-write locks and possibly with condition
variables, although our kernel interface for these is incredibly poorly
documented (for once, Linux actually has better documentation: futexes are very
well documented). Looking in umtx.h, it sort-of exposes inline functions that
look like this, but given the complete lack of documentation, I have no idea
how useable they are.
David
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 for the unthreaded environment then > takes advantage of this by not even allocating memory for mutexes in > some cases. It's worth taking a step back and asking why this code exists at all, and the main reason is that acquiring a mutex used to be really expensive. It still is on some fruit-flavoured operating systems, but elsewhere it's a single atomic operation in the uncontended case, and in that case the cache line will already be exclusively owned by the calling core in single-threaded code. I would much rather that we followed the example of Solaris and made the multithreaded case fast and the default than keep piling on hacks that allow code to shave off a few clock cycles in the single-threaded case. In particular, the popularity of multicore systems means that it is increasingly rare for code to be both single threaded and performance critical, so this seems like misplaced optimisation. I strongly suspect that making it possible to inline the uncontended lock case for a pthread mutex and eliminating all of the branches on __isthreaded would give us a net speedup in both single and multithreaded cases. > This __gthread_active_p() thing is another barrier to bringing in a > threaded plugin in an unthreaded application. Ports people spend a fair > amount of time adding -pthread flags to things (such as perl) to work > around this. This and the similar checks in libc cause a lot of pain, and it seems that the correct fix is ensuring that the performance penalty for linking libthr is so small that there is no point in avoiding it. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: LLVM Image Activator
Hi Nathan, I'm very interested in making better use of LLVM in our infrastructure. It would also be nice to be able to integrate this with rtld, so that we can load shared libraries that contain LLVM IR. Beyond that, there are a few long-term projects that I have in mind: - Run passes that add code for collecting profiling information before running code invoked in this way. - Recompile on subsequent invocations based on the collected profiling information. - Specialise installed shared libraries based on the programs that link to them, so that if foo band bar both link to libbaz, but use it in very different ways, they get different versions compiled specifically for them. - Statically compile and cache programs invoked with the JIT, so that they are very fast on their second run. This would probably want a periodic job to remove old caches. I have written code in LanguageKit for doing several of these things, but it would be nicer to have them done at the system level, rather than at the level of a front end. I'd also like to start using the LLVM JIT for accelerating various other functions. I have a proof-of-concept JIT for BPF that uses LLVM and I'd like to extend this to pf/ipf firewall rules. David On 6 Jan 2013, at 18:02, Nathan Whitehorn wrote: > Having LLVM/clang in the base system lets us do some interesting things > that we couldn't do with GCC. One is that LLVM ships with a JIT for LLVM > IR as well as components of a toolchain for it (this is what Google's > pNACL uses) and that you can end up producing binary files that are in > IR instead of native code. The IR isn't really cross-platform, but does > let you do CPU-specific optimizations when executed by the JIT, etc. > > The attached patch causes the LLVM JIT (lli) to be built by default > (adding ~20 seconds to buildworld on my five-year-old laptop) and adds a > kernel image activator that invokes it when passed LLVM bitcode files. > It's not completely finished (see the XXX comment in the middle), but it > does work, as follows: > > $ clang -emit-llvm -c -o hw.ll hw.c > $ file hw.ll > hw.ll: LLVM bitcode > $ lli hw.ll > Hello world! > $ chmod a+x hw.ll > $ ./hw.ll > Hello world! > $ > > Is there any interest in having features like this? It seems like this > could provides some interesting possibilities for us and nice > integration from having imported clang into base. > -Nathan > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 patch is probably a good idea. I'll try to ensure that there is infrastructure in clang for selecting the linker by that time as well. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 ld-bfd and ld being a symlink to one of them). > > Yes, a symlink is of course an easy solution post-install. But 'ld' is built > as part of 'make toolchain', I believe, so this approach wouldn't work if I > wanted mclinker to be used as the linker in 'make buildworld'. The newly > built 'ld' in /usr/obj/ would be used as the linker instead. That's why I said 'and in the bootstrap'. You'd also need to ensure that the bootstrap build of clang and binutils set up the symlink. Purely for testing, I think you can do this manually by doing the bootstrap and then the buildworld as separate make invocations. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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). A better solution would be to teach clang about mclinker. I was pondering adding a linker selection flag, along the lines of the existing -stdlib= for selecting the C++ standard library, as you may want to pass different options to different linkers. David On 13 Dec 2012, at 12:36, Erik Cederstrand wrote: > Hi folks, > > I'm working with Pete Chou from MCLinker (actually, he's doing almost all the > work) to get mclinker to survive a buildworld. The goal is to allow mclinker > to be a drop-in replacement for GNU ld. > > My first suggestion was to just add LD=/usr/local/bin/mclinker to src.conf. > But this only works when ld is invoked explicitly (and only when 'ld' is not > hard-coded, of course). > > When ld is invoked internally by the compiler, Pete has tested that > gcc(collect2) and clang do not respect the LD variable, but search for 'ld' > in COMPILER_PATH and then PATH instead. Since mclinker is not part of the > build process, it isn't found in COMPILER_PATH, and GNU ld is used instead. > Instead, he can add an additional compiler search path via the "-B" flag, > which seems to work. > > I'm worried that 'ld' is so hard-wired everywhere that it's impossible to > specify another name. In that case, my suggestion would be to use build > knobs, e.g. WITH_GNU_LD and WITH_MCLINKER_LD to install either GNU ld or > mclinker as 'ld', but that wouldn't work unless mclinker is imported into > base. > > What's the FreeBSD way of doing this? What do other toolchains do if they use > a non-GNU ld linker? > > Thanks, > Erik > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 ) should work in C++98 / C++03 mode, however the >> implementation in libc++ must be compiled in C++11 mode. > > Minor note: we now use -std=c++0x by default for building libc++, so > shall I update that to -std=c++11? Yes, if we've now got a clang in base that understands that. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi
On 23 Nov 2012, at 21:27, Dimitry Andric wrote: > Note there are also other problems when compiling libc++ with -std=c++98 > and -std=c++03, such as complaints about namespacing and such. I am not > entirely sure libc++ is fully supported yet under those restrictions. :) In theory, the libc++ headers that are part of the C++03 spec (i.e. not things like ) should work in C++98 / C++03 mode, however the implementation in libc++ must be compiled in C++11 mode. To upstream this patch, the __LONG_LONG_SUPPORTED flag should be unconditionally set for non-FreeBSD flags in the __config file in libc++. This will have no functionality change on other platforms. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Fwd: [LLVMdev] Announcing 3.2 Release Schedule
The only outstanding bug on my radar for 3.2 is related to Objective-C exceptions, but if there's anything FreeBSD-related then please let me know. Otherwise, please test with FreeBSD and with your favourite ports. We'll try to import 3.2 soon after its release. David Begin forwarded message: > From: Pawel Wodnicki > Subject: [LLVMdev] Announcing 3.2 Release Schedule > Date: 9 October 2012 07:23:21 GMT+01:00 > To: cfe-...@cs.uiuc.edu, llvmdev > > Extra! Extra! Read all about the LLVM/Clang 3.2 release. > > Barring any unforeseen circumstances we would like to materialize > this 3.2 Dragon by December the 16th, so here are couple of dates > to remember. > > Developers > > All major features for the 3.2 release should be finished > (feature complete) by the November 29th. > > After November 29, we will accept only bug fixes and patches > for *release blocking* issues which do not change the functionality > of LLVM and Clang. i.e., if your feature isn't finished, then > it may have to be turned off by default. > > After the branching date on November 11th it will be up to the > code maintainers to approve any patches. However, I will make > the decision whether to include the patch in the release. > > Testers > > WE WANT YOU! > > This release can not happen without you! So if you would like to > be a tester, do not think twice about it and please get in touch > with me by email. > > > Schedule > > November 11: Branching for the 3.2 release > > November 12-13 : Phase 1 - release candidate 1 binaries generated and > available for download > > November 13-29 : Phase 1 - testing release candidate 1 and bug fixing > for Phase 1 > > November 29: End of Phase 1 - LLVM 3.2 feature complete, Release > notes finalized > > November 29-30 : Phase 2 - release candidate 2 binaries generated and > available for download > > November 30-12 : Phase 2 - testing release candidate 2 and bug fixing > *only release blocking* bugs > > December 12-13 : Final binaries generated and tested for critical > issues, *no bug fixing* > > December 14-15 : Website updated, signed binaries ready for download > > December 16: LLVM/Clang 3.2 released > > > 2012 Dates to consider > Dev meeting November 7-8 > Thanksgiving November 22-25 > ChristmasDecember 25-2 > > > Pawel > > ___ > LLVM Developers mailing list > llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: enabling libc++ by default when building with clang
On 17 Sep 2012, at 20:10, Brooks Davis wrote:
> One key question is, when do we want to throw this switch? Do we do it
> now so people using clang start using it sooner or do we wait until
> we've switched the default compiler and things have settled a bit?
As dim says, enabling it does not mean requiring things to use it. I would
like to flip this switch as soon as possible so that it's easy for ports people
maintaining C++ ports to see if their stuff breaks with -stdlib=libc++. A few
have already tested this, but I'd like to see much wider testing.
The more important switches to worry about are:
- Changing the default for -stdlib= to libc++ (it's currently libstdc++. I
think I'll probably make it libc++ when std={c,gnu}++11 soon)
- Removing libstdc++ from base and putting it in the compat9 port.
These have the potential to impact users significantly. Simply having
libc++.{so,a} on their system does not unless they explicitly choose to test it.
David___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
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 reports upstream. We can't fix bugs if we aren't made aware of them. David Current hat: LLVM / Clang developer.___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
