Date: Sun, 11 Sep 2022 08:57:09 -0700 From: Mark Millard <marklmi@yahoo.com> To: Lorenzo Salvadore <phascolarctos@protonmail.ch> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: lang/gcc12 's g++12 gets a failure on aarch64 FreeBSD (main) but not on aarch64 Fedora (36), small test case Message-ID: <F9AAC72E-B967-4276-9FB8-214538C68DD6@yahoo.com> In-Reply-To: <5T6hqjycYy4YYKvw5nXon_xY9KeiiyI3SqHjD07MbHj79un1XGi3AvhFF02Do-8fthrShlq8QEdhwh1ZZB0OgGQaF8tqsYTcVycUlbvOY_I=@protonmail.ch> References: <913100F3-F0DC-45F0-BF08-8D4146276636.ref@yahoo.com> <913100F3-F0DC-45F0-BF08-8D4146276636@yahoo.com> <5T6hqjycYy4YYKvw5nXon_xY9KeiiyI3SqHjD07MbHj79un1XGi3AvhFF02Do-8fthrShlq8QEdhwh1ZZB0OgGQaF8tqsYTcVycUlbvOY_I=@protonmail.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Sep-11, at 02:04, Lorenzo Salvadore =
<phascolarctos@protonmail.ch> wrote:
> ------- Original Message -------
> On Saturday, September 3rd, 2022 at 23:24, Mark Millard =
<marklmi@yahoo.com> wrote:
>=20
>=20
>>=20
>>=20
>> On aarch64 FreeBSD (see the comment for the failure message):
>>=20
>> // g++12 -std=3Dc++20 -fmodules-ts -xc++-system-header memory
>> // g++12 -std=3Dc++20 -fmodules-ts -c =
gpp12_module_dynamic_pointer_cast_failure.cpp
>> //
>> // gets:
>> //
>> // during IPA pass: visibility
>> // gpp12_dynamic_pointer_cast_failure.cpp:21:1: internal compiler =
error: in function_and_variable_visibility, at ipa-visibility.cc:716
>> // 21 | }
>> // | ^
>>=20
>> import <memory>;
>>=20
>>=20
>> struct data
>> {
>> virtual ~data() =3D default;
>> };
>>=20
>> void test(std::shared_ptr<data> b)
>>=20
>> {
>> auto dpc =3D std::dynamic_pointer_cast<data>(b);
>>=20
>> }
>>=20
>>=20
>>=20
>>=20
>> Note: On FreeBSD, I do my own poudriere-devel based port builds
>> and install the resulting packages. For reference:
>>=20
>> # g++12 -v
>> Using built-in specs.
>> COLLECT_GCC=3Dg++12
>> =
COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc12/gcc/aarch64-portbld-freebsd=
14.0/12.2.0/lto-wrapper
>> Target: aarch64-portbld-freebsd14.0
>> Configured with: =
/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure =
--disable-multilib --disable-bootstrap --disable-nls =
--enable-gnu-indirect-function --enable-host-shared --enable-plugin =
--libdir=3D/usr/local/lib/gcc12 --libexecdir=3D/usr/local/libexec/gcc12 =
--program-suffix=3D12 --with-as=3D/usr/local/bin/as =
--with-gmp=3D/usr/local =
--with-gxx-include-dir=3D/usr/local/lib/gcc12/include/c++/ =
--with-gxx-libcxx-include-dir=3D/usr/include/c++/v1 =
--with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports =
Collection' --with-system-zlib --without-zstd =
--enable-languages=3Dc,c++,objc,fortran,jit --prefix=3D/usr/local =
--localstatedir=3D/var --mandir=3D/usr/local/man =
--infodir=3D/usr/local/share/info/gcc12 =
--build=3Daarch64-portbld-freebsd14.0
>> Thread model: posix
>> Supported LTO compression algorithms: zlib
>> gcc version 12.2.0 (FreeBSD Ports Collection)
>>=20
>>=20
>>=20
>>=20
>> There was no such failure on fedora 36 via:
>>=20
>> # c++ -std=3Dc++20 -fmodules-ts -xc++-system-header memory
>> # c++ -std=3Dc++20 -freport-bug -fmodules-ts -c =
gpp12_module_dynamic_pointer_cast_failure.cpp
>> #
>>=20
>> where:
>>=20
>> # c++ -v
>> Using built-in specs.
>> COLLECT_GCC=3Dc++
>> =
COLLECT_LTO_WRAPPER=3D/usr/libexec/gcc/aarch64-redhat-linux/12/lto-wrapper=
>> Target: aarch64-redhat-linux
>> Configured with: ../configure --enable-bootstrap =
--enable-languages=3Dc,c++,fortran,objc,obj-c++,ada,go,lto --prefix=3D/usr=
--mandir=3D/usr/share/man --infodir=3D/usr/share/info =
--with-bugurl=3Dhttp://bugzilla.redhat.com/bugzilla --enable-shared =
--enable-threads=3Dposix --enable-checking=3Drelease --enable-multilib =
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions =
--enable-gnu-unique-object --enable-linker-build-id =
--with-gcc-major-version-only --enable-libstdcxx-backtrace =
--with-linker-hash-style=3Dgnu --enable-plugin --enable-initfini-array =
--with-isl=3D/builddir/build/BUILD/gcc-12.2.1-20220819/obj-aarch64-redhat-=
linux/isl-install --enable-gnu-indirect-function =
--build=3Daarch64-redhat-linux --with-build-config=3Dbootstrap-lto =
--enable-link-serialization=3D1
>> Thread model: posix
>> Supported LTO compression algorithms: zlib zstd
>> gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC)
>=20
> As the maintainer of the gcc12 port, I should probably be the one who =
has
> the answer for you. Unfortunately, as you know, I have taken =
maintainership
> only recently and I do not know gcc well enough to solve this issue =
yet.
>=20
> I suggest you to open an official bug report on
> https://bugs.freebsd.org/bugzilla/ to keep track of this issue.
I continued to work on it. See the upstream bugzilla
submittal that has my gradual evidence gathering:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106820
std::dynamic_pointer_cast is not where the problem is but
uses something gets the problem: std::shared_ptr<data>{b,??}
That in turn ties back to usage that involves:
https://github.com/gcc-mirror/gcc/blob/master/libgcc/gthr-posix.h
and its use of:
# define __gthrw2(name,name2,type) \
static __typeof(type) name \
__attribute__ ((__weakref__(#name2), __copy__ (type))); \
__gthrw_pragma(weak type)
. . .
/* Typically, __gthrw_foo is a weak reference to symbol foo. */
#define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
. . .
__gthrw(pthread_mutex_unlock)
which g++ is not handling well when the <memory> header
unit is involved.
This was found via managing to build the port with
"-g -O0" in use and then using lldb, setting a
breakpoint on fancy_abort and the looking around.
To get the debug build I used a temporarily modified
lang/gcc12/Makefile:
QUOTE
.if empty(PORT_OPTIONS:M*BOOTSTRAP)
CONFIGURE_ARGS+=3D--disable-bootstrap
# Just for using a debugger on the compiler itself and such:
MAKE_ARGS+=3D "CFLAGS=3D${CFLAGS} -g -O0" "CXXFLAGS=3D${CXXFLAGS} -g =
-O0" "STAGE1_CFLAGS=3D-g -O0" "STAGE1_CXXFLAGS=3D-g -O0" =
"XGCC_FLAGS_FOR_TARGET=3D-g -O0" STRIP=3Dtrue
END QUOTE
That proved sufficient --but I may have involved more
MAKE_ARGS content than necessary.
> Then I would
> encourage you to configure the two gcc versions (the one on FreeBSD =
and the
> one on Fedora) as similarly as possible (for example, you have =
--disable-multilib
> and --disable-bootstrap on FreeBSD, but --enable-multilib and
> --with-build-config=3Dbootstrap-lto on Fedora),
I had tested the port's STANDARD_BOOTSTRAP as well. My
time preferences generally lead to avoiding LTO_BOOTSTRAP
without solid evidence of the need.
The ports logic for multilib is:
QUOTE
.if exists(/usr/lib32/libc.so)
OPTIONS_DEFINE_amd64+=3D MULTILIB
OPTIONS_DEFAULT_amd64+=3D MULTILIB
OPTIONS_DEFINE_powerpc64+=3D MULTILIB
#OPTIONS_DEFAULT_powerpc64+=3D MULTILIB # =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105010
MULTILIB_DESC=3D Build support for 32-bit and 64-bit targets
MULTILIB_CONFIGURE_ENABLE=3D multilib
.else
CONFIGURE_ARGS+=3D --disable-multilib
.endif
END QUOTE
aarch64 does not have a /usr/lib32/ for FreeBSD to
produce support for. Only amd64 and powerpc64
MACHINE_ARCH's have such (or have had such for a long
time). I'm not sure what enabling multilib would do
for FreeBSD's port on aarch64.
However, given the __weakref__ binding to posix being
involved but not handled, this route seems unlikely
to make any difference.
> then test again.
> If the FreeBSD version has the same configuation of the Fedora version =
but still
> fails, then the problem might be upstream and a bug report upstream =
should be
> opened; otherwise, it is possible that something is wrong with our =
port and we
> should fix it.
So far as I can tell the problem is upstream. My classification
as "Blocks: 99227 c++-modules" was accepted despite the FreeBSD
context for the failure vs. Fedora not failing.
I also submitted:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106825
(that does happen on Fedora). It as also accepted for
"Blocks: 99227 c++-modules". It is another <memory>
header unit issue shown via another std::shared_ptr usage
example, an undefined reference being the type of failure
that results.
There are a couple of pre-existing bugzilla's that I submitted
confirming information to that I indicated the problems as
still existing in gcc 12.2.1 (on Fedora 36). libstdc++ header
units usage attempts seem to lead to hitting a number of
problems in g++ support for such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103499
(invalid use of non-static member function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99426
(failed to read compiled module cluster ...: Bad file data)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9AAC72E-B967-4276-9FB8-214538C68DD6>