Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Sep 2016 14:51:45 -0700
From:      Mark Millard <markmi@dsl-only.net>
To:        freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org>
Cc:        FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: armv6 specific std::async crash from g++6 built a.out [g++5  too; unsure for aarch64/powerpc/powerpc64: help?]
Message-ID:  <389C3223-AE3B-4D4A-8ABC-57A71D8705E9@dsl-only.net>
In-Reply-To: <790F9152-F7E0-4D00-9A44-CCEE439DFC5B@dsl-only.net>
References:  <25A60F75-B228-4C95-A890-8D6A8DA3F2CE@dsl-only.net> <2514E6E1-B405-4C3F-B283-754B948851EF@dsl-only.net> <00C57E2B-47EB-4579-9130-8116C9F934A0@dsl-only.net> <561577BD-0167-4623-B69D-08923E671D5D@dsl-only.net> <790F9152-F7E0-4D00-9A44-CCEE439DFC5B@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
[Quick top post reporting that using gcc5 5.4.0 has the same problem for =
armv6 FreeBSD. I've got a stable/11 context, currently -r304943.]

FreeBSD bugzilla Bug 212330 is for this.

For:

> #include <future>       // future, async, launch::async
>=20
> static void f() {}
>=20
> int main(int, const char* [])
> {
>   auto a0{ std::async( std::launch::async, f ) };
>   a0.get();
>   return 0;
> }

I've now also tried "pkg install gcc5" on the rpi2 and then used it to =
produce the a.out file. ./a.out still gets SIGSEGV for the ~10 line =
program (and the original program the crash was discovered with).

g++6 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread =
-Wl,-rpath=3D/usr/local/lib/gcc6
or
g++5 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread =
-Wl,-rpath=3D/usr/local/lib/gcc5

Omitting the -Wl,-rpath=3D/usr/local/lib/gcc<?> also produces an a.out =
for the ~10 line program that gets the SIGSEGV. (I tried the g++6 case =
anyway.)

Comparison to other rpi2 contexts:

g++-5 on Ubuntu Mate 16.04 on the same rpi2 does not have this problem.
g++-6 on Ubuntu Mate 16.04 on the same rpi2 does not have this problem.



The other contexts that I've tried do not have the problem: so far only =
armv6 FreeBSD:

clang based builds do not have the problem any place that I've tried. =
Other than the toolchain in use these are the same contexts as for the =
g++ tests.

Ubuntu Mate with g++-5 and g++-6 on an ODRIOD-C2 (aarch64) works. [I've =
no FreeBSD aarch64 context.]

amd64 FreeBSD stable/11 with g++6 works. [I've not tried g++5.]



If anyone has aarch64, powerpc64, or powerpc (or other) FreeBSD contexts =
and g++5 and/or g++6 and want to try compiling and running the program:

#include <future>       // future, async, launch::async

static void f() {}

int main(int, const char* [])
{
  auto a0{ std::async( std::launch::async, f ) };
  a0.get();
  return 0;
}

based on

g++6 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread =
-Wl,-rpath=3D/usr/local/lib/gcc6
and/or
g++6 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread
and/or
g++5 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread =
-Wl,-rpath=3D/usr/local/lib/gcc5
and/or
g++5 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread

and report on the result in =
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212330 that might =
help.

My testing has been limited to stable/11 as well.



Untested (that I will eventually have a context for again): powerpc64 =
and powerpc.

[I'm still a few weeks away from getting access to the powerpc64 and =
powerpc contexts again so I've not tried those. Plus I tend to use =
devel/powerpc64-xtoolchain-gcc FreeBSD builds for powerpc64 and an odd =
context for a clang-based buildworld for powerpc (with a gcc 4.2.1 based =
kernel with signal delivery changes to deal with clang producing =
stack-handling ABI violations). clang++ 3.8.0 for powerpc64 and powerpc =
has other problems, including exception handling being messed up in the =
programs it produces.]

=3D=3D=3D
Mark Millard
markmi at dsl-only.net

On 2016-Sep-2, at 4:28 AM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2016-Sep-1, at 4:35 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>> Another top post because I should have kept going with the =
reductions: the following ~10 line program also shows the SIGSEGV =
behavior on armv6 (an rpi2) for running ./a.out after compiling via =
g++6.
>>=20
>>> # more g++6_build_crashes.cpp                                        =
                                                                         =
                                                          #include =
<future>       // future, async, launch::async
>>>=20
>>> static void f() {}
>>>=20
>>> int main(int, const char* [])
>>> {
>>>   auto a0{ std::async( std::launch::async, f ) };
>>>   a0.get();
>>>   return 0;
>>> }
>>=20
>> It only takes one std::async use to have the problem. So far the =
above (and the earlier variants) always crash with SIGSEGV on the rpi2 =
when the g++6 compiler is used.
>>=20
>> As for the compile commands used:
>>=20
>>> g++6 -g -v -std=3Dc++14 -Wpedantic -Wall -O2 -pthread =
-Wl,-rpath=3D/usr/local/lib/gcc6 -mcpu=3Dcortex-a7 =
g++6_build_crashes.cpp
>>=20
>>=20
>> Omitting the -mcpu=3Dcortex-a7 still get the problem.
>>=20
>> Using -O0 instead of -O2 still gets the problem.
>>=20
>> But I'll note that my stable/11 -r304943 build and my ports builds =
(usr/ports -r421001 vintage) were/are based on using -mcpu=3Dcortex-a7 . =
Also the system clang 3.8.0 was used to build g++6:
>>=20
>>> GNU C++14 (FreeBSD Ports Collection) version 6.2.0 =
(armv6-portbld-freebsd11.0)
>>>       compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 =
(tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version =
3.1.4-p1, MPC version 1.0.3, isl version none
>>=20
>>> # more /etc/make.conf=20
>>> DEFAULT_VERSIONS+=3Dperl5=3D5.22
>>> WRKDIRPREFIX=3D/usr/obj/portswork
>>> WITH_DEBUG=3D
>>> WITH_DEBUG_FILES=3D
>>> MALLOC_PRODUCTION=3D
>>> #
>>> #system clang 3.8 (gcc6 rejects -march=3Darmv7a):
>>> #CFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7
>>> #CXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7
>>> #CPPFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7
>>> #
>>> #lang/gcc6's xgcc stage considers the above conflicting so use just:
>>> CFLAGS+=3D -mcpu=3Dcortex-a7
>>> CXXFLAGS+=3D -mcpu=3Dcortex-a7
>>> CPPFLAGS+=3D -mcpu=3Dcortex-a7
>>=20
>>=20
>> =3D=3D=3D
>> Mark Millard
>> markmi at dsl-only.net
>=20
> Beyond amd64 FreeBSD not having the problem that armv6 has. . .
>=20
> I have since booted Ubuntu Mate 16.04 on the rpi2 (armv6 / cortex-a7) =
and installed g++-6, g++-6 (Ubuntu 6.1.1-2ubuntu12~16.04) 6.1.1 20160510 =
since it was available. (So not 6.2: not a full vintage match to my =
FreeBSD g++6 contexts, unfortunately.)
>=20
> The original program that failed on FreeBSD when compiled with g++6 =
(v6.2) on the same rpi2 executes just fine after being compiled on the =
Ubuntu Mate rpi2 configuration with g++-6 (v6.1).
>=20
> So the armv6 SIGSEGV looks to not not be a generic g++6/libstdc++ =
problem for std::async use: it seems to be armv6 FreeBSD specific. =
(Unfortunately I've not been able to form fully matching versions for =
this comparison.)
>=20
> I've also installed g++-6 on a ODROID-C2 (aarch64) Linux (Ubuntu =
16.04.1) and built the original program that I discovered the problem =
with. g++-6 (Ubuntu 6.1.1-2ubuntu12~16.04) 6.1.1 20160510 was the =
compiler.
>=20
> It executes just fine on the ODROID-C2 under Ubuntu Mate. (So far as I =
know FreeBSD does not support this type of context (yet) but it is the =
only aarch64 context I currently have access to.)
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
>=20
>=20



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?389C3223-AE3B-4D4A-8ABC-57A71D8705E9>