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

------- 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. 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), 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.

Thanks,

Lorenzo Salvadore