Re: lang/gcc12 's g++12 gets a failure on aarch64 FreeBSD (main) but not on aarch64 Fedora (36), small test case

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:
> 
> 
>> 
>> 
>> On aarch64 FreeBSD (see the comment for the failure message):
>> 
>> // g++12 -std=c++20 -fmodules-ts -xc++-system-header memory
>> // g++12 -std=c++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 | }
>> // | ^
>> 
>> import <memory>;
>> 
>> 
>> struct data
>> {
>> virtual ~data() = default;
>> };
>> 
>> void test(std::shared_ptr<data> b)
>> 
>> {
>> auto dpc = std::dynamic_pointer_cast<data>(b);
>> 
>> }
>> 
>> 
>> 
>> 
>> Note: On FreeBSD, I do my own poudriere-devel based port builds
>> and install the resulting packages. For reference:
>> 
>> # g++12 -v
>> Using built-in specs.
>> COLLECT_GCC=g++12
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc12/gcc/aarch64-portbld-freebsd14.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=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12 --program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/ --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd --enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/gcc12 --build=aarch64-portbld-freebsd14.0
>> Thread model: posix
>> Supported LTO compression algorithms: zlib
>> gcc version 12.2.0 (FreeBSD Ports Collection)
>> 
>> 
>> 
>> 
>> There was no such failure on fedora 36 via:
>> 
>> # c++ -std=c++20 -fmodules-ts -xc++-system-header memory
>> # c++ -std=c++20 -freport-bug -fmodules-ts -c gpp12_module_dynamic_pointer_cast_failure.cpp
>> #
>> 
>> where:
>> 
>> # c++ -v
>> Using built-in specs.
>> COLLECT_GCC=c++
>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/12/lto-wrapper
>> Target: aarch64-redhat-linux
>> Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --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=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.2.1-20220819/obj-aarch64-redhat-linux/isl-install --enable-gnu-indirect-function --build=aarch64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
>> Thread model: posix
>> Supported LTO compression algorithms: zlib zstd
>> gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC)
> 
> 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.
> 
> 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=106820

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+=--disable-bootstrap
# Just for using a debugger on the compiler itself and such:
MAKE_ARGS+=    "CFLAGS=${CFLAGS} -g -O0" "CXXFLAGS=${CXXFLAGS} -g -O0" "STAGE1_CFLAGS=-g -O0" "STAGE1_CXXFLAGS=-g -O0" "XGCC_FLAGS_FOR_TARGET=-g -O0" STRIP=true
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=bootstrap-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+=          MULTILIB
OPTIONS_DEFAULT_amd64+= MULTILIB
OPTIONS_DEFINE_powerpc64+=      MULTILIB
#OPTIONS_DEFAULT_powerpc64+=    MULTILIB # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
MULTILIB_DESC=          Build support for 32-bit and 64-bit targets
MULTILIB_CONFIGURE_ENABLE=      multilib
.else
CONFIGURE_ARGS+=        --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=106825

(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=103499
(invalid use of non-static member function)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426
(failed to read compiled module cluster ...: Bad file data)


===
Mark Millard
marklmi at yahoo.com