From owner-freebsd-toolchain@freebsd.org Sun Mar 10 19:17:53 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20A2D153E33C for ; Sun, 10 Mar 2019 19:17:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC528A32A for ; Sun, 10 Mar 2019 19:17:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Bp4VcKsVM1m.NfTJqgPVtBoQs01Dpq1R0Ck8ChXSZjrqn0H0oWbxjYPkcvhxLRz kqhe2Hmr5TbD64egqw0S0KAddWfAWl5Q4DzfnlVuurRaZYVvxuT8_CzUS9E85v0LXLuTaPT7k7zP ePRtXfKF4T_2dsPZLvqZK0IiDYzHv8NpDrKY5LkhDxeEvAsJ0uYm9NoVh1e8NuYC5DRfYJ7j7Iz0 H37HoXxVpay0YqhKM6RkjxolV5h2PJmawPMmu5mz1sQqMiGJu8je_AI1kpvw1MkardKkm0aaaLWP 4oDEGS1dUNKUU6UNrH_Jlx0qNTYknN3XJD9ekDRnvbI5K.8yHRe0wON6lqW6kt0.a7h0TH12Xnv0 dhaQeXF_ZpiQuGyv20hKLVlVV1ERGLRUF5YaEyelAM6I6eMfqe13eB.lsj2n_JCVAqBhVLK03YSm VJyv3JcSIW1tSt.fp4hjIfZStd2Vxl.2BBXCCFARKzLVypPzDQ8B2kRF_MMeqXX1y4Kk5CztBjK5 xLb12j.qulVjdrOEqoFOCVsqk5Na1Hag4F13i9.SoZ1eX6TpNhHfQ1WTmFeAM_fAuah5OCfl3QL3 fVQYtpZ.RzQLkKXPojIgMN.TARm38fKK_pqagVZrDCC2SHxoooTx0hHEG5aY5exIlLNQ8DpLpxYu .Y3wh11.xNuv1_V54KDbuuoimlatVGHKTsgo3DWGvS9X.r0S5qAYnoUEjrZyTwmhABif0Xlk8BT. Pb3qpCWEBC_jnVHpVMHhRurZ5mUfd9TZ8N2s9LSejfWT21CZOEMlm.hjlejMHMWtfGI4XzooYtkw .nkn1qcouPN2ZxY6LVbKr6Gx7o8YlTy76xHJshR2QMnH3sevQI7HNzSF6adTY6WdY9DYecfWbgit OFMFB1wU6SVEHEMd0JZmSQv3h6FAe7fUtGFm_8pdb.IXJOUCeAKVDsqHb6hNZYIHDJ.VS4Uq0ihA mzwQx3wPOyZY5sWLe.a72bMRWGIaNl8w3wm9whyMjL5ozQrHC2JI2HbJ8D5ad.5edy2gKjWGp5Sd XHdQ7bJE1XeHJ9hjYcYkxaO8rf_Iro4zKmNbeLHaP4w1yg6PwxlZ4EYS0sF3LMi8bNJqMYPfSVA- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sun, 10 Mar 2019 19:17:49 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp422.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f687c20ca46223b1ea7a09a69a7dc82f; Sun, 10 Mar 2019 19:07:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: 32-bit powerpc: gcc8 unable to build devel/llvm80, for example: crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 against symbol `__cxa_finalize@@FBSD_1.0' Message-Id: <1470043E-62EE-4F8C-A04F-4AFC003EC8CF@yahoo.com> Date: Sun, 10 Mar 2019 12:07:39 -0700 Cc: FreeBSD Toolchain To: ports-list freebsd , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 9DC528A32A X-Spamd-Bar: + X-Spamd-Result: default: False [1.28 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.86)[0.855,0]; NEURAL_HAM_LONG(-0.31)[-0.305,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.98)[ip: (2.72), ipnet: 66.163.184.0/21(1.24), asn: 36646(0.99), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.26)[0.264,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[147.184.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 19:17:53 -0000 My ports-mgmt/pouriere-devel based build attempt for building = devel/llvm80 failed with: [00:01:11] [01] [00:00:00] Building devel/llvm80 | llvm80-8.0.0.r3 [04:30:47] [01] [04:29:36] Saved devel/llvm80 | llvm80-8.0.0.r3 wrkdir = to: = /usr/local/poudriere/data/wrkdirs/FBSDpowerpc-default/default/llvm80-8.0.0= .r3.tbz [04:30:47] [01] [04:29:36] Finished devel/llvm80 | llvm80-8.0.0.r3: = Failed: build [04:31:10] [01] [04:29:59] Skipping devel/xtoolchain-llvm80 | = xtoolchain-llvm80-0.1: Dependent port devel/llvm80 | llvm80-8.0.0.r3 = failed [04:31:11] Stopping 2 builders The log shows: /usr/local/lib/gcc8/gcc/powerpc-portbld-freebsd13.0/8.3.0/crtbeginS.o: = in function `__do_global_dtors_aux': crtstuff.c:(.text+0x13c): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `__cxa_finalize@@FBSD_1.0' defined in .text section in = /lib/libc.so.7 tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `llvm::object_deleter<(anonymous = namespace)::RegisterFatalErrorHandler>::call(void*)': = CIndex.cpp:(.text._ZN4llvm14object_deleterIN12_GLOBAL__N_125RegisterFatalE= rrorHandlerEE4callEPv+0x0): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `operator delete(void*)@@GLIBCXX_3.4' defined in .text = section in /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `llvm::CrashRecoveryContextDeleteCleanup > >::recoverResources()': = CIndex.cpp:(.text._ZN4llvm33CrashRecoveryContextDeleteCleanupISt6vectorIPK= cSaIS3_EEE16recoverResourcesEv[_ZN4llvm33CrashRecoveryContextDeleteCleanup= ISt6vectorIPKcSaIS3_EEE16recoverResourcesEv]+0x28): relocation truncated = to fit: R_PPC_PLTREL24 against symbol `operator = delete(void*)@@GLIBCXX_3.4' defined in .text section in = /usr/local/lib/gcc8/libstdc++.so = CIndex.cpp:(.text._ZN4llvm33CrashRecoveryContextDeleteCleanupISt6vectorIPK= cSaIS3_EEE16recoverResourcesEv[_ZN4llvm33CrashRecoveryContextDeleteCleanup= ISt6vectorIPKcSaIS3_EEE16recoverResourcesEv]+0x40): relocation truncated = to fit: R_PPC_PLTREL24 against symbol `operator = delete(void*)@@GLIBCXX_3.4' defined in .text section in = /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `std::_Sp_counted_ptr_inplace, = (__gnu_cxx::_Lock_policy)2>::~_Sp_counted_ptr_inplace()': = CIndex.cpp:(.text._ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOper= ationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2EED0Ev[_ZNSt23_Sp_counted_ptr_in= placeIN5clang22PCHContainerOperationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2E= ED5Ev]+0x0): relocation truncated to fit: R_PPC_PLTREL24 against symbol = `operator delete(void*)@@GLIBCXX_3.4' defined in .text section in = /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `std::_Sp_counted_ptr_inplace, = (__gnu_cxx::_Lock_policy)2>::_M_destroy()': = CIndex.cpp:(.text._ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOper= ationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv[_ZNSt23_Sp_coun= ted_ptr_inplaceIN5clang22PCHContainerOperationsESaIS1_ELN9__gnu_cxx12_Lock= _policyE2EE10_M_destroyEv]+0x0): relocation truncated to fit: = R_PPC_PLTREL24 against symbol `operator delete(void*)@@GLIBCXX_3.4' = defined in .text section in /usr/local/lib/gcc8/libstdc++.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `llvm::object_creator<(anonymous = namespace)::RegisterFatalErrorHandler>::call()': = CIndex.cpp:(.text._ZN4llvm14object_creatorIN12_GLOBAL__N_125RegisterFatalE= rrorHandlerEE4callEv+0x2c): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `operator new(unsigned int)@@GLIBCXX_3.4' defined in = .text section in /usr/local/lib/gcc8/libstdc++.so = CIndex.cpp:(.text._ZN4llvm14object_creatorIN12_GLOBAL__N_125RegisterFatalE= rrorHandlerEE4callEv+0x3c): relocation truncated to fit: R_PPC_PLTREL24 = against symbol `llvm::install_fatal_error_handler(void (*)(void*, = std::__cxx11::basic_string, = std::allocator > const&, bool), void*)@@LLVM_8' defined in .text = section in lib/libLLVM-8.so tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `fatal_error_handler(void*, std::__cxx11::basic_string, std::allocator > const&, bool)': = CIndex.cpp:(.text._ZL19fatal_error_handlerPvRKNSt7__cxx1112basic_stringIcS= t11char_traitsIcESaIcEEEb+0x38): relocation truncated to fit: = R_PPC_PLTREL24 against symbol `fprintf@@FBSD_1.0' defined in .text = section in /lib/libc.so.7 = CIndex.cpp:(.text._ZL19fatal_error_handlerPvRKNSt7__cxx1112basic_stringIcS= t11char_traitsIcESaIcEEEb+0x3c): relocation truncated to fit: = R_PPC_PLTREL24 against symbol `abort@@FBSD_1.0' defined in .text section = in /lib/libc.so.7 tools/clang/tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o: in = function `std::_Sp_counted_ptr_inplace, = (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)': = CIndex.cpp:(.text._ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOper= ationsESaIS1_ELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_inf= o[_ZNSt23_Sp_counted_ptr_inplaceIN5clang22PCHContainerOperationsESaIS1_ELN= 9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info]+0x5c): = additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/devel/llvm80 =3D>> Cleaning up wrkdir Context: # uname -apKU FreeBSD FBSDG4S 13.0-CURRENT FreeBSD 13.0-CURRENT #14 r344955M: Fri Mar = 8 22:39:44 PST 2019 = markmi@FBSDFSSD:/usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/= powerpc.powerpc/sys/GENERICvtsc-NODBG powerpc powerpc 1300014 1300014 (The 32-bit powerpc is running a gcc 4.2.1 based system. amd64 = system-clang built the bootstrap gcc 4.2.1 toolchain, which in turn built the system. The = 32-bit FreeBSD was running on a PowerMac G5 [2-sockets, 2 cores each].) # svnlite info /usr/ports/ | grep 'Re[plv]' Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 495006 Last Changed Rev: 495006 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Mon Mar 11 00:10:42 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84ECE1523A0D for ; Mon, 11 Mar 2019 00:10:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBE9A6E3E1 for ; Mon, 11 Mar 2019 00:10:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: KDNOktcVM1lqUJXzV4tIoPy.JpwdndXT1RnccL6V4HXU9e_wiWGMM74A0q0kM7d tZaFsDCXOWaW5P9TQ5aU_KWy3MM7CazC_aWUbNH7xb5k23hLQl_r485ctoe6xOKL8GztGic_Ia1d jgOXK4nIrFItX5zrGwYeQ66w134Qni8FxDDnrXVrlWycN2XJ5MKFJd0uzmBifxaS1H5jv5VhUcYC v3cFbK3ZnVxxTyEKUKvnlBhG.J5iiCk1OBlIiqHrx.aBi3BfaiOh.ns.mjpd96M9Z6gLpz5jBlSn SpzD8ELi2jFau0tHNLhNaIVsZbrYA94zQJGI0Qria2pV6San_4Ds44.L0Tndz3L2V9sLUdrYx70Y zwCpWT18oSmkOqXdRsRNfGe_e6jYj6rrnR5ON8NCDLrl11CnArNh1Tf47hhmp6sxLRNxB1hh41le jJeom.2jFZTV8EH4sOG1OZv3cqY57Rg8ZYdOG0xtXx.ttjQGhrUcrgM7yDOLEZQVj_l5e3NWBXJt HMNduajfqx3u.vAD.qb5MtOs9joKh7rwV9NPHqRHvqPBmTH9Hj9heEvcccR1.y_9BrlbF7.yhGHk qK.T2qn3jSy0nM01CzS5SIe73lHorLBfuM11drKAKzpuV0x9P30FxG7m1fi_fAkYosOlYbX1qZ2V UXjF9FXLo3v0ATS1TDB30q3NUEqXzuGobdS6TUrnbHBitB0k6IotL4YGcn5jHNjEZShlTjvb5XPn VBnGI5OicbbZOA6qxR3Podyj3oY21ka0jTPb7x5FiMT.eNSA7GcvOfe3G1bELHTQJhCmVYqmXb5y Z7XjjCaRVLr_7G5WtaTHucu_hnOCPd.IrvJ.Kto9DRTLlKcdSTi_vZXtXwRF1fI_VxNe0bmSdjPE YDG0upR17HrXjfLzVtzLIq6ph6A5Z_ZBJUPgjQk_qE7PEYcQGeBwrybLulf.Kb34mIUDjTo32aw7 PE7lpxs.suwNBnJ9onefCXKoyBxymh6HKrbSbEoLGGikTnvzX8ifKAt3Os2pFlG43hBFRy8h2vro DEA1vBk9DoCvHfnVwK8EVaH8w4CG4jPV669M5SiLgNUQTyCLritikWupoDT_sJvv7tW0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 11 Mar 2019 00:10:34 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1cd5e553d20e916b82dafe8c926bde74; Mon, 11 Mar 2019 00:10:30 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: 32-bit powerpc: gcc8 unable to build devel/llvm60: "/usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935" Message-Id: <1A031A56-9D18-4B12-B98B-302F94C5CF56@yahoo.com> Date: Sun, 10 Mar 2019 17:10:28 -0700 To: FreeBSD PowerPC ML , FreeBSD Toolchain , ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: DBE9A6E3E1 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.99)[0.993,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.52)[ip: (5.11), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.15), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.94)[0.941,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.62)[0.616,0]; RCVD_IN_DNSWL_NONE(0.00)[42.135.6.74.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 00:10:42 -0000 My ports-mgmt/pouriere-devel based build attempt for building = devel/llvm60 failed with: [00:00:53] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_6 [02:05:13] [01] [02:04:20] Saved devel/llvm60 | llvm60-6.0.1_6 wrkdir = to: = /usr/local/poudriere/data/wrkdirs/FBSDpowerpc-default/default/llvm60-6.0.1= _6.tbz [02:05:14] [01] [02:04:21] Finished devel/llvm60 | llvm60-6.0.1_6: = Failed: build [02:05:30] Stopping 1 builders The log shows: [3365/4552] : && /usr/local/bin/g++8 -fPIC -O2 -pipe -DNDEBUG = -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include -fPIC = -fvisibility -inlines-hidden -Werror=3Ddate-time -std=3Dc++11 -Wall -W = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wno-missing-field-initializers -pedantic -Wno-long-long = -Wno-maybe-uninitialized -Wdelete-non-v irtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O2 -pipe = -DNDEBUG -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include=20 -Wl,-rpath=3D/usr/local/lib/gcc8 -L/usr/local/lib/gcc8 -Wl,-z,origin = -Wl,-O3 -Wl,--gc-sections = -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto= /LTO.exports -shared -Wl,-so name,libLTO.so.6 -o lib/libLTO.so.6.0.1 = tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o = tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib = -Wl,-rpath,"\$ORIGIN/../lib:/usr/local/lib" lib/libLL VM-6.0.so && : FAILED: lib/libLTO.so.6.0.1=20 : && /usr/local/bin/g++8 -fPIC -O2 -pipe -DNDEBUG = -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include -fPIC = -fvisibility-inlines-hid den -Werror=3Ddate-time -std=3Dc++11 -Wall -W -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic = -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor=20 -Wno-comment -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG = -Wl,-rpath=3D/usr/local/lib/gcc8 -DNDEBUG -D_GLIBCXX_USE_C99 = -Wl,-rpath=3D/usr/local/lib/gcc8 -isystem /usr/local/include = -Wl,-rpath=3D /usr/local/lib/gcc8 -L/usr/local/lib/gcc8 -Wl,-z,origin -Wl,-O3 = -Wl,--gc-sections = -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto= /LTO.exports -shared -Wl,-soname,libLTO. so.6 -o lib/libLTO.so.6.0.1 = tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o = tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib = -Wl,-rpath,"\$ORIGIN/../lib:/usr/local/lib" lib/libLLVM-6.0.so && : /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935 /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935 collect2: error: ld returned 1 exit status . . . The assert seems to be the last BFD_ASSERT shown below: /* If this is a weak defined symbol in a dynamic object, and we know the real definition in the dynamic object, copy interesting flags over to the real definition. */ if (h->is_weakalias) { struct elf_link_hash_entry *def =3D weakdef (h); =20 /* If the real definition is defined by a regular object file, don't do anything special. See the longer description in _bfd_elf_adjust_dynamic_symbol, below. */ if (def->def_regular) { h =3D def; while ((h =3D h->u.alias) !=3D def) h->is_weakalias =3D 0; } else { while (h->root.type =3D=3D bfd_link_hash_indirect) h =3D (struct elf_link_hash_entry *) h->root.u.i.link; BFD_ASSERT (h->root.type =3D=3D bfd_link_hash_defined || h->root.type =3D=3D bfd_link_hash_defweak); BFD_ASSERT (def->def_dynamic); BFD_ASSERT (def->root.type =3D=3D bfd_link_hash_defined); (*bed->elf_backend_copy_indirect_symbol) (eif->info, def, h); } . . . Context: # uname -apKU FreeBSD FBSDG4S 13.0-CURRENT FreeBSD 13.0-CURRENT #14 r344955M: Fri Mar = 8 22:39:44 PST 2019 = markmi@FBSDFSSD:/usr/obj/powerpcvtsc_clang_gcc421/powerpc.powerpc/usr/src/= powerpc.powerpc/sys/GENERICvtsc-NODBG powerpc powerpc 1300014 1300014 (The 32-bit powerpc is running a gcc 4.2.1 based system. amd64 = system-clang built the bootstrap gcc 4.2.1 toolchain, which in turn built the system. The = 32-bit FreeBSD was running on a PowerMac G5 [2-sockets, 2 cores each].) # svnlite info /usr/ports/ | grep 'Re[plv]' Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 495006 Last Changed Rev: 495006 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Mon Mar 11 12:55:53 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 241331541E02 for ; Mon, 11 Mar 2019 12:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A658094CFF for ; Mon, 11 Mar 2019 12:55:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 601161541DFF; Mon, 11 Mar 2019 12:55:52 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EA8A1541DFE for ; Mon, 11 Mar 2019 12:55:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF76594CFD for ; Mon, 11 Mar 2019 12:55:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C29591296 for ; Mon, 11 Mar 2019 12:55:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2BCtorS034512 for ; Mon, 11 Mar 2019 12:55:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2BCtoCQ034511 for toolchain@FreeBSD.org; Mon, 11 Mar 2019 12:55:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 233707] www/firefox: fails to build with -fstack-protector-{strong,all} + -Wl,-z,nocopyreloc Date: Mon, 11 Mar 2019 12:55:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tijl@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 12:55:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233707 --- Comment #28 from Tijl Coosemans --- Can you attach your config.log to this bug? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Mar 11 12:09:35 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E6281540523 for ; Mon, 11 Mar 2019 12:09:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B21FA936F8 for ; Mon, 11 Mar 2019 12:09:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6BCB11540522; Mon, 11 Mar 2019 12:09:34 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57C991540521 for ; Mon, 11 Mar 2019 12:09:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E23BD936F3 for ; Mon, 11 Mar 2019 12:09:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 22C5BB44 for ; Mon, 11 Mar 2019 12:09:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2BC9Xkc001506 for ; Mon, 11 Mar 2019 12:09:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2BC9Xmj001500 for toolchain@FreeBSD.org; Mon, 11 Mar 2019 12:09:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 233707] www/firefox: fails to build with -fstack-protector-{strong,all} + -Wl,-z,nocopyreloc Date: Mon, 11 Mar 2019 12:09:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 12:09:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233707 --- Comment #27 from rozhuk.im@gmail.com --- (In reply to Tijl Coosemans from comment #26) I do mine tests on 12.0 stable, less than 1 month updated. I see at least two error message about __stack_chk_guard in config.log file, that is why I add -fPIC in few places. IMHO adding -fPIC more correct way to fix this. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Mar 11 19:16:54 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3E8A152A8EF for ; Mon, 11 Mar 2019 19:16:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 797B676CD5 for ; Mon, 11 Mar 2019 19:16:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3546B152A8EE; Mon, 11 Mar 2019 19:16:53 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 211D1152A8ED for ; Mon, 11 Mar 2019 19:16:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC46576CD2 for ; Mon, 11 Mar 2019 19:16:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EA4B64C65 for ; Mon, 11 Mar 2019 19:16:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2BJGp67048975 for ; Mon, 11 Mar 2019 19:16:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2BJGpj6048974 for toolchain@FreeBSD.org; Mon, 11 Mar 2019 19:16:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236313] graphics/opencollada: excessive build time with clang 8 on i386 Date: Mon, 11 Mar 2019 19:16:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 19:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236313 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Mon Mar 11 19:15:57 UTC 2019 New revision: 345021 URL: https://svnweb.freebsd.org/changeset/base/345021 Log: Pull in r355854 from upstream llvm trunk (by Jonas Paulsson): [RegAlloc] Avoid compile time regression with multiple copy hints. As a fix for https://bugs.llvm.org/show_bug.cgi?id=3D40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints(). This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint(). Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201 This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port. PR: 236313 MFC after: 1 month X-MFC-With: r344779 Changes: head/contrib/llvm/lib/CodeGen/TargetRegisterInfo.cpp --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Mar 12 19:20:39 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86FE9153BC08 for ; Tue, 12 Mar 2019 19:20:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ACC081EB4 for ; Tue, 12 Mar 2019 19:20:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: if2hHZwVM1m5FZ.uqOJ5TxeIQVsh7ETa._abkGnR8qqHHagbfyJ2oJBDGEAXCrw zxkqEhlM2fwfgDuc0eQ6oBhiO9sztFiWfYkd3DOSOAFv.m.o991sYwNw6nIo1GkF0q0LkvtooU1b RY6C_hc1oa2QtvuFFoJhlhY5tRBNjrQ2MQoLNTpwjOlHkT8pa5SxOhUuBLgSOJ6ab7Rl2OTMzV6k iVw7CZQ7dxj7pnjUyuJdP0YwCR2FGd8O7CajcmgNrte1dHkq4g0Ix7QS40P0Om1WeMOJt2bR6G7_ 2g5Ghe4T_wRTY055MIBbYAiUDL_utpkrozH.Xip5YOlnCWNKDOSoKApxIbCRM5bB_KRIWUGxVYt4 GHKXQSZB77sJqKqeWmOpvhwEhkKQiMkXohBz8M8W6LSC7f3hHo5Q9fxcbGWpRLP67L63LIPmhoMY 8pDH5TRNHZCaWjLNrpdoQZVU08_tuKFDhTPK2l2asheRy3q2UUzmxYJqlbZyJSrnFNU..7iNV7dx 4TgmDqAi4HM_SBGcsBEtEJ2gW7kCr0Xd6u8uomni94Gi8_kDqhTDrILnsaTuXc.Hm19dHJYgdqnK KVKSUFicBchcsseE6Gy7ZNADS.kKfN701LhvNUWap7ZhcR.B9BWoV_SHMRx1leCG3ohHf6gAC2uN U7o8YmDqBfAqc9yB73frWwU_P5Kfjh_xdhS1p7nNOlklgagtfysPU_xyQijhOWTtyMybRK0RpJzj BZC97BzozxQ8ua2f4QLye19JhfvZskY1BBYfJTYzUxFI5tiiku_msDDd1Imk8R4Vnk2dBtFFYfKy saS2WzBWTJoYbqCJh.FcczR5ow5grwYsjdFk6WLPRpvaxQYr5Zwd00J0j5hz36Ayra_Ni44P7Mbh wGaoN0uyuh_jz0wdRFU83E636bGkpUA_CWmde7w2WaRs2_0r3OcTidIV.nfktPlSV42u3JNgQw_w 6f7csv3_OJX7xvf4nnwAQ4PQVthKlgijvdLVPO8CR8xQZ8liENjBDYRR7LZnWvkzzLs6gYwRmJr2 1WqnU57shEwi_XzOctSfxXIwWl.e.nLHMWWV1uIz_0TJDUXu7g.1YO05hv.PeQOnxTmg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 12 Mar 2019 19:20:30 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp429.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a3f361f990b1a538e0ecfd35588740d2; Tue, 12 Mar 2019 19:20:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Message-Id: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> Date: Tue, 12 Mar 2019 12:20:28 -0700 To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 2ACC081EB4 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.05)[-0.048,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.07)[ip: (-2.47), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.98), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.186.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 19:20:39 -0000 [I sometimes experiment with building powerpc64 (and 32-bit) via more modern toolchains, here a amd64->powerpc64 cross build via system-clang (so 8.0.0).] buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 (but not 32-bit powerpc). However, for a system installed from such for pwoerpc64, the following program (for example) gets a segmentation fault: # more ~/c_tests/exception_test.cpp=20 #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D environment, that was patched for DW_CFA_remember_state and DW_CFA_restore_state handling, with the system built via devel/powerpc64-xtoolchain-gcc related materials. So the failure is on the system library does of things for the WITH_LLVM_LIBUNWIND=3D context.) Unfortunately: A) devel/gdb makes extensive use of thrown C++ exceptions and so does not work for a powerpc64 system based on WITH_LLVM_LIBUNWIND=3D . B) The world built is not using dwarf-2 so /usr/libexec/gdb is not handy/useful. C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort trap during buildworld's compile of gcrt1.s . (Reference material later, below.) D) lldb crashes in llvm_unreachable in lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() on powerpc64. (Reference material later, below.) So I've not managed to check the backtrace for the segmentation fault in the short example. For reference . . . For (C) ( -gdwarf-2 use ): QUOTES (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 void resetRootFile() { assert(Header.MCDwarfFiles.empty()); Header.RootFile.Name.clear(); Header.resetMD5Usage(); Header.HasSource =3D false; } --- lib/csu__L --- cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang integrated assembler command failed due to signal (use = -v to see invocation) FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on LLVM = 8.0.0) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. cc: note: diagnostic msg: Error generating preprocessed source(s) - no = preprocessable inputs. *** [gcrt1.o] Error code 254 make[5]: stopped in /usr/src/lib/csu/powerpc64 .ERROR_TARGET=3D'gcrt1.o' = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' .MAKE.LEVEL=3D'5' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' .CURDIR=3D'/usr/src/lib/csu/powerpc64' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' .TARGETS=3D'all' = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'powerpc' MACHINE_ARCH=3D'powerpc64' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20181221' = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' 1 error END QUOTES For (D) (lldb): QUOTES CPU not supported UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! Abort trap (core dumped) (gdb) bt #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute () = at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers () = at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { if (!m_reg_context_sp) { m_posix_thread =3D nullptr; RegisterInfoInterface *reg_interface =3D nullptr; const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); switch (target_arch.GetMachine()) { case llvm::Triple::aarch64: reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); break; case llvm::Triple::arm: reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); break; case llvm::Triple::ppc: #ifndef __powerpc64__ reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); break; #endif case llvm::Triple::ppc64: reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); break; case llvm::Triple::mips64: reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); break; case llvm::Triple::x86: reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); break; case llvm::Triple::x86_64: reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); break; default: llvm_unreachable("CPU not supported"); } END QUOTES. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Tue Mar 12 21:05:36 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E827153E8ED for ; Tue, 12 Mar 2019 21:05:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8393385D90 for ; Tue, 12 Mar 2019 21:05:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: w5gAGyUVM1nQGcRrwVvEuLZBhyi3RNXAoiES0GDqRulYmlj3NVWunsjlkug.y7I ISfSp51aqqIwhXCrsu1A0ZK_oMAGv8orp2HTd3hCkwbB6dPz68Sj2uk34zveA2HgvnB6hPObtUsH lcvC8BVnzXQCqaUAzeW4gJlaVFcySq0zd7hn_Zd9NMRFs1PYMAzsVtE3fp5UytkFBiuqKO.aSamc G_GpdFDNLCSCJYDJRj5ckWchqpKci05IB1KoBJaoFDvdkpcGaGvAIN.IYwnaLH8zJ6jXQfJAD488 Wb3buUIhZCebvD4NeYe3.j_Ii.oXE1SBzUB.3.2wQguQ6upEovYCmNopVPLmQJcIgSKlGNEtNSLJ n4LzlI0jZEszuDYgurn.JKMD7eoD6MKYa83fPki8pQ4Xqss8qr33EjkEqPNge6yYyIfETDSdhzuK tWzS5L8nAKDQDMYzIAY6Wpxcu9Mr6ZyJTUHxXITwjGe1hrDCByPW5OZcoyFdaRi9aCLUKU0waGaJ VpCIVjIxLtu5h.LekU9ImXiDSZkma88yIcKEEy_.o1VUjqI6PYmOK4Mm3X4y.AUUqRFzrJvZJQYo EuQRAdS5RFKmpb2karRGDXegHQH_evp3t5lgqD3PyWQsmFJ.SHEtPu.99e9ITnXTmmoPuAu1dJR9 zt6ejHItSTRmvBoPqUC9dEnCkrBNImSQBw6l.qPhGY8loeexlhqjTnlUNnA4sjmBlKq05yayQhbW pGbi7pF_Fo37W6ufHbW70CQSISWargucZmwjieDNReorjr0p6EwFk266VhcGIoVz9ZAATz0i5dah cu58qAb8DVSuTzs41WoZjC0ewGQJcDWnG_SHUZ.CkBEW0oo_Es_QUogJRjqKnjNteRImdLDCkhve 7w.1WSh9PCKAqqOQn.z1DKyv53Y7RUHuYl8vY7ukQv.8uOuJDKWC5cRXlAgHI_neqpJ9vg97MNlF pB6QU4LbrkA5T.yK0S_vMKnBi_JW6n8jmJ9p1Qs9gg8nT6bLYQONymNAu333f2FA1A1okosB9KHR qfm9SOUu5.ZdB6FeMFqolGMq3XaPuV1rJBfcDG_fmRM6nLLAMgMVujtB654gP0d17BCA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 12 Mar 2019 21:05:32 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8cc80f3329a5ccc5ed505fabab741b5c; Tue, 12 Mar 2019 21:05:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Date: Tue, 12 Mar 2019 14:05:27 -0700 References: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain In-Reply-To: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 8393385D90 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.43)[-0.430,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.26)[ip: (-3.45), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.98), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[205.186.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 21:05:36 -0000 [I got some libunwind debug output from the a.out run. This and a disassembly of main suggest an instruction pointer address is too large by 0x4 for jumping to the code that would call __cxa_begin_catch .] > On 2019-Mar-12, at 12:20, Mark Millard wrote: >=20 > [I sometimes experiment with building powerpc64 (and 32-bit) via > more modern toolchains, here a amd64->powerpc64 cross build via > system-clang (so 8.0.0).] >=20 > buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 > (but not 32-bit powerpc). However, for a system installed > from such for pwoerpc64, the following program (for example) > gets a segmentation fault: >=20 > # more ~/c_tests/exception_test.cpp=20 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } >=20 > (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D > environment, that was patched for DW_CFA_remember_state and > DW_CFA_restore_state handling, with the system built via > devel/powerpc64-xtoolchain-gcc related materials. So the > failure is on the system library does of things for the > WITH_LLVM_LIBUNWIND=3D context.) >=20 > Unfortunately: >=20 > A) devel/gdb makes extensive use of thrown C++ exceptions > and so does not work for a powerpc64 system based on > WITH_LLVM_LIBUNWIND=3D . >=20 > B) The world built is not using dwarf-2 so /usr/libexec/gdb > is not handy/useful. >=20 > C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort > trap during buildworld's compile of gcrt1.s . (Reference > material later, below.) >=20 > D) lldb crashes in llvm_unreachable in > lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() > on powerpc64. (Reference material later, below.) >=20 > So I've not managed to check the backtrace for the > segmentation fault in the short example. >=20 >=20 >=20 > For reference . . . >=20 >=20 > For (C) ( -gdwarf-2 use ): >=20 > QUOTES > (gdb) bt > #0 thr_kill () at thr_kill.S:3 > #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 > #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 > #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 > #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 > #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 > #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 > #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 > #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 > #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 > #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 >=20 > void resetRootFile() { > assert(Header.MCDwarfFiles.empty()); > Header.RootFile.Name.clear(); > Header.resetMD5Usage(); > Header.HasSource =3D false; > } >=20 > --- lib/csu__L --- > cc: error: unable to execute command: Abort trap (core dumped) > cc: error: clang integrated assembler command failed due to signal = (use -v to see invocation) > FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on = LLVM 8.0.0) > Target: powerpc64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. > cc: note: diagnostic msg: Error generating preprocessed source(s) - no = preprocessable inputs. > *** [gcrt1.o] Error code 254 >=20 > make[5]: stopped in /usr/src/lib/csu/powerpc64 > .ERROR_TARGET=3D'gcrt1.o' > = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' > .MAKE.LEVEL=3D'5' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' > .CURDIR=3D'/usr/src/lib/csu/powerpc64' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' > .TARGETS=3D'all' > = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'powerpc' > MACHINE_ARCH=3D'powerpc64' > MAKEOBJDIRPREFIX=3D'' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20181221' > = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' > .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' > 1 error > END QUOTES >=20 >=20 > For (D) (lldb): >=20 > QUOTES > CPU not supported > UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! > Abort trap (core dumped) >=20 > (gdb) bt > #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 > #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 > #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 > #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 > #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 > #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 > #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 > #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 > #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 > #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute = () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 > #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 > #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 > #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 > #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers () = at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 > #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 > #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () = at /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 > #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 > #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 >=20 > lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { > if (!m_reg_context_sp) { > m_posix_thread =3D nullptr; >=20 > RegisterInfoInterface *reg_interface =3D nullptr; > const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); >=20 > switch (target_arch.GetMachine()) { > case llvm::Triple::aarch64: > reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); > break; > case llvm::Triple::arm: > reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); > break; > case llvm::Triple::ppc: > #ifndef __powerpc64__ > reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); > break; > #endif > case llvm::Triple::ppc64: > reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); > break; > case llvm::Triple::mips64: > reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); > break; > case llvm::Triple::x86: > reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); > break; > case llvm::Triple::x86_64: > reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); > break; > default: > llvm_unreachable("CPU not supported"); > } > END QUOTES. I ran into libunwind having LIBUNWIND_PRINT_UNWINDING and LIBUNWIND_PRINT_APIS so I can report for the segmentation fault: # export LIBUNWIND_PRINT_UNWINDING=3D"" # export LIBUNWIND_PRINT_APIS=3D"" # ./a.out libunwind: _Unwind_RaiseException(ex_obj=3D0x810043060) libunwind: unw_init_local(cursor=3D0x3fffffffffffcb68, = context=3D0x3fffffffffffd100) libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffd850) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffd648, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffd638) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x81019d954, = start_ip=3D0x81019d860, func=3D.anonymous., lsda=3D0x0, personality=3D0x0 libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffd850) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffd648, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffd638) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x10000da8, = start_ip=3D0x10000d64, func=3D.anonymous., lsda=3D0x10000f84, = personality=3D0x8101b5360 libunwind: unwind_phase1(ex_ojb=3D0x810043060): calling personality = function 0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc970) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb68) = =3D> 0x10000f84 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc8b0) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb68) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffc8e8) libunwind: _Unwind_GetIP(context=3D0x3fffffffffffcb68) =3D> 0x10000da8 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc8a0) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb68) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffd848) libunwind: unwind_phase1(ex_ojb=3D0x810043060): _URC_HANDLER_FOUND libunwind: unw_init_local(cursor=3D0x3fffffffffffcb68, = context=3D0x3fffffffffffd100) libunwind: unwind_phase2(ex_ojb=3D0x810043060) libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffca78) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffca30) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffc830, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x81019d860, = func=3D.anonymous., sp=3D0x3fffffffffffd900, lsda=3D0x0, personality=3D0x0= libunwind: unw_step(cursor=3D0x3fffffffffffcb68) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffca78) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffca30) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb68, = &buf=3D0x3fffffffffffc830, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x10000d64, = func=3D.anonymous., sp=3D0x3fffffffffffd9a0, lsda=3D0x10000f84, = personality=3D0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb68, = &info=3D0x3fffffffffffc630) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb68) = =3D> 0x10000f84 libunwind: _Unwind_SetIP(context=3D0x3fffffffffffcb68, value=3D0x10000dac)= libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = value=3D0x10000dac) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb68, reg=3D3, = value=3D0x810043060) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb68, regNum=3D3, = value=3D0x810043060) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb68, reg=3D4, = value=3D0x1) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb68, regNum=3D4, = value=3D0x1) libunwind: unwind_phase2(ex_ojb=3D0x810043060): _URC_INSTALL_CONTEXT libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-1, = &value=3D0x3fffffffffffc830) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb68, regNum=3D-2, = &value=3D0x3fffffffffffca78) libunwind: unwind_phase2(ex_ojb=3D0x810043060): re-entering user code = with ip=3D0x10000dac, sp=3D0x3fffffffffffd9a0 libunwind: unw_resume(cursor=3D0x3fffffffffffcb68) Segmentation fault (core dumped) Note that the 0x10000dac address below is after the "ld r2,40(r1)" that sets up r2's value for use in the 00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3 routine. The ip value reported by unwind_phase2 appears to too large by 0x4 . (gdb) disass main Dump of assembler code for function main(): 0x0000000010000d64 <+0>: mflr r0 0x0000000010000d68 <+4>: std r31,-8(r1) 0x0000000010000d6c <+8>: std r0,16(r1) 0x0000000010000d70 <+12>: stdu r1,-128(r1) 0x0000000010000d74 <+16>: mr r31,r1 0x0000000010000d78 <+20>: li r3,8 0x0000000010000d7c <+24>: bl 0x100007a0 = <00000018.plt_call.__cxa_allocate_exception@@CXXABI_1.3> 0x0000000010000d80 <+28>: ld r2,40(r1) 0x0000000010000d84 <+32>: nop 0x0000000010000d88 <+36>: ld r4,-32728(r2) 0x0000000010000d8c <+40>: addi r4,r4,16 0x0000000010000d90 <+44>: std r4,0(r3) 0x0000000010000d94 <+48>: nop 0x0000000010000d98 <+52>: nop 0x0000000010000d9c <+56>: ld r4,-32720(r2) 0x0000000010000da0 <+60>: ld r5,-32712(r2) 0x0000000010000da4 <+64>: bl 0x10000800 = <00000018.plt_call.__cxa_throw@@CXXABI_1.3> 0x0000000010000da8 <+68>: ld r2,40(r1) 0x0000000010000dac <+72>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> 0x0000000010000db0 <+76>: ld r2,40(r1) 0x0000000010000db4 <+80>: bl 0x100007e0 = <00000018.plt_call.__cxa_end_catch@@CXXABI_1.3> 0x0000000010000db8 <+84>: ld r2,40(r1) 0x0000000010000dbc <+88>: li r3,0 0x0000000010000dc0 <+92>: addi r1,r1,128 0x0000000010000dc4 <+96>: ld r0,16(r1) 0x0000000010000dc8 <+100>: ld r31,-8(r1) 0x0000000010000dcc <+104>: mtlr r0 0x0000000010000dd0 <+108>: blr 0x0000000010000dd4 <+112>: .long 0x0 0x0000000010000dd8 <+116>: .long 0x0 0x0000000010000ddc <+120>: .long 0x0 End of assembler dump. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Tue Mar 12 23:34:56 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E8A51543217 for ; Tue, 12 Mar 2019 23:34:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9607A8C1A2 for ; Tue, 12 Mar 2019 23:34:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 173ZuHAVM1kWY8iVPElFVfo8WPG5n5feEwui3Lon6Uoh3byahgSu1HztApQSWQC U2fOKOBwGorfT8.L3JY39g0GhPVF2w8Z8M_rjcm1txFDp3LLKRzQZJ9BT33UYQy1Ibh12NDhTYqj 1z4HRUZKkFyUNJ3Bza2AQSOJUq04ArdktQkby4mP_IDKh2ZO1LdeZP40lW8igkq19G.uN8oXW5.A AfzPZmXfGfAuXZjn_pFkDp7Av72CVtE.ML9Xqx5T4mOQreH.02yA4h7DWw2v0BjzTv.qVWGRV3RA Be7CA5pkk80rW_U9Fq4FX2vDgW0rygW52Bx.zc_idRiqAV7ulVw.3XXz3BLtF9Qw5ymfyy5tmUbJ S_BLIWW3DT6tbOASD79A3vUq_tJXJLW.hrv3lb1Kks_qlgAyhkHs20TDhWOTD88Df_ssUMtL1S1s VkZDRW4vF9SGf2TCPoWsCgkT0zfJ53hNcH.0j.TpF34Eslzk.PlVPjhfiNjt3oBn8_Bi7nJzCj6f tg_tc8c4TF2rRAp3IVHNctwVRItwFa5A5J91FC0s72k9hlZ0_O8yHw3NfsWSQyO52WEGtC7WJMbo zh_Sh8UqRzK6o.wzf8lTFBV3Rcxvx818Ard3oqIRi1rKF_yGhVJ_jYb4sYgV9D.1Xsn.y85.8kwE lf0jZ_Rah30dsGbZJWFneiITu_lYOZEPa_Ctuxml5YmGoj5arJae0jczTuGNRflEl9ojCSV3eZVm RLU.9Fi6yvkqlb8SD5ZdKTY3Tvp0ijA6KXVAAeqB4jZiz_e2JltHTBPjbmbfwQDejHlKf08MEPl1 kMSLa5u52rNGmnHDJP330jmwMbBtzIKtdOGgnp0HLp_gGDYsUE6IKwefXRFLifvIp6fb_8pjyve9 wa8cZkgRJNt9vNFBfIV9h3xEPotmMVKS06FeFUmjziVjQ0t2KL5oWRp9MCFt2oMkJIvBxtkbLaWA KLItdKcpB6J90IcZnajym210HnJnM1gks.1sQ4vPdqntdTSLRAtHYNoJtHS_DvSURlMiF8DAUCwn Bfb_7CJhxaWm1WPVhqX3LGVh6RSwcyCKaQz6J5TWuo0D6Vg10Xu7CONqqUWIxyi_FPbs80w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Mar 2019 23:34:53 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp427.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f646c7f5135d87e0ef548952e610ce40; Tue, 12 Mar 2019 23:34:50 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Date: Tue, 12 Mar 2019 16:34:47 -0700 References: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain In-Reply-To: Message-Id: <3B37B7B0-DCB0-4984-AABD-4C3448DA7D56@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 9607A8C1A2 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.852,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.37)[ip: (4.33), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.14), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.94)[0.943,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.85)[0.846,0]; RCVD_IN_DNSWL_NONE(0.00)[42.132.6.74.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 23:34:56 -0000 [The unoptimized code is more revealing so I switch to presenting it and what it lead me to: more detail on r2 being mishandled.] > On 2019-Mar-12, at 14:05, Mark Millard wrote: >=20 > [I got some libunwind debug output from the a.out run. This > and a disassembly of main suggest an instruction pointer > address is too large by 0x4 for jumping to the code that > would call __cxa_begin_catch .] >=20 >> On 2019-Mar-12, at 12:20, Mark Millard wrote: >>=20 >> [I sometimes experiment with building powerpc64 (and 32-bit) via >> more modern toolchains, here a amd64->powerpc64 cross build via >> system-clang (so 8.0.0).] >>=20 >> buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 >> (but not 32-bit powerpc). However, for a system installed >> from such for pwoerpc64, the following program (for example) >> gets a segmentation fault: >>=20 >> # more ~/c_tests/exception_test.cpp=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >> (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D >> environment, that was patched for DW_CFA_remember_state and >> DW_CFA_restore_state handling, with the system built via >> devel/powerpc64-xtoolchain-gcc related materials. So the >> failure is on the system library does of things for the >> WITH_LLVM_LIBUNWIND=3D context.) >>=20 >> Unfortunately: >>=20 >> A) devel/gdb makes extensive use of thrown C++ exceptions >> and so does not work for a powerpc64 system based on >> WITH_LLVM_LIBUNWIND=3D . >>=20 >> B) The world built is not using dwarf-2 so /usr/libexec/gdb >> is not handy/useful. >>=20 >> C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort >> trap during buildworld's compile of gcrt1.s . (Reference >> material later, below.) >>=20 >> D) lldb crashes in llvm_unreachable in >> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() >> on powerpc64. (Reference material later, below.) >>=20 >> So I've not managed to check the backtrace for the >> segmentation fault in the short example. >>=20 >>=20 >>=20 >> For reference . . . >>=20 >>=20 >> For (C) ( -gdwarf-2 use ): >>=20 >> QUOTES >> (gdb) bt >> #0 thr_kill () at thr_kill.S:3 >> #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >> #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >> #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 >> #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 >> #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 >> #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 >> #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 >> #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 >> #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 >> #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 >> #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 >>=20 >> void resetRootFile() { >> assert(Header.MCDwarfFiles.empty()); >> Header.RootFile.Name.clear(); >> Header.resetMD5Usage(); >> Header.HasSource =3D false; >> } >>=20 >> --- lib/csu__L --- >> cc: error: unable to execute command: Abort trap (core dumped) >> cc: error: clang integrated assembler command failed due to signal = (use -v to see invocation) >> FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on = LLVM 8.0.0) >> Target: powerpc64-unknown-freebsd13.0 >> Thread model: posix >> InstalledDir: /usr/bin >> cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >> cc: note: diagnostic msg: Error generating preprocessed source(s) - = no preprocessable inputs. >> *** [gcrt1.o] Error code 254 >>=20 >> make[5]: stopped in /usr/src/lib/csu/powerpc64 >> .ERROR_TARGET=3D'gcrt1.o' >> = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' >> .MAKE.LEVEL=3D'5' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' >> .CURDIR=3D'/usr/src/lib/csu/powerpc64' >> .MAKE=3D'make' >> = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' >> .TARGETS=3D'all' >> = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'powerpc' >> MACHINE_ARCH=3D'powerpc64' >> MAKEOBJDIRPREFIX=3D'' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20181221' >> = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' >> .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' >> 1 error >> END QUOTES >>=20 >>=20 >> For (D) (lldb): >>=20 >> QUOTES >> CPU not supported >> UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! >> Abort trap (core dumped) >>=20 >> (gdb) bt >> #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 >> #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 >> #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >> #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 >> #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 >> #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 >> #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 >> #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 >> #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 >> #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 >> #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute = () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 >> #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 >> #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 >> #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 >> #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers = () at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 >> #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 >> #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () = at /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 >> #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 >> #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 >>=20 >> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { >> if (!m_reg_context_sp) { >> m_posix_thread =3D nullptr; >>=20 >> RegisterInfoInterface *reg_interface =3D nullptr; >> const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); >>=20 >> switch (target_arch.GetMachine()) { >> case llvm::Triple::aarch64: >> reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); >> break; >> case llvm::Triple::arm: >> reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); >> break; >> case llvm::Triple::ppc: >> #ifndef __powerpc64__ >> reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); >> break; >> #endif >> case llvm::Triple::ppc64: >> reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); >> break; >> case llvm::Triple::mips64: >> reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); >> break; >> case llvm::Triple::x86: >> reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); >> break; >> case llvm::Triple::x86_64: >> reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); >> break; >> default: >> llvm_unreachable("CPU not supported"); >> } >> END QUOTES. >=20 >=20 >=20 > I ran into libunwind having LIBUNWIND_PRINT_UNWINDING and > LIBUNWIND_PRINT_APIS so I can report for the segmentation > fault: >=20 > # export LIBUNWIND_PRINT_UNWINDING=3D"" > # export LIBUNWIND_PRINT_APIS=3D"" > # ./a.out > . . . Using unoptimized code instead: # c++ -g exception_test.cpp libunwind: __register_frame_info(0x137d6610, 0x13ae3150) libunwind: __register_frame_info(0x137d6610, 0x13ae3150) libunwind: __deregister_frame_info(0x137d6610) libunwind: __deregister_frame_info(0x137d6610) # ./a.out libunwind: _Unwind_RaiseException(ex_obj=3D0x810043060) libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x81019d954, = start_ip=3D0x81019d860, func=3D.anonymous., lsda=3D0x0, personality=3D0x0 libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x10000dac, = start_ip=3D0x10000d64, func=3D.anonymous., lsda=3D0x10000fe0, = personality=3D0x8101b5360 libunwind: unwind_phase1(ex_ojb=3D0x810043060): calling personality = function 0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc950) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48) = =3D> 0x10000fe0 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc890) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc8c8) libunwind: _Unwind_GetIP(context=3D0x3fffffffffffcb48) =3D> 0x10000dac libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc880) libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffd828) libunwind: unwind_phase1(ex_ojb=3D0x810043060): _URC_HANDLER_FOUND libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) libunwind: unwind_phase2(ex_ojb=3D0x810043060) libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x81019d860, = func=3D.anonymous., sp=3D0x3fffffffffffd8e0, lsda=3D0x0, personality=3D0x0= libunwind: unw_step(cursor=3D0x3fffffffffffcb48) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x10000d64, = func=3D.anonymous., sp=3D0x3fffffffffffd980, lsda=3D0x10000fe0, = personality=3D0x8101b5360 libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc610) libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48) = =3D> 0x10000fe0 libunwind: _Unwind_SetIP(context=3D0x3fffffffffffcb48, value=3D0x10000db4)= libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = value=3D0x10000db4) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D3, = value=3D0x810043060) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D3, = value=3D0x810043060) libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D4, = value=3D0x1) libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D4, = value=3D0x1) libunwind: unwind_phase2(ex_ojb=3D0x810043060): _URC_INSTALL_CONTEXT libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc810) libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) libunwind: unwind_phase2(ex_ojb=3D0x810043060): re-entering user code = with ip=3D0x10000db4, sp=3D0x3fffffffffffd980 libunwind: unw_resume(cursor=3D0x3fffffffffffcb48) Segmentation fault (core dumped) The below shows that the 0x10000db4 in this case seems right --and also that the code sequence does not set r2. Apparently the throw handling was supposed to set it so the optimized code skips setting it. (Later below it seems r2 should have been set by something but was not correctly set.) (gdb) disass main Dump of assembler code for function main(): 0x0000000010000d64 <+0>: mflr r0 0x0000000010000d68 <+4>: std r31,-8(r1) 0x0000000010000d6c <+8>: std r0,16(r1) 0x0000000010000d70 <+12>: stdu r1,-160(r1) 0x0000000010000d74 <+16>: mr r31,r1 0x0000000010000d78 <+20>: li r3,0 0x0000000010000d7c <+24>: stw r3,148(r31) 0x0000000010000d80 <+28>: li r3,8 0x0000000010000d84 <+32>: bl 0x100007a0 = <00000018.plt_call.__cxa_allocate_exception@@CXXABI_1.3> 0x0000000010000d88 <+36>: ld r2,40(r1) 0x0000000010000d8c <+40>: std r3,112(r31) 0x0000000010000d90 <+44>: bl 0x10000e00 = 0x0000000010000d94 <+48>: nop 0x0000000010000d98 <+52>: ld r4,-32728(r2) 0x0000000010000d9c <+56>: nop 0x0000000010000da0 <+60>: ld r5,-32720(r2) 0x0000000010000da4 <+64>: ld r3,112(r31) 0x0000000010000da8 <+68>: bl 0x10000800 = <00000018.plt_call.__cxa_throw@@CXXABI_1.3> 0x0000000010000dac <+72>: ld r2,40(r1) 0x0000000010000db0 <+76>: b 0x10000df4 0x0000000010000db4 <+80>: mr r5,r4 0x0000000010000db8 <+84>: std r3,136(r31) 0x0000000010000dbc <+88>: stw r5,132(r31) 0x0000000010000dc0 <+92>: b 0x10000dc4 0x0000000010000dc4 <+96>: ld r3,136(r31) 0x0000000010000dc8 <+100>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> 0x0000000010000dcc <+104>: ld r2,40(r1) 0x0000000010000dd0 <+108>: std r3,120(r31) 0x0000000010000dd4 <+112>: bl 0x100007e0 = <00000018.plt_call.__cxa_end_catch@@CXXABI_1.3> 0x0000000010000dd8 <+116>: ld r2,40(r1) 0x0000000010000ddc <+120>: li r3,0 0x0000000010000de0 <+124>: addi r1,r1,160 0x0000000010000de4 <+128>: ld r0,16(r1) 0x0000000010000de8 <+132>: ld r31,-8(r1) 0x0000000010000dec <+136>: mtlr r0 0x0000000010000df0 <+140>: blr 0x0000000010000df4 <+144>: .long 0x0 0x0000000010000df8 <+148>: .long 0x0 0x0000000010000dfc <+152>: .long 0x0 End of assembler dump. Notably lr seems to be: 0x10000dcc which is just after: bl 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> Note also the pc, r12, and ctr all having the failure address: 0x81042b900 . #0 0x000000081042b900 in ?? () from /lib/libc.so.7 (gdb) x/32i 0x000000081042b8F0 0x81042b8f0 : .long 0x8 0x81042b8f4 : vmrglh v1,v30,v7 0x81042b8f8: .long 0x8 0x81042b8fc: vsubeuqm v1,v30,v7,v17 =3D> 0x81042b900: .long 0x8 0x81042b904: vpmsumw v1,v30,v7 0x81042b908 <_citrus_bcs_skip_ws_len@got.plt>: .long 0x8 0x81042b90c <_citrus_bcs_skip_ws_len@got.plt+4>: .long 0x103e3c92 0x81042b910: .long 0x8 0x81042b914: .long 0x103e3c9b 0x81042b918: .long 0x8 (gdb) info reg r0 0x810563d10 34633825552 r1 0x3fffffffffffd980 4611686018427378048 r2 0x0 0 r3 0x810043060 34628448352 r4 0x1 1 r5 0x1 1 r6 0x8103d9490 34632209552 r7 0x0 0 r8 0x29 41 r9 0x4e 78 r10 0x3fffffffffffc8f8 4611686018427373816 r11 0x81056c28c 34633859724 r12 0x81042b900 34632546560 r13 0x81005f020 34628562976 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0x0 0 r27 0x0 0 r28 0x1 1 r29 0x3fffffffffffdb78 4611686018427378552 r30 0x3fffffffffffdb88 4611686018427378568 r31 0x3fffffffffffd980 4611686018427378048 pc 0x81042b900 0x81042b900 msr cr 0x28000802 671090690 lr 0x10000dcc 0x10000dcc ctr 0x81042b900 34632546560 xer 0x0 0 fpscr 0x0 0 vscr vrsave And the following shows how r12 and ctr were filled in by code that expected r2 to be correct: (gdb) x/32i 0x100007c0 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 . . . Overall: r2 seem to be mishandled in the exception handling. Note on the gdb use: The above devel/gdb activity was executed from a devel/powerpc64-xtoolchain-gcc built world that was based on WITHOUT_LLVM_LIBUNWIND=3D and and my patched libgcc_s material. This means it suffered from mismatches with the clang/libunwind world (that I chroot to): QUOTE warning: .dynamic section for "/usr/lib/libc++.so.1" is not at the = expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libcxxrt.so.1" is not at the = expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libm.so.5" is not at the expected = address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libc.so.7" is not at the expected = address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the = expected address (wrong library or version mismatch?) warning: .dynamic section for "/libexec/ld-elf.so.1" is not at the = expected address (wrong library or version mismatch?) END QUOTE But any thrown exceptions the gdb may have used worked in my patched WITHOUT_LLVM_LIBUNWIND=3D environment. This gdb is not limited to dwarf-2. The material from the a.out is not misinterpreted even if library code details might be. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Mar 13 02:45:51 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05EAC15476FD; Wed, 13 Mar 2019 02:45:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 84B589130B; Wed, 13 Mar 2019 02:45:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2D2jfSc031816 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Mar 2019 19:45:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2D2jfJD031815; Tue, 12 Mar 2019 19:45:41 -0700 (PDT) (envelope-from sgk) Date: Tue, 12 Mar 2019 19:45:41 -0700 From: Steve Kargl To: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Optimization bug with floating-point? Message-ID: <20190313024506.GA31746@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 84B589130B X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.32 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.75)[0.747,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[washington.edu]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.97)[0.968,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; REPLYTO_ADDR_EQ_FROM(0.00)[]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.89)[0.891,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.09), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 02:45:51 -0000 All, There seems to an optimization bug with clang on % uname -a FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 IOW, if you do numerica work on i386, you may want to check your results. The program demonstrating the issue is at the end of this email. gcc8 --version gcc8 (FreeBSD Ports Collection) 8.3.0 gcc8 -fno-builtin -o z a.c -lm && ./z gcc8 -O -fno-builtin -o z a.c -lm && ./z gcc8 -O2 -fno-builtin -o z a.c -lm && ./z gcc8 -O3 -fno-builtin -o z a.c -lm && ./z Max ULP: 2.297073 Count: 0 (# of ULP that exceed 21) cc --version FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) Target: i386-unknown-freebsd13.0 cc -fno-builtin -o z a.c -lm && ./z Max ULP: 2.297073 Count: 0 cc -O -fno-builtin -o z a.c -lm && ./z cc -O2 -fno-builtin -o z a.c -lm && ./z cc -O3 -fno-builtin -o z a.c -lm && ./z ur ui: 21.588761 7.006300 x y: 9.5623927 1.4993777 csinhf: 5.07348328e+02 7.09178613e+03 dp_csinh: 5.07348986e+02 7.09178955e+03 sinhf: 7.10991113e+03 cosf: 7.13578984e-02 Max ULP: 23.061242 Count: 39 (# of ULP that exceeds 21) Things are much worse than this toy program shows. My test program used in development of libm is giving Restrict x < 10 ./testf -u -X 10 Max ULP Re: 136628.340239 Max ULP Im: 1891176.003955 Restrict c < 50 ./testf -u -X 10 Max ULP Re: 3615923.332529 Max ULP Im: 13677733.591783 /* * Compute 1 million valus of csinhf() and then compute the ULP for * for the real and imaginary parts. */ #include #include #include #include #include #include /* Return 0 <= x < 1. */ double ranged(void) { union { double x; struct { uint32_t lo; uint32_t hi; } u; } v; v.u.hi = (uint32_t)random(); v.u.hi = ((v.u.hi << 11) >> 11) | 0x3ff00000; v.u.lo = (uint32_t)random(); return (v.x - 1); } float rangef(void) { float s; s = (float)ranged(); return (s); } /* Double precision csinh() without using C's double complex.s */ void dp_csinh(double x, double y, double *re, double *im) { double c, s; sincos(y, &s, &c); *re = sinh(x) * c; *im = cosh(x) * s; } /* ULP estimate. */ double ulpfd(float app, double acc) { int n; double f; f = frexp(acc, &n); f = fabs(acc - app); f = ldexp(f, FLT_MANT_DIG - n); return (f); } int main(void) { double re, im, u, ur, ui; float complex f; float x, y; int cnt, i; srandom(19632019); ur = ui = 0; for (cnt = 0, i = 0; i < 10000000; i++) { x = rangef() + 9; y = rangef() + 0.5; f = csinhf(CMPLXF(x,y)); dp_csinh((double)x, (double)y, &re, &im); ur = ulpfd(crealf(f), re); if (ur > u) u = ur; ui = ulpfd(cimagf(f), im); if (ui > u) u = ui; if (ur > 21 || ui > 21) { printf(" ur ui: %f %f\n", ur, ui); printf(" x y: %.7f %.7f\n", x, y); printf(" csinhf: %.8e %.8e\n", crealf(f), cimagf(f)); printf("dp_csinh: %.8le %.8le\n", re, im); printf(" sinhf: %.8e\n", sinhf(x)); printf(" cosf: %.8e\n\n", cosf(y)); cnt++; } } printf("Max ULP: %f\n", u); printf("Count: %d\n", cnt); return (0); } -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 03:24:41 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 181E3154847E for ; Wed, 13 Mar 2019 03:24:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-20.consmr.mail.ne1.yahoo.com (sonic304-20.consmr.mail.ne1.yahoo.com [66.163.191.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 219C9927DA for ; Wed, 13 Mar 2019 03:24:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: sN8m3aMVM1mmJD19pZxn.KIqiVw8VlfjDxCBPFxqrO2b__SO6SE3xvGXKgYvOgM HGoZlGRGzlHIyHTYZo2oH44ScQ3vf1YferLXERBVf4cUGUN33fow_hoRVMuwDei1OjPXkjOgqFZp 7.SzIsk6ZAlCm.bvx5ST72yRl1dLjhkAGjhry1ZO2GOFzZ3dgFsopa.RuasMxLsi4866H.pFVMe0 79xQpSWuytH1xIRkG.m15oC99HZIJ2C2LCPwonLmubLzsurmtDkF_MQ20NnFjBeeVfuc4FxJlWVU i11XqzFzczWJZDIA1AZNboYvBjo996Rcwu4jwcZ9QUMBCZcGBK_eMDdOg20gvm7B08uyIwZSeVK_ iVWWDuBV8urst2Y1I__OCoDFm6VLLNOUH6YOxa1AikObBE1_2_MV07CCsCaJQGQ8s7rruu1pFwms 6NvyTwt0Fdo3Nn7q3tMTObzV7NCvNh4XC4kNHU4CVo6tEOq3oCJh8BvTg4YQr.p1QyO03FZ_RTEO lXfqomuklNG9_WA3J.R5t7kunNWw7REtfr29elUiXdHtQtBuGilUWFFGik8rUYV0PeEu3rCQx5MR i5v6wa.lkZx3D2TwlpkIoO5w9Ls5vILXGsbXjd2tTExY0vsOdvOIc2.TvmR0qr.r8qItGP9ufbpo Gqb2orvUEAL8DvuYh0SOiTjysqLDBmGbZAH2h4nKaFlwJjqODSQSFSrEqhAimsMDYPqzhPr9U27. tX7Li3ZZHLHmdQXUrkywpVeRBbX.lS5qriSHZdFZFeF2AElHpO35lBiu4jT2IWlFoQme80fnqS63 OKcQlF8hpqyqFVxUPkBstfiw4ZIrM1BQPVYXfPX9CVmROI_hzM78KaR8CZTCBDDEoUq7HfykGl85 z6ibgsdBLO7sZJEK.UGd0fJhxQ948lJ11igfn2ULv_lIWuLzgCVUzRDsxSZRkL8fyCS3AcfJRmuY 5vDSZiXprv.epsQXtOk_XwpONcHWcnl3GkpFJNolMlSrKPn1pbai6EHljlDx0xkLiZvlkR3gXi_6 aE4AKKpI.Q_Rr3D_VAEdOPoT4btLSeu_e8JNOIvvMqOl8NJw9oeZq1xEgvioB2PNgMjb3V8Tv Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Wed, 13 Mar 2019 03:24:37 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3ab372a0c178cdb6562a2fb532b534d9; Wed, 13 Mar 2019 03:24:32 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r345044: WITH_LLVM_LIBUNWIND= based buildworld leads to thrown C++ exceptions segmentation faulting Date: Tue, 12 Mar 2019 20:24:30 -0700 References: <36A485AF-E786-4BDB-8DD8-863BAB38D359@yahoo.com> <3B37B7B0-DCB0-4984-AABD-4C3448DA7D56@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain In-Reply-To: <3B37B7B0-DCB0-4984-AABD-4C3448DA7D56@yahoo.com> Message-Id: <92CBCDF0-C870-49A8-8A00-868C7BACF38A@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 219C9927DA X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.976,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.49)[ip: (5.31), ipnet: 66.163.184.0/21(1.23), asn: 36646(0.98), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.82)[0.818,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.884,0]; RCVD_IN_DNSWL_NONE(0.00)[146.191.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 03:24:41 -0000 [Explicitly setting r2 to its expected value in gdb does let the program complete without failing.] > On 2019-Mar-12, at 16:34, Mark Millard wrote: >=20 > [The unoptimized code is more revealing so I switch to > presenting it and what it lead me to: more detail on > r2 being mishandled.] >=20 >> On 2019-Mar-12, at 14:05, Mark Millard wrote: >>=20 >> [I got some libunwind debug output from the a.out run. This >> and a disassembly of main suggest an instruction pointer >> address is too large by 0x4 for jumping to the code that >> would call __cxa_begin_catch .] >>=20 >>> On 2019-Mar-12, at 12:20, Mark Millard wrote: >>>=20 >>> [I sometimes experiment with building powerpc64 (and 32-bit) via >>> more modern toolchains, here a amd64->powerpc64 cross build via >>> system-clang (so 8.0.0).] >>>=20 >>> buildworld with WITH_LLVM_LIBUNWIND=3D completes for powerpc64 >>> (but not 32-bit powerpc). However, for a system installed >>> from such for pwoerpc64, the following program (for example) >>> gets a segmentation fault: >>>=20 >>> # more ~/c_tests/exception_test.cpp=20 >>> #include >>>=20 >>> int main(void) >>> { >>> try { throw std::exception(); } >>> catch (std::exception& e) {} >>> return 0; >>> } >>>=20 >>> (Note: the same a.out works under a WITHOUT_LLVM_LIBUNWIND=3D >>> environment, that was patched for DW_CFA_remember_state and >>> DW_CFA_restore_state handling, with the system built via >>> devel/powerpc64-xtoolchain-gcc related materials. So the >>> failure is on the system library does of things for the >>> WITH_LLVM_LIBUNWIND=3D context.) >>>=20 >>> Unfortunately: >>>=20 >>> A) devel/gdb makes extensive use of thrown C++ exceptions >>> and so does not work for a powerpc64 system based on >>> WITH_LLVM_LIBUNWIND=3D . >>>=20 >>> B) The world built is not using dwarf-2 so /usr/libexec/gdb >>> is not handy/useful. >>>=20 >>> C) CFLAGS+=3D-gdwarf-2 leads to system-clang having an Abort >>> trap during buildworld's compile of gcrt1.s . (Reference >>> material later, below.) >>>=20 >>> D) lldb crashes in llvm_unreachable in >>> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() >>> on powerpc64. (Reference material later, below.) >>>=20 >>> So I've not managed to check the backtrace for the >>> segmentation fault in the short example. >>>=20 >>>=20 >>>=20 >>> For reference . . . >>>=20 >>>=20 >>> For (C) ( -gdwarf-2 use ): >>>=20 >>> QUOTES >>> (gdb) bt >>> #0 thr_kill () at thr_kill.S:3 >>> #1 0x000000000474afcf in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x00000000046cd386 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >>> #3 0x00000000047394ba in __assert (func=3D, = file=3D, line=3D, failedexpr=3D) at /usr/src/lib/libc/gen/assert.c:51 >>> #4 0x000000000429aa9f in resetRootFile () at = /usr/src/contrib/llvm/include/llvm/MC/MCDwarf.h:316 >>> #5 parseDirectiveFile () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:3377 >>> #6 parseStatement () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:2023 >>> #7 0x000000000428cc12 in Run () at = /usr/src/contrib/llvm/lib/MC/MCParser/AsmParser.cpp:884 >>> #8 0x000000000163c649 in ExecuteAssembler () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:503 >>> #9 cc1as_main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/cc1as_main.cpp:589 >>> #10 0x0000000001643d10 in ExecuteCC1Tool () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:312 >>> #11 main () at = /usr/src/contrib/llvm/tools/clang/tools/driver/driver.cpp:382 >>>=20 >>> void resetRootFile() { >>> assert(Header.MCDwarfFiles.empty()); >>> Header.RootFile.Name.clear(); >>> Header.resetMD5Usage(); >>> Header.HasSource =3D false; >>> } >>>=20 >>> --- lib/csu__L --- >>> cc: error: unable to execute command: Abort trap (core dumped) >>> cc: error: clang integrated assembler command failed due to signal = (use -v to see invocation) >>> FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on = LLVM 8.0.0) >>> Target: powerpc64-unknown-freebsd13.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>> cc: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >>> cc: note: diagnostic msg: Error generating preprocessed source(s) - = no preprocessable inputs. >>> *** [gcrt1.o] Error code 254 >>>=20 >>> make[5]: stopped in /usr/src/lib/csu/powerpc64 >>> .ERROR_TARGET=3D'gcrt1.o' >>> = .ERROR_META_FILE=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/lib/csu/powerpc64/gcrt1.o.meta' >>> .MAKE.LEVEL=3D'5' >>> MAKEFILE=3D'' >>> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >>> _ERROR_CMD=3D'cc -gdwarf-2 -target powerpc64-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd13.0/bin/ -O2 -pipe = -I/usr/src/lib/csu/common -I/usr/src/lib/libc/include -mlongcall = -DCRT_IRELOC_SUPPRESS -std=3Dgnu99 -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual = -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls = -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o gcrt1.o gcrt1.s;' >>> .CURDIR=3D'/usr/src/lib/csu/powerpc64' >>> .MAKE=3D'make' >>> = .OBJDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/lib/csu/powerpc64' >>> .TARGETS=3D'all' >>> = DESTDIR=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/powerpc.powerpc64/tmp' >>> LD_LIBRARY_PATH=3D'' >>> MACHINE=3D'powerpc' >>> MACHINE_ARCH=3D'powerpc64' >>> MAKEOBJDIRPREFIX=3D'' >>> MAKESYSPATH=3D'/usr/src/share/mk' >>> MAKE_VERSION=3D'20181221' >>> = PATH=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/p= owerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lega= cy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_alt= binutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/bin::/sbin= :/bin:/usr/sbin:/usr/bin' >>> SRCTOP=3D'/usr/src' >>> = OBJTOP=3D'/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64' >>> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null = /usr/src/lib/csu/powerpc64/Makefile /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/csu/powerpc64/../Makefile.inc = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/csu/powerpc64/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' >>> .PATH=3D'. /usr/src/lib/csu/powerpc64 /usr/src/lib/csu/common' >>> 1 error >>> END QUOTES >>>=20 >>>=20 >>> For (D) (lldb): >>>=20 >>> QUOTES >>> CPU not supported >>> UNREACHABLE executed at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192! >>> Abort trap (core dumped) >>>=20 >>> (gdb) bt >>> #0 0x0000000813715208 in .__sys_thr_kill () at thr_kill.S:3 >>> #1 0x00000008137147cc in __raise (s=3D) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x000000081366b5d8 in abort () at = /usr/src/lib/libc/stdlib/abort.c:79 >>> #3 0x0000000011df6fb8 in llvm::llvm_unreachable_internal () at = /usr/src/contrib/llvm/lib/Support/ErrorHandling.cpp:222 >>> #4 0x00000000103aaaf8 in FreeBSDThread::GetRegisterContext () at = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD/FreeBSDThr= ead.cpp:192 >>> #5 0x00000000105807d4 in lldb_private::Thread::SetupForResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Thread.cpp:613 >>> #6 0x0000000010571bc8 in lldb_private::ThreadList::WillResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/ThreadList.cpp:541 >>> #7 0x00000000105da23c in lldb_private::Process::PrivateResume () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Process.cpp:3281 >>> #8 0x00000000105a00c8 in lldb_private::Target::Launch () at = /usr/src/contrib/llvm/tools/lldb/source/Target/Target.cpp:2922 >>> #9 0x000000001073f550 in CommandObjectProcessLaunch::DoExecute () = at = /usr/src/contrib/llvm/tools/lldb/source/Commands/CommandObjectProcess.cpp:= 221 >>> #10 0x00000000106c36c4 in lldb_private::CommandObjectParsed::Execute = () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:975 >>> #11 0x00000000106d8b44 in = lldb_private::CommandInterpreter::HandleCommand () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :1761 >>> #12 0x00000000106da0a0 in = lldb_private::CommandInterpreter::IOHandlerInputComplete () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :2801 >>> #13 0x00000000107c0a08 in lldb_private::IOHandlerEditline::Run () at = /usr/src/contrib/llvm/tools/lldb/source/Core/IOHandler.cpp:558 >>> #14 0x0000000010346e5c in lldb_private::Debugger::ExecuteIOHandlers = () at /usr/src/contrib/llvm/tools/lldb/source/Core/Debugger.cpp:988 >>> #15 0x00000000106c8ddc in = lldb_private::CommandInterpreter::RunCommandInterpreter () at = /usr/src/contrib/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp= :3003 >>> #16 0x000000001034feb4 in lldb::SBDebugger::RunCommandInterpreter () = at /usr/src/contrib/llvm/tools/lldb/source/API/SBDebugger.cpp:935 >>> #17 0x00000000101de878 in Driver::MainLoop () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:756 >>> #18 0x00000000101a0088 in main () at = /usr/src/contrib/llvm/tools/lldb/tools/driver/Driver.cpp:936 >>>=20 >>> lldb::RegisterContextSP FreeBSDThread::GetRegisterContext() { >>> if (!m_reg_context_sp) { >>> m_posix_thread =3D nullptr; >>>=20 >>> RegisterInfoInterface *reg_interface =3D nullptr; >>> const ArchSpec &target_arch =3D = GetProcess()->GetTarget().GetArchitecture(); >>>=20 >>> switch (target_arch.GetMachine()) { >>> case llvm::Triple::aarch64: >>> reg_interface =3D new RegisterInfoPOSIX_arm64(target_arch); >>> break; >>> case llvm::Triple::arm: >>> reg_interface =3D new RegisterInfoPOSIX_arm(target_arch); >>> break; >>> case llvm::Triple::ppc: >>> #ifndef __powerpc64__ >>> reg_interface =3D new = RegisterContextFreeBSD_powerpc32(target_arch); >>> break; >>> #endif >>> case llvm::Triple::ppc64: >>> reg_interface =3D new = RegisterContextFreeBSD_powerpc64(target_arch); >>> break; >>> case llvm::Triple::mips64: >>> reg_interface =3D new RegisterContextFreeBSD_mips64(target_arch); >>> break; >>> case llvm::Triple::x86: >>> reg_interface =3D new RegisterContextFreeBSD_i386(target_arch); >>> break; >>> case llvm::Triple::x86_64: >>> reg_interface =3D new RegisterContextFreeBSD_x86_64(target_arch); >>> break; >>> default: >>> llvm_unreachable("CPU not supported"); >>> } >>> END QUOTES. >>=20 >>=20 >>=20 >> I ran into libunwind having LIBUNWIND_PRINT_UNWINDING and >> LIBUNWIND_PRINT_APIS so I can report for the segmentation >> fault: >>=20 >> # export LIBUNWIND_PRINT_UNWINDING=3D"" >> # export LIBUNWIND_PRINT_APIS=3D"" >> # ./a.out >> . . . >=20 > Using unoptimized code instead: >=20 > # c++ -g exception_test.cpp > libunwind: __register_frame_info(0x137d6610, 0x13ae3150) > libunwind: __register_frame_info(0x137d6610, 0x13ae3150) > libunwind: __deregister_frame_info(0x137d6610) > libunwind: __deregister_frame_info(0x137d6610) > # ./a.out > libunwind: _Unwind_RaiseException(ex_obj=3D0x810043060) > libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) > libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x81019d954, = start_ip=3D0x81019d860, func=3D.anonymous., lsda=3D0x0, personality=3D0x0 > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffd830) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffd628, bufLen=3D512) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffd618) > libunwind: unwind_phase1(ex_ojb=3D0x810043060): pc=3D0x10000dac, = start_ip=3D0x10000d64, func=3D.anonymous., lsda=3D0x10000fe0, = personality=3D0x8101b5360 > libunwind: unwind_phase1(ex_ojb=3D0x810043060): calling personality = function 0x8101b5360 > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc950) > libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48)= =3D> 0x10000fe0 > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc890) > libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc8c8) > libunwind: _Unwind_GetIP(context=3D0x3fffffffffffcb48) =3D> 0x10000dac > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc880) > libunwind: _Unwind_GetRegionStart(context=3D0x3fffffffffffcb48) =3D> = 0x10000d64 > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffd828) > libunwind: unwind_phase1(ex_ojb=3D0x810043060): _URC_HANDLER_FOUND > libunwind: unw_init_local(cursor=3D0x3fffffffffffcb48, = context=3D0x3fffffffffffd0e0) > libunwind: unwind_phase2(ex_ojb=3D0x810043060) > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x81019d860, = func=3D.anonymous., sp=3D0x3fffffffffffd8e0, lsda=3D0x0, personality=3D0x0= > libunwind: unw_step(cursor=3D0x3fffffffffffcb48) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffca10) > libunwind: unw_get_proc_name(cursor=3D0x3fffffffffffcb48, = &buf=3D0x3fffffffffffc810, bufLen=3D512) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): start_ip=3D0x10000d64, = func=3D.anonymous., sp=3D0x3fffffffffffd980, lsda=3D0x10000fe0, = personality=3D0x8101b5360 > libunwind: unw_get_proc_info(cursor=3D0x3fffffffffffcb48, = &info=3D0x3fffffffffffc610) > libunwind: _Unwind_GetLanguageSpecificData(context=3D0x3fffffffffffcb48)= =3D> 0x10000fe0 > libunwind: _Unwind_SetIP(context=3D0x3fffffffffffcb48, = value=3D0x10000db4) > libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = value=3D0x10000db4) > libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D3, = value=3D0x810043060) > libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D3, = value=3D0x810043060) > libunwind: _Unwind_SetGR(context=3D0x3fffffffffffcb48, reg=3D4, = value=3D0x1) > libunwind: unw_set_reg(cursor=3D0x3fffffffffffcb48, regNum=3D4, = value=3D0x1) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): _URC_INSTALL_CONTEXT > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-1, = &value=3D0x3fffffffffffc810) > libunwind: unw_get_reg(cursor=3D0x3fffffffffffcb48, regNum=3D-2, = &value=3D0x3fffffffffffca58) > libunwind: unwind_phase2(ex_ojb=3D0x810043060): re-entering user code = with ip=3D0x10000db4, sp=3D0x3fffffffffffd980 > libunwind: unw_resume(cursor=3D0x3fffffffffffcb48) > Segmentation fault (core dumped) >=20 > The below shows that the 0x10000db4 in this case seems right --and > also that the code sequence does not set r2. Apparently the > throw handling was supposed to set it so the optimized code > skips setting it. (Later below it seems r2 should have been > set by something but was not correctly set.) >=20 > (gdb) disass main > Dump of assembler code for function main(): > 0x0000000010000d64 <+0>: mflr r0 > 0x0000000010000d68 <+4>: std r31,-8(r1) > 0x0000000010000d6c <+8>: std r0,16(r1) > 0x0000000010000d70 <+12>: stdu r1,-160(r1) > 0x0000000010000d74 <+16>: mr r31,r1 > 0x0000000010000d78 <+20>: li r3,0 > 0x0000000010000d7c <+24>: stw r3,148(r31) > 0x0000000010000d80 <+28>: li r3,8 > 0x0000000010000d84 <+32>: bl 0x100007a0 = <00000018.plt_call.__cxa_allocate_exception@@CXXABI_1.3> > 0x0000000010000d88 <+36>: ld r2,40(r1) > 0x0000000010000d8c <+40>: std r3,112(r31) > 0x0000000010000d90 <+44>: bl 0x10000e00 = > 0x0000000010000d94 <+48>: nop > 0x0000000010000d98 <+52>: ld r4,-32728(r2) > 0x0000000010000d9c <+56>: nop > 0x0000000010000da0 <+60>: ld r5,-32720(r2) > 0x0000000010000da4 <+64>: ld r3,112(r31) > 0x0000000010000da8 <+68>: bl 0x10000800 = <00000018.plt_call.__cxa_throw@@CXXABI_1.3> > 0x0000000010000dac <+72>: ld r2,40(r1) > 0x0000000010000db0 <+76>: b 0x10000df4 > 0x0000000010000db4 <+80>: mr r5,r4 > 0x0000000010000db8 <+84>: std r3,136(r31) > 0x0000000010000dbc <+88>: stw r5,132(r31) > 0x0000000010000dc0 <+92>: b 0x10000dc4 > 0x0000000010000dc4 <+96>: ld r3,136(r31) > 0x0000000010000dc8 <+100>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> > 0x0000000010000dcc <+104>: ld r2,40(r1) > 0x0000000010000dd0 <+108>: std r3,120(r31) > 0x0000000010000dd4 <+112>: bl 0x100007e0 = <00000018.plt_call.__cxa_end_catch@@CXXABI_1.3> > 0x0000000010000dd8 <+116>: ld r2,40(r1) > 0x0000000010000ddc <+120>: li r3,0 > 0x0000000010000de0 <+124>: addi r1,r1,160 > 0x0000000010000de4 <+128>: ld r0,16(r1) > 0x0000000010000de8 <+132>: ld r31,-8(r1) > 0x0000000010000dec <+136>: mtlr r0 > 0x0000000010000df0 <+140>: blr > 0x0000000010000df4 <+144>: .long 0x0 > 0x0000000010000df8 <+148>: .long 0x0 > 0x0000000010000dfc <+152>: .long 0x0 > End of assembler dump. >=20 > Notably lr seems to be: 0x10000dcc which > is just after: >=20 > bl 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >=20 > Note also the pc, r12, and ctr all having the failure > address: 0x81042b900 . >=20 > #0 0x000000081042b900 in ?? () from /lib/libc.so.7 > (gdb) x/32i 0x000000081042b8F0 > 0x81042b8f0 : .long 0x8 > 0x81042b8f4 : vmrglh v1,v30,v7 > 0x81042b8f8: .long 0x8 > 0x81042b8fc: vsubeuqm v1,v30,v7,v17 > =3D> 0x81042b900: .long 0x8 > 0x81042b904: vpmsumw v1,v30,v7 > 0x81042b908 <_citrus_bcs_skip_ws_len@got.plt>: .long 0x8 > 0x81042b90c <_citrus_bcs_skip_ws_len@got.plt+4>: .long 0x103e3c92 > 0x81042b910: .long 0x8 > 0x81042b914: .long 0x103e3c9b > 0x81042b918: .long 0x8 >=20 > (gdb) info reg > r0 0x810563d10 34633825552 > r1 0x3fffffffffffd980 4611686018427378048 > r2 0x0 0 > r3 0x810043060 34628448352 > r4 0x1 1 > r5 0x1 1 > r6 0x8103d9490 34632209552 > r7 0x0 0 > r8 0x29 41 > r9 0x4e 78 > r10 0x3fffffffffffc8f8 4611686018427373816 > r11 0x81056c28c 34633859724 > r12 0x81042b900 34632546560 > r13 0x81005f020 34628562976 > r14 0x0 0 > r15 0x0 0 > r16 0x0 0 > r17 0x0 0 > r18 0x0 0 > r19 0x0 0 > r20 0x0 0 > r21 0x0 0 > r22 0x0 0 > r23 0x0 0 > r24 0x0 0 > r25 0x0 0 > r26 0x0 0 > r27 0x0 0 > r28 0x1 1 > r29 0x3fffffffffffdb78 4611686018427378552 > r30 0x3fffffffffffdb88 4611686018427378568 > r31 0x3fffffffffffd980 4611686018427378048 > pc 0x81042b900 0x81042b900 > msr > cr 0x28000802 671090690 > lr 0x10000dcc 0x10000dcc > ctr 0x81042b900 34632546560 > xer 0x0 0 > fpscr 0x0 0 > vscr > vrsave >=20 > And the following shows how r12 and ctr were filled in by > code that expected r2 to be correct: >=20 > (gdb) x/32i 0x100007c0 > 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) > 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) > 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 > 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) > 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) > 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr > 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 > 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 > . . . >=20 > Overall: r2 seem to be mishandled in the exception handling. Just before: 0x0000000010000dc8 <+100>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> (gdb) set $r2=3D0x10019300 (gdb) c Continuing. Program exited normally. r2 has the wrong value and needs to have been set by: ld r2,40(r1) (expressed as an additional instruction in teh prelude to bl 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>) That shows how I got the 0x10019300 value as well: 40(r1) lookup. This makes the optimized code interesting because it had the "ld r2,40(r1)" but it was skipped by that code being started at 0x0000000010000dac . 0x0000000010000da8 <+68>: ld r2,40(r1) 0x0000000010000dac <+72>: bl 0x100007c0 = <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> (An earlier message of this sequence has more detail for the optimized code.) > Note on the gdb use: >=20 > The above devel/gdb activity was executed from a > devel/powerpc64-xtoolchain-gcc built world that was based on > WITHOUT_LLVM_LIBUNWIND=3D and and my patched libgcc_s material. > This means it suffered from mismatches with the clang/libunwind > world (that I chroot to): >=20 > QUOTE > warning: .dynamic section for "/usr/lib/libc++.so.1" is not at the = expected address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libcxxrt.so.1" is not at the = expected address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libm.so.5" is not at the expected = address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libc.so.7" is not at the expected = address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the = expected address (wrong library or version mismatch?) >=20 > warning: .dynamic section for "/libexec/ld-elf.so.1" is not at the = expected address (wrong library or version mismatch?) > END QUOTE >=20 > But any thrown exceptions the gdb may have used worked in my > patched WITHOUT_LLVM_LIBUNWIND=3D environment. This gdb is not > limited to dwarf-2. >=20 > The material from the a.out is not misinterpreted even if > library code details might be. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Mar 13 05:08:33 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B5E61525409 for ; Wed, 13 Mar 2019 05:08:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55FB395A85 for ; Wed, 13 Mar 2019 05:08:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oMKI.N4VM1m80RvEaSPy4EcyzDfRQ4V.3ktvKOKzbRCco6OjEJdzrtIb3gvpKUz 8DLHgDQNaCpbjiZ0YOyKfuBQDykt9Hh723GNGHcB4aa00rYOcXUQJTjKHKjraFYpGf8Yeta7kePt ciGtyXoXU7ZSKiuiTsmfkADPmrbRteW.BDpNpEOHe3XN6cY2SHPRQMRcQYBaq2ad0mp049XaruwZ USIod2jOiHiR_ryPInTOplP1byyvXFy62S.LluOdEe9EGHKel28ABwZ9ek.P1KaQZPLfnW2Cs4Hp IYia_Mp6Yb.fnUVRI6MPoTYXABIaib9PGJRr.Yi292xBJG4D4P.9.LI_4RvsOpv601PVdTNbWyhq lWrQZQlw4kFxzcBmYQz9qvt_abUkO.UKI7Ao_AiM_moYUsP459EFAxaWooQ_2x.jXGu3sXXHKcPK wLRobQEMLL6n4SoLhibRS4dSpLiAZ.XavR4aYg02jbH9uY1A6j9pOzHMBHVbb0VQ8JGIyWb8KvOe JbyU7iaqWKNxJfq4SbYzjee.CMB6Dw_Q_DffuaMl033k4NMx_CSR.7R8NM2dfylo1l4stLBuYJTy yoCCLixW2HgXLnyPXNuP93tSzGOTX0KMvBfOiar_lOmI5Jg0E.eUIRkdmq1t7vl.6gq1EUvr5kRN .KyM0sMjsP757dBJEA2NZlEqwvOKadCih20MsyARvXhjOS.aanolfhNJV.GfU_6vfuYVsBM4cYtb I118qfaIvehJSxhsxb5iDm0161Ti9DlEuqLfFIoCmj_7Njjua95DgY7B7wCRZH_cyz3aJjVY0RgQ DdJb3xaP.oaUDcjpGyvOpQyCpMel2QJTUUUA7vaP893jLg0L_BL63fGZRlD6qZIkQWyUFHyywK5J sEzYb44BTXbCAOFq1U33x5EBKQBB0X3ncOXpLlElY3xZiRYy3yuQlOJpKmvx8rseABVj2Sx5Wsle .WytxpQX9nj.b30uZ8Fr0hpI.eJ7o1E17xyHzoGGnvYp9X1khwUbHf6XXJyYB44GmqMQmCz6cn7R pgJ2gIE1NhKU7JzAHzzfPHc1c7u0VJ4aT7F5W74wQxq5s5SG8HSvD0bavbTjU2EIWMBt0o59Qc9P 0Gb6K_0op Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 13 Mar 2019 05:08:25 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6c98a8c6421053bf4a99aad6b4df2756; Wed, 13 Mar 2019 05:08:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Message-Id: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> Date: Tue, 12 Mar 2019 22:08:20 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 55FB395A85 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.476,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.84)[0.836,0]; NEURAL_HAM_LONG(-0.87)[-0.870,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.49)[ip: (0.77), ipnet: 98.137.64.0/21(0.98), asn: 36647(0.79), country: US(-0.07)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.69.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 05:08:33 -0000 I have submitted: https://bugs.llvm.org//show_bug.cgi?id=3D41050 for the clang 8 code generation problem of no code for setting r2 appropriately before the: bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> in unoptimized code ( no -O ). For the -O2 code: ld r2,40(r1) is present but is being skipped by the libunwind return to the code: it returns to the just-following bl instruction (like above) instead. In both cases: (gdb) x/32i 0x100007c0 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: std = r2,40(r1) 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 . . . with an inappropriate r2 value leads to jumping to inappropriate places. The example source code was: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } Note: This is from investigations of head -r345044 using WITH_LLVM_LIBUNWIND=3D on powerpc64. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Mar 13 11:57:45 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AC79152FE32 for ; Wed, 13 Mar 2019 11:57:45 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5353741ED for ; Wed, 13 Mar 2019 11:57:44 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9DFD21A5C7; Wed, 13 Mar 2019 12:57:36 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLXFTp2kQrXg; Wed, 13 Mar 2019 12:57:36 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 1776F1A5C6 for ; Wed, 13 Mar 2019 12:57:36 +0100 (CET) To: FreeBSD Toolchain From: Willem Jan Withagen Subject: Is this a programming error, or a compiler error.. Message-ID: Date: Wed, 13 Mar 2019 12:57:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: nl X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 11:57:45 -0000 Hi, I'm getting a crash in a Ceph test program in the following pice of code: struct entity_addrvec_t {   vector v; .....   entity_addr_t legacy_addr() const {     for (auto& a : v) {       if (a.type == entity_addr_t::TYPE_LEGACY) {         return a;       }     }     return entity_addr_t();   } ...... Where the loop is taken, even if v.size() == 0 So v content is pointing to random memory and itterating over the next pointer results in a crash. I would expect the loop not to be executed.... --WjW From owner-freebsd-toolchain@freebsd.org Wed Mar 13 12:17:07 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 772451531884 for ; Wed, 13 Mar 2019 12:17:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 108F975232 for ; Wed, 13 Mar 2019 12:17:07 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.1.32] (92-111-45-98.static.v4.ziggozakelijk.nl [92.111.45.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E3485577B9; Wed, 13 Mar 2019 13:17:05 +0100 (CET) From: Dimitry Andric Message-Id: <98EFC560-16A0-4F62-892A-64B15B21AF21@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_0A0E58B5-10EF-4886-BA3E-B70D8DCFD5EF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Is this a programming error, or a compiler error.. Date: Wed, 13 Mar 2019 13:17:05 +0100 In-Reply-To: Cc: FreeBSD Toolchain To: Willem Jan Withagen References: X-Mailer: Apple Mail (2.3445.102.3) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 12:17:07 -0000 --Apple-Mail=_0A0E58B5-10EF-4886-BA3E-B70D8DCFD5EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Mar 2019, at 12:57, Willem Jan Withagen wrote: >=20 > I'm getting a crash in a Ceph test program in the following pice of = code: >=20 > struct entity_addrvec_t { > vector v; > ..... > entity_addr_t legacy_addr() const { > for (auto& a : v) { > if (a.type =3D=3D entity_addr_t::TYPE_LEGACY) { > return a; > } > } > return entity_addr_t(); > } > ...... >=20 > Where the loop is taken, even if v.size() =3D=3D 0 > So v content is pointing to random memory and itterating over the next = pointer results in a crash. This can happen when the vector is invalidated, due to either it, or its parent object having been moved from. Maybe run this under valgrind or AddressSanitizer, that should give some more clues. -Dimitry --Apple-Mail=_0A0E58B5-10EF-4886-BA3E-B70D8DCFD5EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXIj0wQAKCRCwXqMKLiCW ozqNAKCdU6u26/t8zJLS6lt9XN6rhNMuAQCcD0aDm8mbqvYO0GvUu7gQl6EKZak= =1mrP -----END PGP SIGNATURE----- --Apple-Mail=_0A0E58B5-10EF-4886-BA3E-B70D8DCFD5EF-- From owner-freebsd-toolchain@freebsd.org Wed Mar 13 13:11:53 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4815515330BF for ; Wed, 13 Mar 2019 13:11:53 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B02B8770B0; Wed, 13 Mar 2019 13:11:52 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 66EBB30BB3; Wed, 13 Mar 2019 14:11:51 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ollh8Q3tkQcw; Wed, 13 Mar 2019 14:11:50 +0100 (CET) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 9966A30BAC; Wed, 13 Mar 2019 14:11:50 +0100 (CET) Subject: Re: Is this a programming error, or a compiler error.. To: Dimitry Andric Cc: FreeBSD Toolchain References: <98EFC560-16A0-4F62-892A-64B15B21AF21@FreeBSD.org> From: Willem Jan Withagen Message-ID: <9c822acb-01be-2579-f181-34b97d8417d3@digiware.nl> Date: Wed, 13 Mar 2019 14:11:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <98EFC560-16A0-4F62-892A-64B15B21AF21@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: nl X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:11:53 -0000 On 13-3-2019 13:17, Dimitry Andric wrote: > On 13 Mar 2019, at 12:57, Willem Jan Withagen wrote: >> I'm getting a crash in a Ceph test program in the following pice of code: >> >> struct entity_addrvec_t { >> vector v; >> ..... >> entity_addr_t legacy_addr() const { >> for (auto& a : v) { >> if (a.type == entity_addr_t::TYPE_LEGACY) { >> return a; >> } >> } >> return entity_addr_t(); >> } >> ...... >> >> Where the loop is taken, even if v.size() == 0 >> So v content is pointing to random memory and itterating over the next pointer results in a crash. > This can happen when the vector is invalidated, due to either it, or its > parent object having been moved from. Maybe run this under valgrind or > AddressSanitizer, that should give some more clues. Would be new tricks for me... I'll look into it. Prefixing the loop with `if (!empy())` fixes the runtime problem, and this is a single thread program So there is no other thread here that could work on the vector and corrupt it while looping over it. --WjW From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:05:54 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 172581535EF8; Wed, 13 Mar 2019 15:05:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 09A1C831B0; Wed, 13 Mar 2019 15:05:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DF5n13034668 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 08:05:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DF5nXT034667; Wed, 13 Mar 2019 08:05:49 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 08:05:49 -0700 From: Steve Kargl To: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313150548.GA34658@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313024506.GA31746@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 09A1C831B0 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.92 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.68)[0.679,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[washington.edu]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.60)[0.598,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.93)[0.932,0]; R_SPF_NA(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.09), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:05:54 -0000 On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > All, > > There seems to an optimization bug with clang on > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 > > IOW, if you do numerica work on i386, you may want to check your > results. > > The program demonstrating the issue is at the end of this email. > > gcc8 --version > gcc8 (FreeBSD Ports Collection) 8.3.0 > > gcc8 -fno-builtin -o z a.c -lm && ./z > gcc8 -O -fno-builtin -o z a.c -lm && ./z > gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > > Max ULP: 2.297073 > Count: 0 (# of ULP that exceed 21) > The above results do not change if one add -ffloat-store to the command line. > cc -O -fno-builtin -o z a.c -lm && ./z > cc -O2 -fno-builtin -o z a.c -lm && ./z > cc -O3 -fno-builtin -o z a.c -lm && ./z > > Max ULP: 23.061242 > Count: 39 (# of ULP that exceeds 21) Clang doesn't support -ffloat-store, so the above does not change. -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:08:56 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67A7A153604C; Wed, 13 Mar 2019 15:08:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B9BE83423; Wed, 13 Mar 2019 15:08:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DF8sxA034706 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 08:08:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DF8ssk034705; Wed, 13 Mar 2019 08:08:54 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 08:08:54 -0700 From: Steve Kargl To: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313150854.GB34658@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313024506.GA31746@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 9B9BE83423 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.89 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.66)[0.665,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[washington.edu]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.58)[0.584,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; REPLYTO_ADDR_EQ_FROM(0.00)[]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.93)[0.926,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:08:56 -0000 On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > cc -O -fno-builtin -o z a.c -lm && ./z > cc -O2 -fno-builtin -o z a.c -lm && ./z > cc -O3 -fno-builtin -o z a.c -lm && ./z > > > Max ULP: 23.061242 > Count: 39 (# of ULP that exceeds 21) > These results do not change if one uses /usr/local/bin/clang60. -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:16:38 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4D6E1536514; Wed, 13 Mar 2019 15:16:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8805383B47; Wed, 13 Mar 2019 15:16:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DFGZSC034767 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 08:16:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DFGZNs034766; Wed, 13 Mar 2019 08:16:35 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 08:16:35 -0700 From: Steve Kargl To: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313151635.GA34757@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313024506.GA31746@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 8805383B47 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.86 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.65)[0.648,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[washington.edu]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.58)[0.579,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.92)[0.923,0]; R_SPF_NA(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:16:38 -0000 On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > gcc8 --version > gcc8 (FreeBSD Ports Collection) 8.3.0 > > gcc8 -fno-builtin -o z a.c -lm && ./z > gcc8 -O -fno-builtin -o z a.c -lm && ./z > gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > > Max ULP: 2.297073 > Count: 0 (# of ULP that exceed 21) > clang agrees with gcc8 if one changes ... > int > main(void) > { > double re, im, u, ur, ui; > float complex f; > float x, y; this line to "volatile float x, y". -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:42:18 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7686615372E9; Wed, 13 Mar 2019 15:42:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B53584E8E; Wed, 13 Mar 2019 15:42:17 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 78E84260306; Wed, 13 Mar 2019 16:42:15 +0100 (CET) Subject: Re: Optimization bug with floating-point? To: sgk@troutmask.apl.washington.edu, freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: <14ead2c2-b586-309d-947f-1395b5284dd1@selasky.org> Date: Wed, 13 Mar 2019 16:41:51 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190313151635.GA34757@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9B53584E8E X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.43 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[selasky.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.91)[-0.907,0]; IP_SCORE(-3.21)[ip: (-9.45), ipnet: 88.99.0.0/16(-4.66), asn: 24940(-1.94), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:42:18 -0000 On 3/13/19 4:16 PM, Steve Kargl wrote: > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: >> >> gcc8 --version >> gcc8 (FreeBSD Ports Collection) 8.3.0 >> >> gcc8 -fno-builtin -o z a.c -lm && ./z >> gcc8 -O -fno-builtin -o z a.c -lm && ./z >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z >> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z >> >> Max ULP: 2.297073 >> Count: 0 (# of ULP that exceed 21) >> > > clang agrees with gcc8 if one changes ... > >> int >> main(void) >> { >> double re, im, u, ur, ui; >> float complex f; >> float x, y; > > this line to "volatile float x, y". > Can you try to use: #define sincos(x,p,q) do { \ *(p) = sin(x); \ *(q) = cos(x); \ } while (0) Instead of libm's sincos(). Might be a bug in there. --HPS From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:50:13 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 437F515377B0; Wed, 13 Mar 2019 15:50:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E03CF856FC; Wed, 13 Mar 2019 15:50:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DFo9lG034951 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 08:50:09 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DFo9qJ034950; Wed, 13 Mar 2019 08:50:09 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 08:50:09 -0700 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313155009.GA34852@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <14ead2c2-b586-309d-947f-1395b5284dd1@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14ead2c2-b586-309d-947f-1395b5284dd1@selasky.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: E03CF856FC X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.99 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.72)[0.724,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.92)[0.921,0]; NEURAL_SPAM_MEDIUM(0.63)[0.628,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:50:13 -0000 On Wed, Mar 13, 2019 at 04:41:51PM +0100, Hans Petter Selasky wrote: > On 3/13/19 4:16 PM, Steve Kargl wrote: > > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >> > >> gcc8 --version > >> gcc8 (FreeBSD Ports Collection) 8.3.0 > >> > >> gcc8 -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > >> > >> Max ULP: 2.297073 > >> Count: 0 (# of ULP that exceed 21) > >> > > > > clang agrees with gcc8 if one changes ... > > > >> int > >> main(void) > >> { > >> double re, im, u, ur, ui; > >> float complex f; > >> float x, y; > > > > this line to "volatile float x, y". > > > > Can you try to use: > > #define sincos(x,p,q) do { \ > *(p) = sin(x); \ > *(q) = cos(x); \ > } while (0) > > > Instead of libm's sincos(). Might be a bug in there. > Using sin() and cos() directly as in /* Double precision csinh() without using C's double complex.s */ void dp_csinh(double x, double y, double *re, double *im) { double c, s; *re = sinh(x) * cos(y); *im = cosh(x) * sin(y); } does not change the result. I'll also note that libm is compiled by clang, and I do not recompile it for the tests. Both gcc8 and cc are using the same libm. I've also tested clang of amd64 with the -m32, it fails as well. -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:54:32 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22EA41537B79 for ; Wed, 13 Mar 2019 15:54:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AAF3085D9A for ; Wed, 13 Mar 2019 15:54:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6B8511537B78; Wed, 13 Mar 2019 15:54:31 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58F881537B77 for ; Wed, 13 Mar 2019 15:54:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4B2485D95 for ; Wed, 13 Mar 2019 15:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1DF151D3D2 for ; Wed, 13 Mar 2019 15:54:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2DFsT3U038654 for ; Wed, 13 Mar 2019 15:54:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2DFsTGb038653 for toolchain@FreeBSD.org; Wed, 13 Mar 2019 15:54:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236313] graphics/opencollada: excessive build time with clang 8 on i386 Date: Wed, 13 Mar 2019 15:54:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:54:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236313 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Wed Mar 13 15:54:15 UTC 2019 New revision: 495589 URL: https://svnweb.freebsd.org/changeset/ports/495589 Log: graphics/opencollada: back out r494777 after base r345021 PR: 236313 Changes: head/graphics/opencollada/files/patch-clang8 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Mar 13 15:56:54 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56D5E1537CAC; Wed, 13 Mar 2019 15:56:54 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5274E85EAA; Wed, 13 Mar 2019 15:56:53 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2ACB4260306; Wed, 13 Mar 2019 16:56:50 +0100 (CET) Subject: Re: Optimization bug with floating-point? To: sgk@troutmask.apl.washington.edu Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <14ead2c2-b586-309d-947f-1395b5284dd1@selasky.org> <20190313155009.GA34852@troutmask.apl.washington.edu> From: Hans Petter Selasky Message-ID: Date: Wed, 13 Mar 2019 16:56:26 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190313155009.GA34852@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5274E85EAA X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; IP_SCORE(-2.57)[ip: (-8.71), ipnet: 2a01:4f8::/29(-2.18), asn: 24940(-1.94), country: DE(-0.01)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.turbocat.net]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 15:56:54 -0000 On 3/13/19 4:50 PM, Steve Kargl wrote: > Using sin() and cos() directly as in > > /* Double precision csinh() without using C's double complex.s */ > void > dp_csinh(double x, double y, double *re, double *im) > { > double c, s; > *re = sinh(x) * cos(y); > *im = cosh(x) * sin(y); > } > > does not change the result. I'll also note that libm > is compiled by clang, and I do not recompile it for the > tests. Both gcc8 and cc are using the same libm. > > I've also tested clang of amd64 with the -m32, it fails > as well. Hi, I cannot see this is failing with 11-stable userland. Can you check with objdump() that clang doesn't optimise it to sincos() ? FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) Target: x86_64-unknown-freebsd11.0 Thread model: posix InstalledDir: /usr/bin cc -lm -O2 -Wall test.c && ./a.out Max ULP: 2.297073 Count: 0 clang40 -lm -O2 test6.c > ./a.out Max ULP: 2.297073 Count: 0 clang50 -lm -O2 test6.c > ./a.out Max ULP: 2.297073 Count: 0 clang60 -lm -O2 test6.c > ./a.out Max ULP: 2.297073 Count: 0 --HPS From owner-freebsd-toolchain@freebsd.org Wed Mar 13 16:13:43 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49CB01538898; Wed, 13 Mar 2019 16:13:43 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4DE0878D1; Wed, 13 Mar 2019 16:13:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DGDQCX035176 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 09:13:26 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DGDQjN035171; Wed, 13 Mar 2019 09:13:26 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 09:13:26 -0700 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313161326.GA35122@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <14ead2c2-b586-309d-947f-1395b5284dd1@selasky.org> <20190313155009.GA34852@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: D4DE0878D1 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.66 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.41)[0.406,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.92)[0.915,0]; NEURAL_SPAM_MEDIUM(0.63)[0.628,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 16:13:43 -0000 On Wed, Mar 13, 2019 at 04:56:26PM +0100, Hans Petter Selasky wrote: > On 3/13/19 4:50 PM, Steve Kargl wrote: > > Using sin() and cos() directly as in > > > > /* Double precision csinh() without using C's double complex.s */ > > void > > dp_csinh(double x, double y, double *re, double *im) > > { > > double c, s; > > *re = sinh(x) * cos(y); > > *im = cosh(x) * sin(y); > > } > > > > does not change the result. I'll also note that libm > > is compiled by clang, and I do not recompile it for the > > tests. Both gcc8 and cc are using the same libm. > > > > I've also tested clang of amd64 with the -m32, it fails > > as well. > > Hi, > > I cannot see this is failing with 11-stable userland. Can you check with > objdump() that clang doesn't optimise it to sincos() ? It doesn't. % nm z | grep sin U csinhf 00401360 T dp_csinh U sin U sinh > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) > Target: x86_64-unknown-freebsd11.0 The test does not fail on x86_64 unless you add the -m32 option, which forces i386 behavior. cc --version FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) Target: x86_64-unknown-freebsd13.0 cc -fno-builtin -O2 -o z a.c -lm && ./z Max u: 2.297073 Count: 0 cc -fno-builtin -O2 -o z a.c -lm -m32 && ./z Max u: 23.061242 Count: 39 > Thread model: posix > InstalledDir: /usr/bin > > cc -lm -O2 -Wall test.c && ./a.out > Max ULP: 2.297073 > Count: 0 add -m32. > > clang40 -lm -O2 test6.c > > ./a.out > Max ULP: 2.297073 > Count: 0 > > clang50 -lm -O2 test6.c > > ./a.out > Max ULP: 2.297073 > Count: 0 > > clang60 -lm -O2 test6.c > > ./a.out > Max ULP: 2.297073 > Count: 0 -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 16:33:00 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0338A15390F5; Wed, 13 Mar 2019 16:33:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D1318881C; Wed, 13 Mar 2019 16:32:59 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id EE5709D89; Wed, 13 Mar 2019 16:32:58 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Optimization bug with floating-point? To: sgk@troutmask.apl.washington.edu, freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Wed, 13 Mar 2019 09:32:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190313151635.GA34757@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5D1318881C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 16:33:00 -0000 On 3/13/19 8:16 AM, Steve Kargl wrote: > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: >> >> gcc8 --version >> gcc8 (FreeBSD Ports Collection) 8.3.0 >> >> gcc8 -fno-builtin -o z a.c -lm && ./z >> gcc8 -O -fno-builtin -o z a.c -lm && ./z >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z >> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z >> >> Max ULP: 2.297073 >> Count: 0 (# of ULP that exceed 21) >> > > clang agrees with gcc8 if one changes ... > >> int >> main(void) >> { >> double re, im, u, ur, ui; >> float complex f; >> float x, y; > > this line to "volatile float x, y". So it seems to be a regression in clang 7 vs clang 6? -- John Baldwin From owner-freebsd-toolchain@freebsd.org Wed Mar 13 16:40:42 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 857431539352; Wed, 13 Mar 2019 16:40:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5961088BFF; Wed, 13 Mar 2019 16:40:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DGedNc035350 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 09:40:39 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DGedaR035349; Wed, 13 Mar 2019 09:40:39 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 09:40:39 -0700 From: Steve Kargl To: John Baldwin Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313164039.GA35340@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 5961088BFF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.83 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.64)[0.636,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.86)[0.855,0]; NEURAL_SPAM_MEDIUM(0.62)[0.622,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 16:40:42 -0000 On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > On 3/13/19 8:16 AM, Steve Kargl wrote: > > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >> > >> gcc8 --version > >> gcc8 (FreeBSD Ports Collection) 8.3.0 > >> > >> gcc8 -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > >> > >> Max ULP: 2.297073 > >> Count: 0 (# of ULP that exceed 21) > >> > > > > clang agrees with gcc8 if one changes ... > > > >> int > >> main(void) > >> { > >> double re, im, u, ur, ui; > >> float complex f; > >> float x, y; > > > > this line to "volatile float x, y". > > So it seems to be a regression in clang 7 vs clang 6? > /usr/local/bin/clang60 has the same problem. % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z Maximum ULP: 23.061242 # of ULP > 21: 39 Adding volatile as in the above "fixes" the problem. AFAICT, this a i386/387 code generation problem. Perhaps, an alignment issue? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-toolchain@freebsd.org Wed Mar 13 17:16:14 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8631C153A785; Wed, 13 Mar 2019 17:16:14 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3B7F8AADF; Wed, 13 Mar 2019 17:16:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 5009DA1E8; Wed, 13 Mar 2019 17:16:13 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Optimization bug with floating-point? To: sgk@troutmask.apl.washington.edu Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Wed, 13 Mar 2019 10:16:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190313164039.GA35340@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E3B7F8AADF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 17:16:14 -0000 On 3/13/19 9:40 AM, Steve Kargl wrote: > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: >> On 3/13/19 8:16 AM, Steve Kargl wrote: >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: >>>> >>>> gcc8 --version >>>> gcc8 (FreeBSD Ports Collection) 8.3.0 >>>> >>>> gcc8 -fno-builtin -o z a.c -lm && ./z >>>> gcc8 -O -fno-builtin -o z a.c -lm && ./z >>>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z >>>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z >>>> >>>> Max ULP: 2.297073 >>>> Count: 0 (# of ULP that exceed 21) >>>> >>> >>> clang agrees with gcc8 if one changes ... >>> >>>> int >>>> main(void) >>>> { >>>> double re, im, u, ur, ui; >>>> float complex f; >>>> float x, y; >>> >>> this line to "volatile float x, y". >> >> So it seems to be a regression in clang 7 vs clang 6? >> > > /usr/local/bin/clang60 has the same problem. > > % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z > Maximum ULP: 23.061242 > # of ULP > 21: 39 > > Adding volatile as in the above "fixes" the problem. > > AFAICT, this a i386/387 code generation problem. Perhaps, > an alignment issue? Oh, I misread your earlier e-mail to say that clang60 worked. One issue I'm aware of is that clang does not have any support for the special arrangement FreeBSD/i386 uses where it uses different precision for registers vs in-memory for some of the floating point types (GCC has a special hack that is only used on FreeBSD for this but isn't used on any other OS's). I wonder if that could be a factor? Volatile probably forces a round trip between memory which might explain why this is the case. I wonder what your test program does on i386 Linux with GCC? -- John Baldwin From owner-freebsd-toolchain@freebsd.org Wed Mar 13 17:40:42 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24161153B0BB; Wed, 13 Mar 2019 17:40:42 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 494DD8B865; Wed, 13 Mar 2019 17:40:41 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f171.google.com with SMTP id h9so219312itl.1; Wed, 13 Mar 2019 10:40:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=QXm80K82s/MMlZ5c23ttFg7MBDmKAlUau6b+lOSB0Ns=; b=W2e3SR4riGs5lyq2weh3ARMuYmr8BZfsPid2zGQvkxxY6pQ9uWiBVXirE1Lo4C48+s OXpcbnHbnRIDRSBveWIRr6Zw2fL/Humg/lY0q0m/rLpGVpVyol07y5zxMHnDG5BDYt78 3z26qvvxViqN5nTlfEIpUBYcgt7os95QCblPW0RW8uB94jlQqdV9kp3aHWm3ZXSRftJF usnPANPzOeHc2A5fQ1m7t32I7yjGmIrHvxYrGL7xAzFvT0d/a2qtKzt+WJ3RsNeBLe3C YxVDK1Az5NvGE5lMdX/Kp3eViQ6//zAoWtG0W2ieFqHqQTdkK5T46xW05nKs2QnqIXpy mLQw== X-Gm-Message-State: APjAAAViiQ5gfxDNX1tGbJsJmtclR+Uej9cUTAy9VdHy6nvCHZ2WqZrQ xnwK1hXBU/9hyY3kIaZMkgzcHz++ X-Google-Smtp-Source: APXvYqyPzgFbytf0kzDF/7QVGz2ECOukGPpB6x1yQjMAaPoRr06NQ67WUhaEmfHP/zIjZdfL5OAPfg== X-Received: by 2002:a02:9101:: with SMTP id a1mr12194104jag.50.1552498839718; Wed, 13 Mar 2019 10:40:39 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com. [209.85.166.43]) by smtp.gmail.com with ESMTPSA id t62sm1442353ita.35.2019.03.13.10.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 10:40:39 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id f6so2471496iop.3; Wed, 13 Mar 2019 10:40:39 -0700 (PDT) X-Received: by 2002:a6b:6007:: with SMTP id r7mr23431791iog.124.1552498839214; Wed, 13 Mar 2019 10:40:39 -0700 (PDT) MIME-Version: 1.0 References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 13 Mar 2019 10:40:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Optimization bug with floating-point? To: John Baldwin Cc: "freebsd-toolchain@FreeBSD.org" , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 494DD8B865 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.171 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.62 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.89)[-0.888,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[171.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.73)[ip: (-7.60), ipnet: 209.85.128.0/17(-3.88), asn: 15169(-2.08), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 17:40:42 -0000 Hi John, On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote: > One issue I'm aware of is that clang does not have any support for the > special arrangement FreeBSD/i386 uses where it uses different precision > for registers vs in-memory for some of the floating point types (GCC has > a special hack that is only used on FreeBSD for this but isn't used on > any other OS's). I wonder if that could be a factor? Volatile probably > forces a round trip between memory which might explain why this is the > case. > > I wonder what your test program does on i386 Linux with GCC? $ uname -sr Linux 4.20.4 $ gcc --version gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) ... $ rpm -qf /usr/lib/libm-2.27.so glibc-2.27-37.fc28.i686 $ gcc -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: 1.959975 Count: 0 $ gcc -O -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: 1.959975 Count: 0 $ gcc -O1 -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: 1.959975 Count: 0 $ gcc -O2 -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: nan Count: 0 $ gcc -O3 -m32 -fno-builtin -o z kargl.c -lm && ./z Max ULP: nan Count: 0 Uh. kargl.c: In function =E2=80=98main=E2=80=99: kargl.c:80:10: warning: =E2=80=98u=E2=80=99 may be used uninitialized in th= is function [-Wmaybe-uninitialized] if (ur > u) u =3D ur; ^ If I initialize 'u' (to, e.g., -1e52), I get: Max ULP: 1.959975 Count: 0 at -O2 and -O3 as well. Best, Conrad From owner-freebsd-toolchain@freebsd.org Wed Mar 13 18:08:12 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D1D5153C11C; Wed, 13 Mar 2019 18:08:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C36028D250; Wed, 13 Mar 2019 18:08:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DI86bd036009 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 11:08:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DI86sQ036008; Wed, 13 Mar 2019 11:08:06 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 11:08:06 -0700 From: Steve Kargl To: John Baldwin Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313180806.GA35586@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: C36028D250 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.13 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.78)[0.782,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.94)[0.942,0]; NEURAL_SPAM_MEDIUM(0.69)[0.691,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 18:08:12 -0000 On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > On 3/13/19 9:40 AM, Steve Kargl wrote: > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > >> On 3/13/19 8:16 AM, Steve Kargl wrote: > >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >>>> > >>>> gcc8 --version > >>>> gcc8 (FreeBSD Ports Collection) 8.3.0 > >>>> > >>>> gcc8 -fno-builtin -o z a.c -lm && ./z > >>>> gcc8 -O -fno-builtin -o z a.c -lm && ./z > >>>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > >>>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > >>>> > >>>> Max ULP: 2.297073 > >>>> Count: 0 (# of ULP that exceed 21) > >>>> > >>> > >>> clang agrees with gcc8 if one changes ... > >>> > >>>> int > >>>> main(void) > >>>> { > >>>> double re, im, u, ur, ui; > >>>> float complex f; > >>>> float x, y; > >>> > >>> this line to "volatile float x, y". > >> > >> So it seems to be a regression in clang 7 vs clang 6? > >> > > > > /usr/local/bin/clang60 has the same problem. > > > > % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z > > Maximum ULP: 23.061242 > > # of ULP > 21: 39 > > > > Adding volatile as in the above "fixes" the problem. > > > > AFAICT, this a i386/387 code generation problem. Perhaps, > > an alignment issue? > > Oh, I misread your earlier e-mail to say that clang60 worked. > > One issue I'm aware of is that clang does not have any support for the > special arrangement FreeBSD/i386 uses where it uses different precision > for registers vs in-memory for some of the floating point types (GCC has > a special hack that is only used on FreeBSD for this but isn't used on > any other OS's). I wonder if that could be a factor? Volatile probably > forces a round trip between memory which might explain why this is the > case. > > I wonder what your test program does on i386 Linux with GCC? I don't have an i386 Linux environment. I tried comparing the assembly generated with and without volatile, but it proves difficult as register numbers are changed between the 2 listings so almost all lines mismatch If I move ranged(), rangef(), dp_csinh(), and ulpfd() into b.c so a.c only contains main(), add appropriate prototypes to a.c, and comment out the printf() statements, I still see the problem. Judging from the diff, there is a difference in the spills and loads in 2 places. % diff -uw without_volatile with_volatile --- without_volatile 2019-03-13 10:51:33.244226000 -0700 +++ with_volatile 2019-03-13 10:51:54.088095000 -0700 @@ -35,11 +35,13 @@ movl %esi, 68(%esp) # 4-byte Spill calll rangef fadds .LCPI0_0 - fstpl 24(%esp) # 8-byte Folded Spill + fstps 28(%esp) calll rangef fadds .LCPI0_1 - fstl 100(%esp) # 8-byte Folded Spill - fldl 24(%esp) # 8-byte Folded Reload + fstps 24(%esp) + flds 28(%esp) + flds 24(%esp) + fxch %st(1) fstps 48(%esp) fstps 52(%esp) movl 48(%esp), %eax @@ -49,13 +51,13 @@ calll csinhf movl %eax, %esi movl %edx, %edi + flds 28(%esp) + flds 24(%esp) leal 72(%esp), %eax movl %eax, 20(%esp) leal 80(%esp), %eax movl %eax, 16(%esp) - fldl 100(%esp) # 8-byte Folded Reload fstpl 8(%esp) - fldl 24(%esp) # 8-byte Folded Reload fstpl (%esp) calll dp_csinh movl %esi, 40(%esp) @@ -75,7 +77,7 @@ fnstsw %ax # kill: def $ah killed $ah killed $ax sahf - fstl 24(%esp) # 8-byte Folded Spill + fstl 100(%esp) # 8-byte Folded Spill ja .LBB0_3 # %bb.2: # %for.body # in Loop: Header=BB0_1 Depth=1 @@ -114,7 +116,7 @@ # in Loop: Header=BB0_1 Depth=1 fstp %st(2) fldl 92(%esp) # 8-byte Folded Reload - fldl 24(%esp) # 8-byte Folded Reload + fldl 100(%esp) # 8-byte Folded Reload fucomp %st(1) fnstsw %ax # kill: def $ah killed $ah killed $ax Adding ieeefp.h to a.c and fpsetprec(FP_PE) in main() produces a massive diff, but still wrong results if volatile is not use. Clang appears to be broken for FP on i386/387. -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 18:16:26 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCF3A153C5C2; Wed, 13 Mar 2019 18:16:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 36DA48D8D7; Wed, 13 Mar 2019 18:16:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DIGN6e036104 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 11:16:23 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DIGNOP036103; Wed, 13 Mar 2019 11:16:23 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 11:16:23 -0700 From: Steve Kargl To: Conrad Meyer Cc: John Baldwin , "freebsd-toolchain@FreeBSD.org" , freebsd-current Subject: Re: Optimization bug with floating-point? Message-ID: <20190313181623.GA36061@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 36DA48D8D7 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.19 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; TO_DN_SOME(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.82)[0.817,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.71)[0.713,0]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.95)[0.948,0]; R_SPF_NA(0.00)[] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 18:16:26 -0000 On Wed, Mar 13, 2019 at 10:40:28AM -0700, Conrad Meyer wrote: > Hi John, > > On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote: > > One issue I'm aware of is that clang does not have any support for the > > special arrangement FreeBSD/i386 uses where it uses different precision > > for registers vs in-memory for some of the floating point types (GCC has > > a special hack that is only used on FreeBSD for this but isn't used on > > any other OS's). I wonder if that could be a factor? Volatile probably > > forces a round trip between memory which might explain why this is the > > case. > > > > I wonder what your test program does on i386 Linux with GCC? > > $ uname -sr > Linux 4.20.4 > $ gcc --version > gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) > ... > $ rpm -qf /usr/lib/libm-2.27.so > glibc-2.27-37.fc28.i686 > > $ gcc -m32 -fno-builtin -o z kargl.c -lm && ./z > Max ULP: 1.959975 > Count: 0 > $ gcc -O -m32 -fno-builtin -o z kargl.c -lm && ./z > Max ULP: 1.959975 > Count: 0 > $ gcc -O1 -m32 -fno-builtin -o z kargl.c -lm && ./z > Max ULP: 1.959975 > Count: 0 > $ gcc -O2 -m32 -fno-builtin -o z kargl.c -lm && ./z > Max ULP: nan > Count: 0 > $ gcc -O3 -m32 -fno-builtin -o z kargl.c -lm && ./z > Max ULP: nan > Count: 0 > > Uh. > > kargl.c: In function ‘main’: > kargl.c:80:10: warning: ‘u’ may be used uninitialized in this function > [-Wmaybe-uninitialized] > if (ur > u) u = ur; > ^ Whoops. There are a number of variations on a theme named a.c. Initializing u to 0 doesn't change the outcome with clang on FreeBSD. -- Steve From owner-freebsd-toolchain@freebsd.org Wed Mar 13 21:25:00 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E7611542508; Wed, 13 Mar 2019 21:25:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 31B8F711E5; Wed, 13 Mar 2019 21:24:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2DLOtWS037754 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 14:24:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2DLOtbU037753; Wed, 13 Mar 2019 14:24:55 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 14:24:55 -0700 From: Steve Kargl To: John Baldwin Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190313212455.GA37717@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 31B8F711E5 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.77 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.69)[0.691,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.95)[0.948,0]; NEURAL_SPAM_MEDIUM(0.42)[0.416,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 21:25:00 -0000 On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > On 3/13/19 9:40 AM, Steve Kargl wrote: > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > >> On 3/13/19 8:16 AM, Steve Kargl wrote: > >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >>>> > >>>> gcc8 --version > >>>> gcc8 (FreeBSD Ports Collection) 8.3.0 > >>>> > >>>> gcc8 -fno-builtin -o z a.c -lm && ./z > >>>> gcc8 -O -fno-builtin -o z a.c -lm && ./z > >>>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > >>>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > >>>> > >>>> Max ULP: 2.297073 > >>>> Count: 0 (# of ULP that exceed 21) > >>>> > >>> > >>> clang agrees with gcc8 if one changes ... > >>> > >>>> int > >>>> main(void) > >>>> { > >>>> double re, im, u, ur, ui; > >>>> float complex f; > >>>> float x, y; > >>> > >>> this line to "volatile float x, y". > >> > >> So it seems to be a regression in clang 7 vs clang 6? > >> > > > > /usr/local/bin/clang60 has the same problem. > > > > % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z > > Maximum ULP: 23.061242 > > # of ULP > 21: 39 > > > > Adding volatile as in the above "fixes" the problem. > > > > AFAICT, this a i386/387 code generation problem. Perhaps, > > an alignment issue? > > Oh, I misread your earlier e-mail to say that clang60 worked. > > One issue I'm aware of is that clang does not have any support for the > special arrangement FreeBSD/i386 uses where it uses different precision > for registers vs in-memory for some of the floating point types (GCC has > a special hack that is only used on FreeBSD for this but isn't used on > any other OS's). I wonder if that could be a factor? Volatile probably > forces a round trip between memory which might explain why this is the > case. > I went looking for this special hack. In gcc/gccx/config/i386, one finds /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the compiler get the contents of and std::numeric_limits correct. */ #undef TARGET_96_ROUND_53_LONG_DOUBLE #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) So, taking this as a hunch, I added ieeefp.h to my test program and called 'fpsetprec(FP_PD)' as the first executable statement. This then results in % cc -fno-builtin -m32 -O2 -o z b.o a.c -lm && ./z Max u: 2.297073 Count: 0 So, is there a way to correctly build clang for i386/387 to automatically set the precision correctly? -- Steve From owner-freebsd-toolchain@freebsd.org Thu Mar 14 02:14:16 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7C521522794 for ; Thu, 14 Mar 2019 02:14:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91A0183D5D for ; Thu, 14 Mar 2019 02:14:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 4dS44lUVM1nTR.xMPGSveJUpmWHbQdDxTpx7zBxDe1wxv_8D0LRbT5.iDq5vv0S NOfWexcv0FEfA9bfBmI_gl2YjkrJSyewlbKmo1EFudwteJtdhgXTxSsb3fkDayBJGkrlduuW2br_ aBQwIyOTy2j21mforYkLBN5bs48fhNhNAeP9IpMnn7juJ0SoZEWcxO7e1N3ccltHbO..QCa2qLtN MMyyWPna27AsRCEavc8ptWMJELmTD478M78OrVwp5FhfE7F99nGKXsErhLqfUvNyCrFNZ2ma9mf9 Bpd6Ozc5SL7m2zqlO.Mh3NMZLdZzhZc767LgiQQrPeiGHDOqdwhVOEmxyqOmjrxN4sMdRiTHI.o2 SPcgQdPjozmmwpV4cIAnjk1mI6f2iE0mGfLK_1.MyQzEiHe.JDlSQUI97AqYH1wOZxuBLVqtnpwz SUyl.qUTMKCfksVkhA9.6wl5QxgP6cbpOcJiJs.T4qJGSN3uqByuECdstYLkxgjZPNj41_fIWwji IUoexNnChsNcK0HFtgWU9oWOG9elUcLmbw56I28db9k2krxVvXUfiV5orD8k4mzQrCfDGzzcI_BQ UEdXM7C5_YXFalvxxCEupAQNb_zOBtg5m_LC6uOIANVOyt4nXNTYp5t8x77xumukLBtqwS_y17rV Xuvs2t0dZ96K473uBGFmRF7fbG7zctNk5BHjp2dlfKs_wDeM8sYOrIYyxwN5HlVcb8FSTshFFTXK V4_Cvxm4GmIyA7LEhmNdrUwBzulXOl_wpA9aTipK7kNjZhONKlpiO9J4Ao6CJBbwwU6WpvSh2fNE NaB8Dlcm5chn5RcvTinE1.Xzr81N8784fqOQbfuk1yA6TkpCJtJPDW7yuUNpx7SfbfVzQmtsss_X 1fNBumiJcmuKfjIDjI3YlvmjXcO_ZNjbu74Kk5GnToV95L9qvUgcuu71sVGoZsUSbNRXZqNuowFB r5CogOd_zYmwQI8MPi0TDTXBRDa0okRhczGwR2u8O5nqo_3HsKQCQ1SVx9duct4vcp8bk.rg19Qy CEWWvPcannOtkDWLA105x6bYeBTIZpf9RxmZ_7r4DDfTMY1RIikKK2jOKAcnNC.Qh10jggnzaTYz VRb.XJwBO_xKDn8Q- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 Mar 2019 02:14:08 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp421.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f7ff231413ab9d9143064498881ad737; Thu, 14 Mar 2019 02:14:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Date: Wed, 13 Mar 2019 19:14:01 -0700 References: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> To: FreeBSD Toolchain , FreeBSD PowerPC ML In-Reply-To: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> Message-Id: <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 91A0183D5D X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.93)[0.932,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.03)[ip: (2.65), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.14), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.52)[0.523,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.41)[0.412,0]; RCVD_IN_DNSWL_NONE(0.00)[125.131.6.74.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 02:14:16 -0000 On 2019-Mar-12, at 22:08, Mark Millard wrote: > I have submitted: >=20 > https://bugs.llvm.org//show_bug.cgi?id=3D41050 >=20 > for the clang 8 code generation problem of > no code for setting r2 appropriately before > the: >=20 > bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >=20 > in unoptimized code ( no -O ). For the -O2 code: >=20 > ld r2,40(r1) >=20 > is present but is being skipped by the libunwind return > to the code: it returns to the just-following bl > instruction (like above) instead. >=20 > In both cases: >=20 > (gdb) x/32i 0x100007c0 > 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) > 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) > 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 > 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) > 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) > 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr > 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 > 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 > . . . >=20 > with an inappropriate r2 value leads to jumping to > inappropriate places. >=20 > The example source code was: >=20 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } >=20 >=20 >=20 > Note: >=20 > This is from investigations of head -r345044 using > WITH_LLVM_LIBUNWIND=3D on powerpc64. >=20 The discussion on https://bugs.llvm.org//show_bug.cgi?id=3D41050 indicates that the ld r2,??? to restore the value appropriate to the a.out code in my example should be happening via the library holding libunwind's code instead of the ld executing in the a.out code. So: thus far it is viewed as a libunwind issue instead of a clang one. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Thu Mar 14 06:30:16 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A5F11531767; Thu, 14 Mar 2019 06:30:16 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BF3A8DCEC; Thu, 14 Mar 2019 06:30:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2E6U7DR042005 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 Mar 2019 23:30:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2E6U7ke042004; Wed, 13 Mar 2019 23:30:07 -0700 (PDT) (envelope-from sgk) Date: Wed, 13 Mar 2019 23:30:07 -0700 From: Steve Kargl To: John Baldwin Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314063007.GA41995@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313212455.GA37717@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 8BF3A8DCEC X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.95 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.82)[0.825,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.95)[0.950,0]; NEURAL_SPAM_MEDIUM(0.46)[0.462,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 06:30:16 -0000 On Wed, Mar 13, 2019 at 02:24:55PM -0700, Steve Kargl wrote: > On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > > On 3/13/19 9:40 AM, Steve Kargl wrote: > > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > > >> On 3/13/19 8:16 AM, Steve Kargl wrote: > > >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > >>>> > > >>>> gcc8 --version > > >>>> gcc8 (FreeBSD Ports Collection) 8.3.0 > > >>>> > > >>>> gcc8 -fno-builtin -o z a.c -lm && ./z > > >>>> gcc8 -O -fno-builtin -o z a.c -lm && ./z > > >>>> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > > >>>> gcc8 -O3 -fno-builtin -o z a.c -lm && ./z > > >>>> > > >>>> Max ULP: 2.297073 > > >>>> Count: 0 (# of ULP that exceed 21) > > >>> > > >>> clang agrees with gcc8 if one changes ... > > >>> > > >>>> int > > >>>> main(void) > > >>>> { > > >>>> double re, im, u, ur, ui; > > >>>> float complex f; > > >>>> float x, y; > > >>> > > >>> this line to "volatile float x, y". > > >> > > >> So it seems to be a regression in clang 7 vs clang 6? > > > > > > /usr/local/bin/clang60 has the same problem. > > > > > > % /usr/local/bin/clang60 -o z -O2 a.c -lm && ./z > > > Maximum ULP: 23.061242 > > > # of ULP > 21: 39 > > > > > > Adding volatile as in the above "fixes" the problem. > > > > > > AFAICT, this a i386/387 code generation problem. Perhaps, > > > an alignment issue? > > > > Oh, I misread your earlier e-mail to say that clang60 worked. > > > > One issue I'm aware of is that clang does not have any support for the > > special arrangement FreeBSD/i386 uses where it uses different precision > > for registers vs in-memory for some of the floating point types (GCC has > > a special hack that is only used on FreeBSD for this but isn't used on > > any other OS's). I wonder if that could be a factor? Volatile probably > > forces a round trip between memory which might explain why this is the > > case. > > > > I went looking for this special hack. In gcc/gccx/config/i386, > one finds > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the > compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > So, taking this as a hunch, I added ieeefp.h to my test program > and called 'fpsetprec(FP_PD)' as the first executable statement. > This then results in > > % cc -fno-builtin -m32 -O2 -o z b.o a.c -lm && ./z > Max u: 2.297073 > Count: 0 > > So, is there a way to correctly build clang for i386/387 > to automatically set the precision correctly? > Spent a couple hours wandering in contrib/llvm. Have no idea how to fix clang to actually work on i386/387. Any ideas would be welcomed. AFAICT, all libm float routines need to be modified to conditional include ieeefp.h and call fpsetprec(FP_PD). This will work around issues is FP and libm. FreeBSD needs to issue an erratum about the numerical issues with clang. -- Steve From owner-freebsd-toolchain@freebsd.org Thu Mar 14 16:46:06 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A05511549130; Thu, 14 Mar 2019 16:46:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 963A588371; Thu, 14 Mar 2019 16:46:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2EGk3BH045092 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 09:46:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2EGk3lK045091; Thu, 14 Mar 2019 09:46:03 -0700 (PDT) (envelope-from sgk) Date: Thu, 14 Mar 2019 09:46:03 -0700 From: Steve Kargl To: John Baldwin Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314164603.GA45044@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190314063007.GA41995@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 963A588371 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.87 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.887,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_LONG(0.93)[0.930,0]; NEURAL_SPAM_MEDIUM(0.34)[0.340,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.02)[ip: (0.09), ipnet: 128.95.0.0/16(0.08), asn: 73(0.01), country: US(-0.07)] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 16:46:06 -0000 On Wed, Mar 13, 2019 at 11:30:07PM -0700, Steve Kargl wrote: > > Spent a couple hours wandering in contrib/llvm. Have no idea > how to fix clang to actually work on i386/387. Any ideas > would be welcomed. > > AFAICT, all libm float routines need to be modified to conditional > include ieeefp.h and call fpsetprec(FP_PD). This will work around > issues is FP and libm. FreeBSD needs to issue an erratum about > the numerical issues with clang. > Probably beating a dead horse, but I'll continue as someone might actually be able to me fix clang. clang has the ability to determine the default precision that the FPU on i386 is using. #include #include #include #include int main(void) { fp_prec_t p; p = fpgetprec(); switch(p) { case FP_PS: printf("24 bit (single-precision)\n"); break; case FP_PRS: printf("reserved\n"); break; case FP_PD: printf("53 bit (double-precision)\n"); break; case FP_PE: printf("64 bit (extended-precision)\n"); break; default: errx(1,"unable to determine precision"); }; return 0; } % cc -o z -O2 d.c && ./z 53 bit (double-precision) It is likely that one (or more files) in contrib/llvm/Target/X86 to be fixed. Unfortunately, there are 116 files, which are written in languages I do not know. Any pointers of which file(s) to poke? -- Steve From owner-freebsd-toolchain@freebsd.org Thu Mar 14 18:50:55 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86BA81527949; Thu, 14 Mar 2019 18:50:55 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C3C28C8EA; Thu, 14 Mar 2019 18:50:54 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id x2EIog59034550 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Mar 2019 05:50:48 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id x2EIobL5023030 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Mar 2019 05:50:37 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id x2EIobtH023029; Fri, 15 Mar 2019 05:50:37 +1100 (AEDT) (envelope-from peter) Date: Fri, 15 Mar 2019 05:50:37 +1100 From: Peter Jeremy To: Steve Kargl Cc: John Baldwin , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314185037.GI87064@server.rulingia.com> References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ABTtc+pdwF7KHXCz" Content-Disposition: inline In-Reply-To: <20190314063007.GA41995@troutmask.apl.washington.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.11.1 (2018-12-01) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 18:50:55 -0000 --ABTtc+pdwF7KHXCz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: >AFAICT, all libm float routines need to be modified to conditional >include ieeefp.h and call fpsetprec(FP_PD). This will work around >issues is FP and libm. FreeBSD needs to issue an erratum about=20 >the numerical issues with clang. I vaguely recall looking into the x87 initialisation a long time ago and STR that the startup code (either crtX or in the kernel) does a fninit() to set the precision. I don't recall exactly where. IMO, calling fpsetprec() in every libm float function is overkill. It should be enough to fpsetprec() before main() and add a note in the man pages that libm is built to use the default FPU configuration and changing the configuration (precision or rounding) may result in larger errors. --=20 Peter Jeremy --ABTtc+pdwF7KHXCz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAlyKon1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzRz9Q/+OjrikP4PpHTymluNc8n4nsbSy40WblYJX2mCk85Rn3F8y0IPYAPk8x6U GlyulPEvgdom2WwuWJ4EhyEqH2pGQzFHSoc3sLiF8XRNlLH/IX0CkFhv2CWGTD0R oCHb1Q5Gs0RdbKKIbrHJTCCQeuYNwPiLExZfxZ2nwpxMOhTAuMSVBTlG00E3a2OF 3APRz+f/cL72+1mt8PV9bIEg4R0xaGzpxf8t9/V9/Ljnzh/Wd/nNhI9NrOoUJ8Df i1/gHcg4SUiMaZBIdU4WpPo2dhy2PJx3w6wl5M6CKd+6VUmX041M+xkDqa6mepvc UdsJkfJ3Kfj7iZ0UYGWw56QR2yTlbNyB73enGbQEUv6fbUgVeAlcKoVS+JWE6t8y en3VC8JcsdlbmRUkJCFlDufJMD6v+wtN7fe/wAedut5gp5j/wlWFzNYhb+2UBBJp FCaE7zgkILXJY58tae2kTOe00zNYg1SlAyHIk4XZt1qlZ99wjAmbD/Fo+YSVR7wL xsgCJ8ZDUqiV8ny2TospBYdoCuqGTgEu5tJw3l5HAyX86RVLMVFDj94PvdrkdvtO v6y68hnIeCO6f5bnQ/AzWFhtWHx8QxB7MCGDnNPM3XVhXFQLs+GtSg9o4V6yt27p Itss96uin2NlCVgAC0lsFz+ZO2VR/UWu0slzsopgDTn+zonbOdE= =M9/i -----END PGP SIGNATURE----- --ABTtc+pdwF7KHXCz-- From owner-freebsd-toolchain@freebsd.org Thu Mar 14 19:20:08 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB05E15282FC; Thu, 14 Mar 2019 19:20:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 172A18D62E; Thu, 14 Mar 2019 19:20:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2EJK0ui056546 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 21:20:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EJK0ui056546 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EJK0bO056545; Thu, 14 Mar 2019 21:20:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 21:20:00 +0200 From: Konstantin Belousov To: Peter Jeremy Cc: Steve Kargl , John Baldwin , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314192000.GI2492@kib.kiev.ua> References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> <20190314185037.GI87064@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190314185037.GI87064@server.rulingia.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:20:08 -0000 On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: > >AFAICT, all libm float routines need to be modified to conditional > >include ieeefp.h and call fpsetprec(FP_PD). This will work around > >issues is FP and libm. FreeBSD needs to issue an erratum about > >the numerical issues with clang. > > I vaguely recall looking into the x87 initialisation a long time ago > and STR that the startup code (either crtX or in the kernel) does > a fninit() to set the precision. I don't recall exactly where. At boot, a clean initial FPU state is stored in fpu_initialstate. Then on first FPU access from userspace (first for the given process context), this saved state is copied into hardware registers. The quirk is that for i386 binaries on amd64, we adjust fpu control word to what is expected by i386 binaries. > > IMO, calling fpsetprec() in every libm float function is overkill. It > should be enough to fpsetprec() before main() and add a note in the > man pages that libm is built to use the default FPU configuration and > changing the configuration (precision or rounding) may result in larger > errors. Changing default precision in crt1 would break the ABI. From owner-freebsd-toolchain@freebsd.org Thu Mar 14 19:59:17 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 426D3152A366; Thu, 14 Mar 2019 19:59:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFA4B681AD; Thu, 14 Mar 2019 19:59:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 0BED714FF8; Thu, 14 Mar 2019 19:59:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Optimization bug with floating-point? To: Konstantin Belousov , Peter Jeremy Cc: Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> <20190314185037.GI87064@server.rulingia.com> <20190314192000.GI2492@kib.kiev.ua> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <99ad567f-a1de-b3be-af4b-456df116bee7@FreeBSD.org> Date: Thu, 14 Mar 2019 12:59:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190314192000.GI2492@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: CFA4B681AD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984,0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:59:17 -0000 On 3/14/19 12:20 PM, Konstantin Belousov wrote: > On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: >> On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: >>> AFAICT, all libm float routines need to be modified to conditional >>> include ieeefp.h and call fpsetprec(FP_PD). This will work around >>> issues is FP and libm. FreeBSD needs to issue an erratum about >>> the numerical issues with clang. >> >> I vaguely recall looking into the x87 initialisation a long time ago >> and STR that the startup code (either crtX or in the kernel) does >> a fninit() to set the precision. I don't recall exactly where. > At boot, a clean initial FPU state is stored in fpu_initialstate. > Then on first FPU access from userspace (first for the given process > context), this saved state is copied into hardware registers. The > quirk is that for i386 binaries on amd64, we adjust fpu control word > to what is expected by i386 binaries. > >> >> IMO, calling fpsetprec() in every libm float function is overkill. It >> should be enough to fpsetprec() before main() and add a note in the >> man pages that libm is built to use the default FPU configuration and >> changing the configuration (precision or rounding) may result in larger >> errors. > Changing default precision in crt1 would break the ABI. So what I don't understand then is what is gcc doing different than clang in this case. I assume neither GCC _nor_ clang are adjusting the FPU in compiler-generated code, and in fact as Steve's earlier tests shows, the precision is set to PD by default when a clang-built binary is run. -- John Baldwin From owner-freebsd-toolchain@freebsd.org Thu Mar 14 20:08:18 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DBD152A83D; Thu, 14 Mar 2019 20:08:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 506B069CD7; Thu, 14 Mar 2019 20:08:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x2EK8FaL046252 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 13:08:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x2EK8FOb046251; Thu, 14 Mar 2019 13:08:15 -0700 (PDT) (envelope-from sgk) Date: Thu, 14 Mar 2019 13:08:15 -0700 From: Steve Kargl To: Peter Jeremy Cc: John Baldwin , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314200815.GA46070@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> <20190314185037.GI87064@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190314185037.GI87064@server.rulingia.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 506B069CD7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 20:08:18 -0000 On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: > >AFAICT, all libm float routines need to be modified to conditional > >include ieeefp.h and call fpsetprec(FP_PD). This will work around > >issues is FP and libm. FreeBSD needs to issue an erratum about > >the numerical issues with clang. > > I vaguely recall looking into the x87 initialisation a long time ago > and STR that the startup code (either crtX or in the kernel) does > a fninit() to set the precision. I don't recall exactly where. > > IMO, calling fpsetprec() in every libm float function is overkill. It > should be enough to fpsetprec() before main() and add a note in the > man pages that libm is built to use the default FPU configuration and > changing the configuration (precision or rounding) may result in larger > errors. My understanding of the situation is that FreeBSD i386/387 sets the FPU to 53-bit precision (whether at start up or first access is immaterial). This was done long ago to prevent issues with different optimization levels leaving different intermediate results is registers with extended precision. You can observe the problem with the toy program I posted and clang. Compile it with -O0 and -O2. With the former you have max ULP of 2.9 (the desired result); with the latter you have a max ULP of 23.xxx. I have observed a 6 billion ULP issue when running my testsuite. As pointed out by John Baldwin, GCC is aware of the FPU setting. The problem with clang is that it seems to unconditionally assume the FPU is set to 64-bit precision. It is unclear if clang is generated the desired result for float routines in libm. The only to gaurantee the desired resut is to use fpsetprec(FP_PD), or fix clang to take into account the FPU environment. -- Steve From owner-freebsd-toolchain@freebsd.org Thu Mar 14 20:11:50 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F726152AAA7; Thu, 14 Mar 2019 20:11:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A0E36A1BE; Thu, 14 Mar 2019 20:11:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2EKBgrC069294 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 22:11:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EKBgrC069294 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EKBgij069293; Thu, 14 Mar 2019 22:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 22:11:42 +0200 From: Konstantin Belousov To: John Baldwin Cc: Peter Jeremy , Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org Subject: Re: Optimization bug with floating-point? Message-ID: <20190314201142.GL2492@kib.kiev.ua> References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> <20190314185037.GI87064@server.rulingia.com> <20190314192000.GI2492@kib.kiev.ua> <99ad567f-a1de-b3be-af4b-456df116bee7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99ad567f-a1de-b3be-af4b-456df116bee7@FreeBSD.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 20:11:50 -0000 On Thu, Mar 14, 2019 at 12:59:14PM -0700, John Baldwin wrote: > On 3/14/19 12:20 PM, Konstantin Belousov wrote: > > On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: > >> On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: > >>> AFAICT, all libm float routines need to be modified to conditional > >>> include ieeefp.h and call fpsetprec(FP_PD). This will work around > >>> issues is FP and libm. FreeBSD needs to issue an erratum about > >>> the numerical issues with clang. > >> > >> I vaguely recall looking into the x87 initialisation a long time ago > >> and STR that the startup code (either crtX or in the kernel) does > >> a fninit() to set the precision. I don't recall exactly where. > > At boot, a clean initial FPU state is stored in fpu_initialstate. > > Then on first FPU access from userspace (first for the given process > > context), this saved state is copied into hardware registers. The > > quirk is that for i386 binaries on amd64, we adjust fpu control word > > to what is expected by i386 binaries. > > > >> > >> IMO, calling fpsetprec() in every libm float function is overkill. It > >> should be enough to fpsetprec() before main() and add a note in the > >> man pages that libm is built to use the default FPU configuration and > >> changing the configuration (precision or rounding) may result in larger > >> errors. > > Changing default precision in crt1 would break the ABI. > > So what I don't understand then is what is gcc doing different than clang > in this case. I assume neither GCC _nor_ clang are adjusting the FPU in > compiler-generated code, and in fact as Steve's earlier tests shows, the > precision is set to PD by default when a clang-built binary is run. Precision control only affect elementary floating-point instructions. Could this be the cause ? SDM vol 1 8.1.5.2 Precision Control Field The precision-control bits only affect the results of the following floating-point instructions: FADD, FADDP, FIADD, FSUB, FSUBP, FISUB, FSUBR, FSUBRP, FISUBR, FMUL, FMULP, FIMUL, FDIV, FDIVP, FIDIV, FDIVR, FDIVRP, FIDIVR, and FSQRT. From owner-freebsd-toolchain@freebsd.org Thu Mar 14 21:03:20 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FD90152E0BF; Thu, 14 Mar 2019 21:03:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6A3C6CFDC; Thu, 14 Mar 2019 21:03:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2219C15794; Thu, 14 Mar 2019 21:03:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Optimization bug with floating-point? To: sgk@troutmask.apl.washington.edu, Peter Jeremy Cc: freebsd-toolchain@freebsd.org, freebsd-current@freebsd.org References: <20190313024506.GA31746@troutmask.apl.washington.edu> <20190313151635.GA34757@troutmask.apl.washington.edu> <20190313164039.GA35340@troutmask.apl.washington.edu> <20190313212455.GA37717@troutmask.apl.washington.edu> <20190314063007.GA41995@troutmask.apl.washington.edu> <20190314185037.GI87064@server.rulingia.com> <20190314200815.GA46070@troutmask.apl.washington.edu> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <2987d041-a356-bd65-2157-4135d4f738ce@FreeBSD.org> Date: Thu, 14 Mar 2019 14:03:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190314200815.GA46070@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D6A3C6CFDC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 21:03:20 -0000 On 3/14/19 1:08 PM, Steve Kargl wrote: > On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote: >> On 2019-Mar-13 23:30:07 -0700, Steve Kargl wrote: >>> AFAICT, all libm float routines need to be modified to conditional >>> include ieeefp.h and call fpsetprec(FP_PD). This will work around >>> issues is FP and libm. FreeBSD needs to issue an erratum about >>> the numerical issues with clang. >> >> I vaguely recall looking into the x87 initialisation a long time ago >> and STR that the startup code (either crtX or in the kernel) does >> a fninit() to set the precision. I don't recall exactly where. >> >> IMO, calling fpsetprec() in every libm float function is overkill. It >> should be enough to fpsetprec() before main() and add a note in the >> man pages that libm is built to use the default FPU configuration and >> changing the configuration (precision or rounding) may result in larger >> errors. > > My understanding of the situation is that FreeBSD i386/387 sets > the FPU to 53-bit precision (whether at start up or first access > is immaterial). This was done long ago to prevent issues with > different optimization levels leaving different intermediate > results is registers with extended precision. You can observe > the problem with the toy program I posted and clang. Compile it > with -O0 and -O2. With the former you have max ULP of 2.9 (the > desired result); with the latter you have a max ULP of 23.xxx. > I have observed a 6 billion ULP issue when running my testsuite. > As pointed out by John Baldwin, GCC is aware of the FPU setting. > The problem with clang is that it seems to unconditionally assume > the FPU is set to 64-bit precision. It is unclear if clang is > generated the desired result for float routines in libm. The > only to gaurantee the desired resut is to use fpsetprec(FP_PD), > or fix clang to take into account the FPU environment. OTOH, note that every other OS in 32-bit mode uses 64-bit precision, and amd64 also uses 64-bit precision by default IIUC. FreeBSD/i386 is definitely unique in this regard. Linux doesn't do it, none of the other BSD's do it (only Dragonfly does b/c they inherited it from FreeBSD). None of Solaris, Windows, etc. do it either if the gcc sources are to be trusted as a reference. That said, I think it must have to do with how clang vs GCC is handling saving the values in memory and whether or not it does truncation to 53 bits when stored in memory somehow. I was trying to poke around in GCC's sources to figure out if it was doing anything differently, but I couldn't find a difference in terms of function pointers, etc. The only difference is is the constants used in a set of structures. I haven't tried to track down what those struct member values control though. -- John Baldwin From owner-freebsd-toolchain@freebsd.org Thu Mar 14 22:36:57 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 100A615317AF for ; Thu, 14 Mar 2019 22:36:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC007106A for ; Thu, 14 Mar 2019 22:36:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5639515317AE; Thu, 14 Mar 2019 22:36:56 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421FA15317AD for ; Thu, 14 Mar 2019 22:36:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8BDF71064 for ; Thu, 14 Mar 2019 22:36:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 01BC2E33E for ; Thu, 14 Mar 2019 22:36:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2EMasVe085044 for ; Thu, 14 Mar 2019 22:36:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2EMasU9085042 for toolchain@FreeBSD.org; Thu, 14 Mar 2019 22:36:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 234201] Regression in LLVM libunwind: Apache Tomcat web application crashes on 12.0 (but not on 11.2) Date: Thu, 14 Mar 2019 22:36:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, regression, toolchain X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: michael.osipov@siemens.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 22:36:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234201 Michael Osipov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael.osipov@siemens.com --- Comment #3 from Michael Osipov --- I'll migrate our Tomcat-based apps to a 12-RELEASE jail on top of a 12-STAB= LE host and will report in a week or two whether I will have the same failures. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Mar 14 22:37:40 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE195153182B for ; Thu, 14 Mar 2019 22:37:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 44ABF710DA for ; Thu, 14 Mar 2019 22:37:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 051691531827; Thu, 14 Mar 2019 22:37:40 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7D381531826 for ; Thu, 14 Mar 2019 22:37:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A66710D3 for ; Thu, 14 Mar 2019 22:37:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id CBF0CE347 for ; Thu, 14 Mar 2019 22:37:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2EMbc5K085790 for ; Thu, 14 Mar 2019 22:37:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2EMbcjA085789 for toolchain@FreeBSD.org; Thu, 14 Mar 2019 22:37:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 234201] Regression in LLVM libunwind: Apache Tomcat web application crashes on 12.0 (but not on 11.2) Date: Thu, 14 Mar 2019 22:37:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: crash, regression, toolchain X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: michael.osipov@siemens.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 22:37:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234201 --- Comment #4 from Michael Osipov --- (In reply to Marie Helene Kvello-Aune from comment #0) Can you please tell when this failures exactly happens? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Mar 15 01:43:49 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 625DF1537025 for ; Fri, 15 Mar 2019 01:43:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23A1380066 for ; Fri, 15 Mar 2019 01:43:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wRZX4gQVM1m7oWD3udlOD3dUMYjwmQ.VHBJ1Ay2Igtg2V4FNnDODcL6VqFRLIBF RXqIORRTt6iSpsxGLxheu57QsYMrF_RLS7RRRZhSbd5PR9PCOvxpbPY.K3Omy9.UuRkG_VMkMMVx aIiLScx4v1lIGL6V6eQIf6kVuvBn7CJhWhAX6E9sTsm1RB5xD9WS9xQT4TvwDpZB78K_I8m8GzWR ejuJyJM3wvT.c0bRHC3pvExtMQJsZOsmLCH2oT1OQIOeEg1KmlC19rNMCLQ3gOIFp53_0b_fvUTc .wQdZ9hTgAvRh8CWw0kmHQBxC6On373KqSdDSu.k5q1NIrSxRgm7aFITYh50yiCbqo_lNcL9U4bh qzdJ3OzP68SlTKBQy7Y721GQjGmyXMbztB.ij8uHvBwjNbAaBHKvr6lxin5iLzU6bbQv8iynY4jb 7oeAewcxdMGGh0EaxWeF87eN1AUKjFup8Fe_x8cOzTf9rNqc9Bg9Slb24AY31panoG591wYUWKjN XbEUPLxNGZaJgE8EZy3.orEexwzZcq05X8WzHEtxN6RMePZEQeUisaiwWwyKSctOTbSe5IJfPX6q ZGBqsX0ripuuP8LP8Qy8jbnhdWORnjgzCeSt5pYdOcZfwlkgSJGHEsF2uTArJooFWDa5CuFRoP1b LUS_4SwdlkKsEhIDJAlKsR4CoePiq0bs16l9EPqrpRmo9ncLD6PLBA8NuAy3ga7kwsNpUvR3Qa5X NDv7iWpjiyS7CgWKPh73L46uDePyGbm.7z8WZVU7rwKSWiJCWMssvsg0yUOn2NDALy6jDX2exIzQ CByzGjRUUSzzzW92vxYSeyvHqBdxxDmKNwr_TW8Wcbd30AiglM7wKKB0YJ7KJDvtaPlSxAmOw4s3 QtvncT8eNL36VKG_Z7Ayp5txJLgO8AaCT8alzeyR8BnjCBaMwx4xio9lz8vT1qD0HvcnA8poKOBh XJgJwTfINILpkcTlP0LC4StChR7DNvXDEEcVH6QYI2FCZ0_ZoPCTv2E_OBa4ogiMAVTFobf_a5rA _M3n4oRRvZUdebHoBN84kh4Fc5YjJwfGLRwSc1uE2Lt__BlXUUHVvCamP8PBZaE4_cmoQPexZDoH adlPIR8Hd Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Mar 2019 01:43:46 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 39434808bbff3548ebbad8c6df877feb; Fri, 15 Mar 2019 01:23:31 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: llvm submittal 41050 created for powerpc64 C++ exception code generation: ld r2,40(r1) missing or skipped before bl __cxa_begin_catch code Date: Thu, 14 Mar 2019 18:23:30 -0700 References: <0AD5D131-C5E3-424E-A276-D960ABDBDFCD@yahoo.com> <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> To: FreeBSD Toolchain , FreeBSD PowerPC ML In-Reply-To: <2429D922-3214-4D40-9616-56BC0CB93A15@yahoo.com> Message-Id: <795BBC02-6CE9-401E-8D9F-84FB9FB31364@yahoo.com> X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 23A1380066 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.92)[0.919,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.22)[ip: (4.40), ipnet: 98.137.64.0/21(0.98), asn: 36647(0.78), country: US(-0.07)]; NEURAL_SPAM_MEDIUM(0.73)[0.726,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.44)[0.445,0]; RCVD_IN_DNSWL_NONE(0.00)[32.68.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 01:43:49 -0000 [ELFv2 vs. ELFv1 ABI differences may lead to the fix only applying to one of them: ELFv2's ABI.] On 2019-Mar-13, at 19:14, Mark Millard wrote: > On 2019-Mar-12, at 22:08, Mark Millard wrote: >=20 >> I have submitted: >>=20 >> https://bugs.llvm.org//show_bug.cgi?id=3D41050 >>=20 >> for the clang 8 code generation problem of >> no code for setting r2 appropriately before >> the: >>=20 >> bl . . . <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3> >>=20 >> in unoptimized code ( no -O ). For the -O2 code: >>=20 >> ld r2,40(r1) >>=20 >> is present but is being skipped by the libunwind return >> to the code: it returns to the just-following bl >> instruction (like above) instead. >>=20 >> In both cases: >>=20 >> (gdb) x/32i 0x100007c0 >> 0x100007c0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3>: = std r2,40(r1) >> 0x100007c4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+4>: = ld r12,-32608(r2) >> 0x100007c8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+8>: = mtctr r12 >> 0x100007cc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+12>: = ld r11,-32592(r2) >> 0x100007d0 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+16>: = ld r2,-32600(r2) >> 0x100007d4 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+20>: = bctr >> 0x100007d8 <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+24>: = .long 0x0 >> 0x100007dc <00000018.plt_call.__cxa_begin_catch@@CXXABI_1.3+28>: = .long 0x0 >> . . . >>=20 >> with an inappropriate r2 value leads to jumping to >> inappropriate places. >>=20 >> The example source code was: >>=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >>=20 >>=20 >> Note: >>=20 >> This is from investigations of head -r345044 using >> WITH_LLVM_LIBUNWIND=3D on powerpc64. >>=20 >=20 > The discussion on https://bugs.llvm.org//show_bug.cgi?id=3D41050 > indicates that the ld r2,??? to restore the value appropriate to > the a.out code in my example should be happening via the library > holding libunwind's code instead of the ld executing in the > a.out code. >=20 > So: thus far it is viewed as a libunwind issue instead of a clang > one. Both ELFv2 and ELFv1 are currently broken because of r2 (TOC) mishanding. Looks like that when libunwind is fixed, it might not support the ELFv1 ABI (just the ELFv2 ABI): handling r2 (TOC) is different because of the differences in the stack frame header . . . ELFv1 has r2 save area at 40(r1) [because of the compiler and = link-editor doublewords] ELFV2 has r2 save area at 24(r1) [no compiler or link-editor = doublewords] A simple update to libunwind/src/UnwindRegistersRestore.S for = powerpc64's _ZN9libunwind15Registers_ppc646jumptoE is (an ELFv2 ABI example): - PPC64_LR(2) + // skip r2 for now and: PPC64_LR(4) PPC64_LR(1) PPC64_LR(3) + ld %r2, 24(%r1) bctr (That is from comment #16.) I've no clue if more would be done to handle the ELFv1 ABI as well. As I understand FreeBSD plans to support the ELFv2 ABI at some point. I'm not sure of the intent after that for the ELFv1 ABI. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Fri Mar 15 07:35:03 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C6A81540F3B for ; Fri, 15 Mar 2019 07:35:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B77DD8CC91 for ; Fri, 15 Mar 2019 07:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7BCE51540F34; Fri, 15 Mar 2019 07:35:02 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67C411540F33 for ; Fri, 15 Mar 2019 07:35:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F21A58CC8C for ; Fri, 15 Mar 2019 07:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1AC3513206 for ; Fri, 15 Mar 2019 07:35:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2F7Z01a033045 for ; Fri, 15 Mar 2019 07:35:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2F7Z0rR033042 for toolchain@FreeBSD.org; Fri, 15 Mar 2019 07:35:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 233707] www/firefox: fails to build with -fstack-protector-{strong,all} + -Wl,-z,nocopyreloc Date: Fri, 15 Mar 2019 07:34:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.mimetype attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 07:35:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233707 rozhuk.im@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #202878|text/x-log |text/plain mime type| | --- Comment #29 from rozhuk.im@gmail.com --- Created attachment 202878 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D202878&action= =3Dedit log This is for latest firefox-66.0_2,1, without mine pathes. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Mar 15 15:45:25 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 419E1150936D for ; Fri, 15 Mar 2019 15:45:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CAC106D8C2 for ; Fri, 15 Mar 2019 15:45:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 89E451509363; Fri, 15 Mar 2019 15:45:24 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 775DB1509362 for ; Fri, 15 Mar 2019 15:45:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1048B6D8BD for ; Fri, 15 Mar 2019 15:45:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 053EB178D4 for ; Fri, 15 Mar 2019 15:45:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2FFjMNX027563 for ; Fri, 15 Mar 2019 15:45:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2FFjMBA027562 for toolchain@FreeBSD.org; Fri, 15 Mar 2019 15:45:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 233707] www/firefox: fails to build with -fstack-protector-{strong,all} + -Wl,-z,nocopyreloc Date: Fri, 15 Mar 2019 15:45:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tijl@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:45:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233707 Tijl Coosemans changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|Closed |Open --- Comment #30 from Tijl Coosemans --- (In reply to rozhuk.im from comment #29) Ok, that does look like your patch is necessary, but please change it to use -fPIE instead of -fPIC. Does the patch address the problem with clock_gett= ime as well or only these additional cases? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Mar 15 21:07:19 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E492152EC4E for ; Fri, 15 Mar 2019 21:07:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AF88D8314D for ; Fri, 15 Mar 2019 21:07:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 64D3B152EC4D; Fri, 15 Mar 2019 21:07:18 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51975152EC4C for ; Fri, 15 Mar 2019 21:07:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB83583147 for ; Fri, 15 Mar 2019 21:07:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E31B51A6EB for ; Fri, 15 Mar 2019 21:07:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2FL7GlV010942 for ; Fri, 15 Mar 2019 21:07:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2FL7GgX010934 for toolchain@FreeBSD.org; Fri, 15 Mar 2019 21:07:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 233707] www/firefox: fails to build with -fstack-protector-{strong,all} + -Wl,-z,nocopyreloc Date: Fri, 15 Mar 2019 21:07:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 21:07:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233707 --- Comment #31 from rozhuk.im@gmail.com --- Yes, it fix clock_gettime for me too. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Mar 15 21:08:12 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9595152ECB5 for ; Fri, 15 Mar 2019 21:08:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4F7831A2 for ; Fri, 15 Mar 2019 21:08:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id F309E152ECAF; Fri, 15 Mar 2019 21:08:11 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFC9F152ECAE for ; Fri, 15 Mar 2019 21:08:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 770148319B for ; Fri, 15 Mar 2019 21:08:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B29111A6F3 for ; Fri, 15 Mar 2019 21:08:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2FL8AwX027275 for ; Fri, 15 Mar 2019 21:08:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2FL8AUc027274 for toolchain@FreeBSD.org; Fri, 15 Mar 2019 21:08:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 233707] www/firefox: fails to build with -fstack-protector-{strong,all} + -Wl,-z,nocopyreloc Date: Fri, 15 Mar 2019 21:08:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rozhuk.im@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.isobsolete flagtypes.name attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 21:08:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233707 rozhuk.im@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #202675|0 |1 is obsolete| | Attachment #202889| |maintainer-approval+ Flags| | --- Comment #32 from rozhuk.im@gmail.com --- Created attachment 202889 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D202889&action= =3Dedit patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 02:47:04 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17BAB153C79F for ; Sat, 16 Mar 2019 02:47:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 932CC69B2A for ; Sat, 16 Mar 2019 02:47:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 54AED153C79C; Sat, 16 Mar 2019 02:47:03 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41791153C799 for ; Sat, 16 Mar 2019 02:47:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAC7069B28 for ; Sat, 16 Mar 2019 02:47:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F00851D7BC for ; Sat, 16 Mar 2019 02:47:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2G2l1Eq031887 for ; Sat, 16 Mar 2019 02:47:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2G2l1eJ031884 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 02:47:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236566] java/openjdk8: clang 8 crashes during build on aarch64 (blocks 647 ports) Date: Sat, 16 Mar 2019 02:47:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 02:47:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236566 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |java@FreeBSD.org Assignee|java@FreeBSD.org |toolchain@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 02:59:47 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D265B153CC9E for ; Sat, 16 Mar 2019 02:59:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 52E3969F83 for ; Sat, 16 Mar 2019 02:59:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 117FB153CC9B; Sat, 16 Mar 2019 02:59:46 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4A37153CC9A for ; Sat, 16 Mar 2019 02:59:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CDCC69F81 for ; Sat, 16 Mar 2019 02:59:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8F3841D924 for ; Sat, 16 Mar 2019 02:59:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2G2xiHM053581 for ; Sat, 16 Mar 2019 02:59:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2G2xi0c053580 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 02:59:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236566] java/openjdk8: clang 8 crashes during build on aarch64 and armv7 (blocks 647 ports) Date: Sat, 16 Mar 2019 02:59:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 02:59:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236566 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|java/openjdk8: clang 8 |java/openjdk8: clang 8 |crashes during build on |crashes during build on |aarch64 (blocks 647 ports) |aarch64 and armv7 (blocks | |647 ports) --- Comment #3 from Jan Beich --- Ditto armv7. $ poudriere jail -cj head-armv7 -x -a arm.armv7 -v head -m svn+https $ poudriere testport -j head-armv7 java/openjdk8 [...] Compiling /usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/oops/instanceKla= ss.cpp Assertion failed: (isa(Val) && "cast() argument of incompatible type= !"), function cast, file /usr/src/contrib/llvm/include/llvm/Support/Casting.h, l= ine 255. c++: error: unable to execute command: Abort trap (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 8.0.0 (branches/release_80 355677) (based on LLVM 8.0= .0) Target: armv7-unknown-freebsd13.0-gnueabihf Thread model: posix InstalledDir: /usr/bin http://www.ipv6proxy.net/go.php?u=3Dhttp://beefy16.nyi.freebsd.org/data/hea= d-armv7-default/p495681_s345110/logs/errors/openjdk8-8.202.8.log --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 04:32:49 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDD6B1540F65 for ; Sat, 16 Mar 2019 04:32:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 530576DDBB for ; Sat, 16 Mar 2019 04:32:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 14C621540F61; Sat, 16 Mar 2019 04:32:49 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02EED1540F60 for ; Sat, 16 Mar 2019 04:32:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 922AA6DDB7 for ; Sat, 16 Mar 2019 04:32:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D6A871E841 for ; Sat, 16 Mar 2019 04:32:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2G4WloM043101 for ; Sat, 16 Mar 2019 04:32:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2G4WlTN043100 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 04:32:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236567] lang/spidermonkey170, lang/spidermonkey38: clang 8 crashes during build on armv7 and armv6 Date: Sat, 16 Mar 2019 04:32:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: rep_platform Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 04:32:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236567 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Any |arm --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 04:20:48 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03CCE15409F5 for ; Sat, 16 Mar 2019 04:20:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3B46D694 for ; Sat, 16 Mar 2019 04:20:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 47C1915409F2; Sat, 16 Mar 2019 04:20:47 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35E6715409F1 for ; Sat, 16 Mar 2019 04:20:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C47886D68D for ; Sat, 16 Mar 2019 04:20:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 09F171E54C for ; Sat, 16 Mar 2019 04:20:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2G4Kjvi014662 for ; Sat, 16 Mar 2019 04:20:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2G4KjFW014661 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 04:20:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236567] lang/spidermonkey170, lang/spidermonkey38: clang 8 crashes during build on armv7 and armv6 Date: Sat, 16 Mar 2019 04:20:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 04:20:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236567 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kwm@FreeBSD.org Assignee|kwm@FreeBSD.org |toolchain@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 04:33:03 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B6BC1540F88 for ; Sat, 16 Mar 2019 04:33:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B563B6DDC8 for ; Sat, 16 Mar 2019 04:33:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 743001540F84; Sat, 16 Mar 2019 04:33:02 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6123A1540F83 for ; Sat, 16 Mar 2019 04:33:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD4176DDC6 for ; Sat, 16 Mar 2019 04:33:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 379E41E845 for ; Sat, 16 Mar 2019 04:33:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2G4X1oQ043382 for ; Sat, 16 Mar 2019 04:33:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2G4X1ir043381 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 04:33:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236568] devel/xwpe: clang 8 crashes during build on armv7 Date: Sat, 16 Mar 2019 04:33:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 04:33:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236568 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ports-bugs@FreeBSD.org |toolchain@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:01:32 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF9C153C82C for ; Sat, 16 Mar 2019 21:01:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 37BF27464F for ; Sat, 16 Mar 2019 21:01:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E3631153C82B; Sat, 16 Mar 2019 21:01:31 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D08EF153C82A for ; Sat, 16 Mar 2019 21:01:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69B5874649 for ; Sat, 16 Mar 2019 21:01:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 994A07A7E for ; Sat, 16 Mar 2019 21:01:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GL1Un7097952 for ; Sat, 16 Mar 2019 21:01:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GL1UtC097951 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:01:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236581] -fopenmp underlinking Date: Sat, 16 Mar 2019 21:01:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:01:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236581 Bug ID: 236581 Summary: -fopenmp underlinking Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org $ fetch https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c $ cc -fopenmp omp_hello.c $ ldd a.out a.out: libomp.so =3D> /usr/lib/libomp.so (0x80024b000) libc.so.7 =3D> /lib/libc.so.7 (0x8002fd000) $ ./a.out OMP: Error #178: Function pthread_key_create failed: OMP: System error #78: Function not implemented vs. $ pkg install llvm80 $ clang80 -fopenmp omp_hello.c $ ldd ./a.out ./a.out: libomp.so =3D> /usr/local/llvm80/lib/libomp.so (0x800249000) libc.so.7 =3D> /lib/libc.so.7 (0x8002f2000) libthr.so.3 =3D> /lib/libthr.so.3 (0x800706000) libm.so.5 =3D> /lib/libm.so.5 (0x800732000) $ ./a.out Hello World from thread =3D 0 Number of threads =3D 8 Hello World from thread =3D 5 Hello World from thread =3D 6 Hello World from thread =3D 3 Hello World from thread =3D 2 Hello World from thread =3D 1 Hello World from thread =3D 7 Hello World from thread =3D 4 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:02:07 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06A2F153C84A for ; Sat, 16 Mar 2019 21:02:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 92FC7746D7 for ; Sat, 16 Mar 2019 21:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4CAD0153C849; Sat, 16 Mar 2019 21:02:06 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39FFC153C848 for ; Sat, 16 Mar 2019 21:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C76F9746D3 for ; Sat, 16 Mar 2019 21:02:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 00EE17BA9 for ; Sat, 16 Mar 2019 21:02:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GL249U003465 for ; Sat, 16 Mar 2019 21:02:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GL24Te003464 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:02:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236581] -fopenmp underlinking Date: Sat, 16 Mar 2019 21:02:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: blocked Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:02:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236581 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |236062 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236062 [Bug 236062] [exp-run] Against projects/clang800-import branch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:13:22 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 539B1153E075 for ; Sat, 16 Mar 2019 21:13:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D89AC74DB4 for ; Sat, 16 Mar 2019 21:13:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9469C153E073; Sat, 16 Mar 2019 21:13:21 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 804BA153E072 for ; Sat, 16 Mar 2019 21:13:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A2E274DAD for ; Sat, 16 Mar 2019 21:13:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 4CE357D2F for ; Sat, 16 Mar 2019 21:13:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GLDKnG044357 for ; Sat, 16 Mar 2019 21:13:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GLDKp2044349 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:13:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236582] Enable LLVM openmp on i386 Date: Sat, 16 Mar 2019 21:13:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter blocked attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:13:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236582 Bug ID: 236582 Summary: Enable LLVM openmp on i386 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: toolchain@FreeBSD.org Reporter: jbeich@FreeBSD.org Blocks: 236062 Created attachment 202923 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D202923&action= =3Dedit v0 Clang -fopenmp works fine on i386, see ports r447281. As long as i386 remai= ns Tier1 having -fopenmp excluded on it will accelerate the sunset of the architecture due to increased effort required to maintain ports on it. Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236062 [Bug 236062] [exp-run] Against projects/clang800-import branch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:14:10 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEA2F153E0D0 for ; Sat, 16 Mar 2019 21:14:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADAD74E44 for ; Sat, 16 Mar 2019 21:14:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D837A153E0CC; Sat, 16 Mar 2019 21:14:09 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5C94153E0CB for ; Sat, 16 Mar 2019 21:14:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4332874E41 for ; Sat, 16 Mar 2019 21:14:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 695FD7D3E for ; Sat, 16 Mar 2019 21:14:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GLE8CC061408 for ; Sat, 16 Mar 2019 21:14:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GLE8i5061406 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:14:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236582] Enable LLVM openmp on i386 Date: Sat, 16 Mar 2019 21:14:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:14:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236582 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:38:08 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39686153E8A2 for ; Sat, 16 Mar 2019 21:38:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B7B0B758D5 for ; Sat, 16 Mar 2019 21:38:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7789A153E899; Sat, 16 Mar 2019 21:38:07 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53531153E897 for ; Sat, 16 Mar 2019 21:38:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA87E758D4 for ; Sat, 16 Mar 2019 21:38:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 064D98028 for ; Sat, 16 Mar 2019 21:38:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GLc5qD015439 for ; Sat, 16 Mar 2019 21:38:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GLc5XK015438 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:38:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236581] /usr/lib/libomp.so underlinking Date: Sat, 16 Mar 2019 21:38:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:38:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236581 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|-fopenmp underlinking |/usr/lib/libomp.so | |underlinking --- Comment #1 from Jan Beich --- Looks like a common mistake due to bug 236141. $ cc -fopenmp -fuse-ld=3Dbfd omp_hello.c /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `scalbnl' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `scalbnf' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `pthread_attr_getstack' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `scalbn' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `pthread_getthreadid_np' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `logbl' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `fmaxl' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `pthread_attr_get_np' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `pthread_create' /usr/local/bin/ld.bfd: /usr/lib/libomp.so: undefined reference to `pthread_condattr_init' cc: error: linker command failed with exit code 1 (use -v to see invocation) $ nm -D /usr/lib/libomp.so | fgrep pthread U pthread_atfork U pthread_attr_destroy U pthread_attr_get_np U pthread_attr_getstack U pthread_attr_init U pthread_attr_setdetachstate U pthread_attr_setstacksize U pthread_cond_destroy U pthread_cond_init U pthread_cond_signal U pthread_cond_wait U pthread_condattr_init U pthread_create U pthread_getspecific U pthread_getthreadid_np U pthread_join U pthread_key_create U pthread_key_delete U pthread_mutex_destroy U pthread_mutex_init U pthread_mutex_lock U pthread_mutex_unlock w pthread_mutexattr_destroy U pthread_mutexattr_init w pthread_mutexattr_settype U pthread_self U pthread_setcancelstate U pthread_setcanceltype U pthread_setspecific --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:48:04 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4AC3153EC7E for ; Sat, 16 Mar 2019 21:48:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5708675E62 for ; Sat, 16 Mar 2019 21:48:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 16C32153EC7A; Sat, 16 Mar 2019 21:48:04 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03E3C153EC79 for ; Sat, 16 Mar 2019 21:48:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88A0E75E61 for ; Sat, 16 Mar 2019 21:48:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D81F38190 for ; Sat, 16 Mar 2019 21:48:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GLm2jv043387 for ; Sat, 16 Mar 2019 21:48:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GLm2uY043386 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:48:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236581] /usr/lib/libomp.so underlinking Date: Sat, 16 Mar 2019 21:48:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:48:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236581 --- Comment #2 from Jan Beich --- Created attachment 202924 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D202924&action= =3Dedit v0 -Wl,--as-needed had to be dropped due to bug 214258. In order to reproduce = add -fuse-ld=3Dbfd to LDFLAGS. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Mar 16 21:48:18 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F8BB153ECAD for ; Sat, 16 Mar 2019 21:48:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0D375E8E for ; Sat, 16 Mar 2019 21:48:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BCAC8153ECAC; Sat, 16 Mar 2019 21:48:17 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB2F4153ECAB for ; Sat, 16 Mar 2019 21:48:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AF8775E8D for ; Sat, 16 Mar 2019 21:48:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 72D9B8191 for ; Sat, 16 Mar 2019 21:48:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2GLmGfK043611 for ; Sat, 16 Mar 2019 21:48:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2GLmGMt043610 for toolchain@FreeBSD.org; Sat, 16 Mar 2019 21:48:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 236581] /usr/lib/libomp.so underlinking Date: Sat, 16 Mar 2019 21:48:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 21:48:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236581 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.=