Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc
On 02/14/16 14:34, Mark Millard wrote: clang's code base is not familiar material for me nor do I have solid reference material for the FreeBSD TARGET_ARCH=powerpc ABI rules so the below has my guess work involved. The following code appears to have hard wired a global, unvarying constant (8) into the test for picking UsingRegs vs. UsingOverflow. For reference, we use the standard ELF ABI (https://uclibc.org/docs/psABI-ppc.pdf). -Nathan ___ 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 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Which compiler are you building with? Just using the normal lang/gcc works for me without issue doing make install in lang/clang36. Are you sure you don't have any local diffs or stale files? -Nathan On 03/16/15 17:18, Mark Millard wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string,int, int) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being likely to be powerpc64 specific would be my guess. May be that it bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === Mark Millard markmi at dsl-only.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 ___ 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: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue
This is not the right one. That is related to clang 3.4. The issue is
that clang 3.5+ require a C++11 compiler to build. GCC 4.2 is not a
C++11 compiler and so the clang build was disabled. This makes the
upgrade path when clang becomes the default compiler a little bumpy, but
that did not seem to be a reason to hold off on the 3.5 upgrade across
the board.
-Nathan
On 03/12/15 10:01, Mark Millard wrote:
Well there is an entry but when I read it I did not find it clear about the
10.x status.
I think the implication is that the 9.x paragraph also applies to 10.x:
On 9.x [and 10.x] installations where clang is enabled by default,
e.g. on x86 and
powerpc, libc++ will not be enabled by default, so libc++ should be
built (with clang) and installed first. If both clang and libc++ are
missing, build clang first, then use it to build libc++.
===
Mark Millard
mar...@dsl-only.net
On 2015-Mar-12, at 05:00 AM, Warner Losh i...@bsdimp.com wrote:
On Mar 12, 2015, at 6:36 PM, Mark Millard mar...@dsl-only.net wrote:
Basic context for the observation (powerpc64 example):
# freebsd-version -ku; uname -a
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11
19:23:14 PDT 2015
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG
powerpc
As COMPILER_FEATURES context first I note that bsd.compiler.mk uses the rule...
.if ${COMPILER_TYPE} == clang || \
(${COMPILER_TYPE} == gcc ${COMPILER_VERSION} = 40800)
COMPILER_FEATURES= c++11
.else
COMPILER_FEATURES=
.endif
So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless COMPILER_TYPE has
been forced to be clang or ${CC} already is clang based.
But src.opts.mk will never indicate to build clang when
!${COMPILER_FEATURES:Mc++11} : that logic has priority over things like
${__T:Mpowerpc*} tests…
Clang can only be built by a new gcc or clang. Old gcc can’t build it, so if
you don’t have a new gcc, you can’t build clang. The default compiler was gcc
on 10.1. There likely should be an UPDATING entry to make this clear.
Warner
.include bsd.compiler.mk
.if !${COMPILER_FEATURES:Mc++11}
# If the compiler is not C++11 capable, disable clang and use gcc instead.
__DEFAULT_YES_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX
__DEFAULT_NO_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC
.elif ${__T} == amd64 || ${__T} == i386
# On x86, clang is enabled, and will be installed as the default cc.
__DEFAULT_YES_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC
__DEFAULT_NO_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX
.elif ${__TT} == arm ${__T:Marm*eb*} ==
# On little-endian arm, clang is enabled, and it is installed as the default
# cc, but since gcc is unable to build the full clang, disable it by default.
__DEFAULT_YES_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_IS_CC
__DEFAULT_NO_OPTIONS+=CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX
.elif ${__T:Mpowerpc*}
# On powerpc, clang is enabled, but gcc is installed as the default cc.
__DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX
__DEFAULT_NO_OPTIONS+=CLANG_BOOTSTRAP CLANG_IS_CC
.else
# Everything else disables clang, and uses gcc instead.
__DEFAULT_YES_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX
__DEFAULT_NO_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC
.endif
By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend on testing
!${COMPILER_FEATURES:Mc++11} (or analogous) before deciding for
powerpc/powerpc64...
# Clang is only for x86, powerpc and little-endian arm right now, by default.
.if ${__T} == amd64 || ${__T} == i386 || ${__T:Mpowerpc*}
__DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL
.elif ${__T} == arm || ${__T} == armv6
__DEFAULT_YES_OPTIONS+=CLANG
# GCC is unable to build the full clang on arm, disable it by default.
__DEFAULT_NO_OPTIONS+=CLANG_FULL
.else
__DEFAULT_NO_OPTIONS+=CLANG CLANG_FULL
.endif
# Clang the default system compiler only on little-endian arm and x86.
.if ${__T} == amd64 || ${__T} == arm || ${__T} == armv6 || \
${__T} == i386
__DEFAULT_YES_OPTIONS+=CLANG_IS_CC
# The pc98 bootloader requires gcc to build and so we must leave gcc enabled
# for pc98 for now.
.if ${__TT} == pc98
__DEFAULT_NO_OPTIONS+=GNUCXX
__DEFAULT_YES_OPTIONS+=GCC
.else
__DEFAULT_NO_OPTIONS+=GCC GNUCXX
.endif
.else
# If clang is not cc, then build gcc by default
__DEFAULT_NO_OPTIONS+=CLANG_IS_CC
__DEFAULT_YES_OPTIONS+=GCC
# And if g++ is c++, build the rest of the GNU C++ stack
.if defined(WITHOUT_CXX)
__DEFAULT_NO_OPTIONS+=GNUCXX
.else
__DEFAULT_YES_OPTIONS+=GNUCXX
.endif
.endif
===
Mark Millard
markmi at dsl-only.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
___
freebsd-toolchain@freebsd.org mailing list
Re: GCC withdraw
On 08/30/13 00:35, David Chisnall wrote: On 30 Aug 2013, at 08:18, Julian Elischer jul...@freebsd.org wrote: As far as I'm concerned we can even slate it for possible removal in 10.2-- if clang has proven up to the task I would be happy to ship gcc, as long as: - It's explicitly marked as deprecated and due for removal at some point in the 10.x timeframe. - libstdc++ is gone (the amount of pain it's causing ports is phenomenal). 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. -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
Re: patch to add AES intrinsics to gcc
On 08/25/13 18:41, Gerald Pfeifer wrote: On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. It would be particularly nice if we had a port with FreeBSD's many patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on powerpc64, for example, while our in-tree GCC does. -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
Re: patch to add AES intrinsics to gcc
On 08/23/13 07:26, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: 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. 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. This isn't even true. As CPUs gain new features, the set of available intrinsics gets more and more ancient, requiring ever more patching, workarounds, and #ifdef. Just look at the original subject of this thread! We're just talking about the default of a make.conf setting here. Switching to clang is a long-term goal of the project for good reason. Other vendors (Apple, for instance) have made the plunge first. This seems like as good a time as any to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial to change back at any time. -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
Re: LLVM Image Activator
On 01/13/13 05:20, Konstantin Belousov wrote: On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: Hi Kostik, 2013/1/7 Konstantin Belousov kostik...@gmail.com: I still do remember the buzz about the binary format 0xCAFEBABE, which AFAIR gained image activator support on several OSes, to be garbage collected. Maybe it would then be a good idea then to add some kind of general purpose remapping imgact? Example: /etc/imgacttab: cafebabe /usr/local/bin/java cffaedfe /usr/local/bin/osx_emulator 4243c0de /usr/bin/lli That way we still give people the freedom to play around with mapping their own executable formats, but don't need to maintain a bunch of imgacts. A generic module that could be somewhat customized at runtime to map offset+signature into the shebang path could be a possibility indeed. I strongly prefer to have it as module and not enabled by default. Asking Nathan for writing the thing is too much, IMHO, esp. in the response to the 50-lines hack. I think this is a good idea, since it both prevents a profusion of similar activators and works nicely in jails and similar environments. I probably won't write it quickly, but it should not take more than about 50 lines, so I can't imagine it will be that bad. There are some complications with this kind of design from the things in the XXX comment in imgact_llvm.c about handling argv[0] that I need to think some more about. Why are you opposed to having it there by default? I think it's actually quite important that it be there by default. Having it not standard would be fine, but it should at least be in GENERIC. There are minimal security risks since it just munges begin_argv and doesn't even load the executable and it's little enough code that there should not be any kernel bloat to speak of. If things like this aren't enabled by default, no one can depend on them being there, no one will use it, and the point is entirely lost. -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
Re: LLVM Image Activator
On 01/07/13 08:25, David Naylor wrote: Hi, Just my 2c On Sunday, 6 January 2013 20:02:21 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. Would it be possible to have this as a module (and thus in ports)? Or, perhaps, change the sources such these things could be loaded as a module... We do support that, but I'm not really sure what would be gained. We have LLVM in base; it seems a shame not to use it. Also, with modification to LLVM, wouldn't the existing '#!' mechanism work (aka '#!/usr/bin/lli') at the beginning of the file? In principle, yes, but we'd have to coordinate that with a lot of players since a number of tools operate on LLVM bitcode. The other obstacle is that LLVM bitcode is a giant binary blob, not text, so the standard #! seems a little out of place. On an aside. Could you imagine shipping a 'x86' llvm-byte code and get the jit (with caching), thus your computer will get full support (speed) from the binaries and the binaries will work on all 'x86' related architectures. (My thinking is for things like i386 vs pentium4). Yes, this is exactly the kind of thing I had in mind. -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
