From nobody Sun Sep 11 15:57:09 2022 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQZ9l6dsPz4c6mX for ; Sun, 11 Sep 2022 15:57:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQZ9k583Zz43Ty for ; Sun, 11 Sep 2022 15:57:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1662911832; bh=sjnp0JTTvaS05SRAcNevwo9LTlRwjhyW5G2zhoQep8o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=O+WKya8TjzW3kqd+Uz7Zbc3NMlqA/OqRF+/l4IXCtKu8JyX8UABEA8HGoxb8SkZLBL0qJpOjdIjNiMcIzJNcPiEWEcWGfO7lPg8PdpSpI78a9OrshxS+Nw1AYV6/EPGKv824sMIrMAs9bRk9MPgcybwr1F6+41ECWBCD38gq6YnGR1vhXxPtE3GdwMEfW0n3waBK/R9S047VhcKFtifHFL/z+Tnc+gWu6ZU5rS96VdNbQZpk5TAJIsQDkKZvJgacpz1GLec+T3599fXnuWHW6LGJwCH56Grw3NCDPm0UcgdEQVV5fgQTignvPabhdLAcs6wx3SAIKc4ygiKngXbj7Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1662911832; bh=n2jt5lP2uPM1oTiwMqH2/q6vPAANWfMviDRSdJkIeC6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l/Qiu0tBpG+tlaZQGu3bYj8oSmcMQs5MxlR8BGBHbS/rYBAluqi5n4/uPdzEocwaOE4MQULJ1vtg1QgoE6pnZbeb5DJHngZy1/DD+s0ZSKgzzyN52LYAlxaMX8dUqw4cMGD3arFlcAUGNSQV4FZXtYrkeLndQJVMm2A9QgD77BvNckCWk23mX9T327/tLcBX4bZyvwFmveR1QgeznGcVyx5ken8BsTAwcQM7BvTo35yd4Z7AfeiNgZFnnrKnaMBINqE9xvNduK03HVgMUsEKVqCH8SJyWH+ms2G/ufRaDEEG8mBJsThrhYMtUvv+F3Cfdme5AubbVRbh/0pUTCs2uA== X-YMail-OSG: ErHIGQUVM1l4jJjnXK6AUgKS4VGBPGXreCJO3eQ7w_k9dSnA6rGaa1eQRltyuXb w5AtfNdAmJ7arwHnwkOJTaU3d2K3t.6chuch0aLUSoHr3j0OJQbsXmEWOUsn1kQbMyB8_UA9s_g9 UclX59A_ue1R5gwOg2k_Inm20L5UbjjioDNJB.syxhQWsHHkH7wyeXwnH8YsLVJgUh9IW5t9pJnH WGWPR1C58685OdFsZi2LY8RQSk5fau7uBpNmJnNBGliNAMMsFKibZVhaiIlrYoOW0oh3_Lde0O5X vVBfL5QQIUOMw96BNdEVhCZX.DtEuHkjAg8dCJqo2nbUz7kdV_6.5eHMwK1zQ5K1r3PQz6UfueDD 5hyQe9fGm69FDMbDeuB6oPmx19IhOD_hKEd2BN9ZbAZPLudd5x.N_VTfRia1NpPOOOneqlOr9tcA t9H1ppULw9GR3pcUrJ3TF70Z9p0hssgdV4lSb0QPFfaeFWFKfdgU3nZG13ttu2obsOQ5M9T2CCJJ Hfb_jCA4tlhqnWiEvZo0KmW8Sni3ua8Q34oj9rrfk4LZEhOdcpTDlBM8ADCavFhSv.nZMgAndFQm ubpUK1mdR1w6EBn_9FQkJaL_C9zIyGoLL_fHM_NzVZD0lENBg2hFhuG885o1c4Fk78Eji9zV_3n5 rfB9jCrjz1GKEmXDOluh5aM4Ojh7Lcv1SvRiAQ3_piwhlkbIGTKgqrippo6SHO5hPgdvzpYu0guO S5t.KOqCyaJ8CUuEBHAGpQGMjqbBya6vI3CBtTzO7_p8n2iKVRi9gfElHKfcaOI85ylQ34OYgGTE vn9vpGJJWdJnTkrSZjlc1Hxal8syZDguGMXRBL5_ldGMTXqleTFw7yhnEsa_LKvGBJknd34AQ9JJ ZqSj1iWmG5ufa8rX9.EQPyO9j6UUtccr4yRiC4P5pu6Pn9ICO9dyYoIPV.MpEjL6AZNhL1BaC_Nz BiibMpY3Xal9EEMx3Od2WLAV5CiFOaanBVnaRJAsH5y4sNPA1XWlWQh0b7NCoxKo9dvgpjWlREqR k1kfaTtikq0q4YvFEkf7hbLzKZ7PSsaSbjn8NJaekk3_i7ehkWCj9J.AR5hY35azr6IRQRglMNen VCeHHhP4cQOW4Jt6zwB7iQbVK.wJcqaEopfL0iTLVGwWSsW68H.XzYf8hD6UucCZrwsLxaUEpnFv Af_T1l3L_dIU5rICe.1zyhz.txV5PKSm3dxxqpiPWhgeMg3Idpie69h5JToYgikGL13IVnCgYea0 bHP4GYWwCwq3xYfITj3Pi4BvqOYizzwq1eLi6Nmz17Y3sIpmLK6RVUS6LYTxcMC1TkegO42xFQqy lN20ySNbQUhtCSqDE0quuj03HCsNrzpmBH19QY4S1gcZrxQfYTfYienD3ZEE5W6BOE__qf3yMhzJ mcNAa41EoePSTsIZh9rVCKg.zqIdxBcJwMnOVzmI1Nb3CY1am6ckW9.7hZweq5J.TIGJyacdts7P u2dwfjgbLr77kSL_Tnw.It996PRQhh1lb_c7LLwqefxpWfzKSH7HKt__fqPsiTnlghm4UNJEp9F6 LUCPz9_b8Qoi874a__xPIem3aIqkQDK5gYxAT5uypflcMEB0.Qa6xtkpZwRgwMjl5.j23068dGH2 zKtFDHEeYuH3MLbeKd8iVo6q.VcN_H1zjNRQ0h8UKgT3CIMvYXz3473ZvC9hBDuHH9PzJblLyGT7 EEOt6Ripwg_cNZYX1ulxYfpJ07d.WCtbR5VS4KeGf88skJ4jieLBTzVssX59d_UGMS3EGoGo6sLn wVOXFYnLt4jeddadgQABwgGZI5OdhClMLXP.ksUXfbNcJf9M2PGKzMQSPT0V96bZ_eKvwInAiQCI MwzxZwqYlQs8DV890jirB51FwvcWvPl63gx4vDmzCFZmYa8HUz3f9xFgfkmfiaNacuWxaJvcRp6N BQvkqYd4TlfU_mD1eoRYcmy4XTLPt4XVyukNFxK44YBGwgPp8mmDMm214eKrqCuHSULRkmu.aMGX IIe6SpUEzxt5mqERIcvAXSAHCQsnyLSQ55RveQ7NO4hh0YncwnNm1wykTiD.RkgXG79_Vh66cV7U 4hYEQVXvLmdc7ztVeFfGHcLS38dc5In00s53ro78fQdu0.8fc5L1GxdJg7uVrwtJVNQrezbBW0OM lx2CRCahjkMuAYP.OrTHJD3mUwcvjCCOzNvo_XpgMVOf14tbkNz4xL.o3.r0r2vaZjrYYTWLlq_l BBRjNsYbGBHMhJcMINZaQOK5302Dq8telJbV7OJNO8Hnf9plBVpdzisg8ia6A1clkVF3qRPwW6Lp HIasFO12oz6h6lv7dFq0MTMDCtNvFrWbF_aqx48szHpLA810- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 11 Sep 2022 15:57:12 +0000 Received: by hermes--production-gq1-5499fdd576-g4rmd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e7304d26df7dd367ec68db379f500cd5; Sun, 11 Sep 2022 15:57:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: lang/gcc12 's g++12 gets a failure on aarch64 FreeBSD (main) but not on aarch64 Fedora (36), small test case From: Mark Millard In-Reply-To: <5T6hqjycYy4YYKvw5nXon_xY9KeiiyI3SqHjD07MbHj79un1XGi3AvhFF02Do-8fthrShlq8QEdhwh1ZZB0OgGQaF8tqsYTcVycUlbvOY_I=@protonmail.ch> Date: Sun, 11 Sep 2022 08:57:09 -0700 Cc: FreeBSD Toolchain , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <913100F3-F0DC-45F0-BF08-8D4146276636.ref@yahoo.com> <913100F3-F0DC-45F0-BF08-8D4146276636@yahoo.com> <5T6hqjycYy4YYKvw5nXon_xY9KeiiyI3SqHjD07MbHj79un1XGi3AvhFF02Do-8fthrShlq8QEdhwh1ZZB0OgGQaF8tqsYTcVycUlbvOY_I=@protonmail.ch> To: Lorenzo Salvadore X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4MQZ9k583Zz43Ty X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=O+WKya8T; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Sep-11, at 02:04, Lorenzo Salvadore = wrote: > ------- Original Message ------- > On Saturday, September 3rd, 2022 at 23:24, Mark Millard = 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 ; >>=20 >>=20 >> struct data >> { >> virtual ~data() =3D default; >> }; >>=20 >> void test(std::shared_ptr b) >>=20 >> { >> auto dpc =3D std::dynamic_pointer_cast(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{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 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 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