Date: Fri, 2 Sep 2016 04:28:49 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: armv6 specific std::async crash from g++6 built a.out [stable/11 -r304943 context; /usr/ports -r421001 context] Message-ID: <790F9152-F7E0-4D00-9A44-CCEE439DFC5B@dsl-only.net> In-Reply-To: <561577BD-0167-4623-B69D-08923E671D5D@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Sep-1, at 4:35 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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
Beyond amd64 FreeBSD not having the problem that armv6 has. . .
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.)
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).
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.)
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.
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.)
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?790F9152-F7E0-4D00-9A44-CCEE439DFC5B>