Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Ryan Stone]

On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric  wrote:

> Solution B is problematic because arm_neon.h uses stdint.h types
> extensively.
>

If I manually modify the arm_neon.h file to instead say this, the problem
is avoided and the kernel builds:

#ifdef _KERNEL
#include 
#else
#include 
#endif

Do you think that the llvm devs would be willing to take a change to
NeonEmitter that does this on FreeBSD?

This may not be a complete solution, though, as googling seems to indicate
that gcc also provides a arm_neon.h and it also #includes 
___
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 (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload

[Ryan Stone]

This should have been fixed in r276760:

https://svnweb.freebsd.org/changeset/base/279760
___
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

[Ryan Stone]

On Mon, Jun 9, 2014 at 10:44 PM, Ed Maste ema...@freebsd.org wrote:
 On 9 June 2014 21:48, Ryan Stone ryst...@gmail.com wrote:
 abi::__cxa_demangle is giving me an invalid result if I pass it a
 symbol that is not mangled.  This is causing me problems as in my
 application, I'm getting symbol names from libelf and have no way of
 know a priori whether a symbol is mangled or not.

 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.

You're right, it is a problem in Linux:

[rstone@rstone-desktop shm]./demangle f
__cxa_demangle(f) = float, status=0
[rstone@rstone-desktop shm]./demangle i
__cxa_demangle(i) = int, status=0
[rstone@rstone-desktop shm]./demangle m
__cxa_demangle(m) = unsigned long, status=0
[rstone@rstone-desktop shm]./demangle main
__cxa_demangle(main) = (null), status=-2

The GNU version is just a little smarter about erroring out properly
on main, but there's nothing stopping anybody from using a function
called f so I'll use your recommended workaround.  Thanks.
___
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: make cleanworld

[Ryan Stone]

On Tue, Nov 8, 2011 at 4:55 PM, Alexander Best arun...@freebsd.org wrote:
 another tought would be to do the following:

 find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} +
 rm/obj/usr/git-freebsd-head/*

As far as I can tell, the expensive part is not chflags, but walking
the entire directory tree.  Running find will still cause us to walk
it twice.
___
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