FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180)

I built a powerpc64 head -r339076 via devel/powerpc64-gcc
and the like that built clang as cc as well (and
WITHOUT_LIB32). This included use of base/binutils to
the the powerpc64 set up. The system and kernel are
non-debug builds (but with symbols). [system-clang is not
used for buildworld buildkernel because of known
issues (last I tried).]

booting, buildworld, buildkernel, poudriere building
what totaled to be somewhat under 400 ports all seem
to work. But . . .

It been a long time since I've done something analogous
and a significant item in the result is different than in
the past once I started testing the throwing of C++
exceptions in code produced by system-clang or by
devel/powerpc64-gcc :

Such code ends up stuck using around 100% of a CPU.
An example is the program:

# more exception_test.cpp
#include <exception>

int main(void)
{
    try { throw std::exception(); }
    catch (std::exception& e) {}
    return 0;
}

For system-clang it ended up with:

# ldd a.out
a.out:
	libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
	libm.so.5 => /lib/libm.so.5 (0x8101ab000)
	libc.so.7 => /lib/libc.so.7 (0x8101eb000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810554000)

That program goes into an possibly unbounded execution.
(Historically when this program had problems it would
stop and produce a core file.)

When compiled by devel/powerpc64-gcc the a.out that results
does the same thing. ( /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ 
as the compiler path ) So this is not really clang specific
in any way. This ended up with:

# ldd a.out
a.out:
	libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
	libm.so.5 => /lib/libm.so.5 (0x8101ab000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8101eb000)
	libc.so.7 => /lib/libc.so.7 (0x810211000)

(That should not have involved clang or llvm at all.)

But compiled by lang/gcc8's g++8 the a.out that results works
fine. This ends up with:

# ldd a.out
a.out:
	libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81006e000)
	libm.so.5 => /lib/libm.so.5 (0x8102c7000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810307000)
	libc.so.7 => /lib/libc.so.7 (0x81032d000)

It is not clear if using base/gcc as system cc
would do any better than using system-clang does
or than devel/powerpc64-gcc does: it is sort of
a variant of devel/powerpc64-gcc .

It will probably be some time before I figure out
much about what is going on.

Two things common to the problem cases are:

libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)

lang/gcc8 avoids those being involved.


Notes:

Some time ago I'd used system-clang to build such
programs in an environment built via devel/powerpc64-gcc
and devel/powerpc64-binutils and the programs worked.
The same for devel/powerpc64-gcc use: the code it
produced for the programs also worked. At this point
I've no clue what changed or when.

WITHOUT_LIB32= is because, for every post-gcc 4.2.1
that I've tried, the lib32 produced misuses R30 in
crtbeginS code (vs. the ABI for FreeBSD) and 32-bit
code just produces core files from the bad so-called
address dereference that results.

I'd rather have throwing C++ exceptions working and
lack of lib32 than have lib32 but not have throwing
C++ exceptions working. But at the moment how to have
such is not obvious when fairly modern compilers
and toolchains are involved. 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)