From owner-freebsd-toolchain@freebsd.org Wed Jul 8 10:10:51 2020 Return-Path: Delivered-To: freebsd-toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 06D7435E056 for ; Wed, 8 Jul 2020 10:10:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (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 4B1w6x2g14z3bQD for ; Wed, 8 Jul 2020 10:10:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ckeBaDwVM1lIgK6kdl9pS.9oBaRMJfe7T_113xJ8.o7A5W.LFDliN9J2YVrhFdY O.ruUyGGgqaZNdGjm8u4NiwSM1AtU3NP62wERreBeN67_ovb121VSTLfy8tolHiL14ZGxq.fTeGK KASfxmEBsVSuHNI6sNHmuPZhOLtK33dovvs8IWfKZnM42qBHk.qDlXjTfM_1zzf2ZAb13B4Kuxv4 g5NCqIrwk1X71_bl06iBAOuoJyl6Havi6WTwqsq6mZmtmUc.D_RQXSXoXnQgCgGgd_oL7DCZR2aw BV3Kwv3bp30_BcJBbW.MxS6DzqfA8TT9ky9mnBeyx7rYbgHCXL81cTjeKvBw8selZjoAvxZdEzoq vAlRTEOn4Q3xXhXj4.LFUjwnypTFJkm8iIKY1fArpoCkfp_6GdgmsATZQNNZKnUawLi6IgkMRgZD 5dQoQPfStUi0BbPk6A7qPzRlbLohaEkjaX3ars22WH5OKb2P0i.vyt13ywsgcLdus4c7.fK1arYK TWAL39UJar3lJT5BHYRafn2sxII_74vSAfa88.qtA4ByRat8e2IbI8sYkXcPFGgV2OG8guNfx6f9 tOKrHjQoM8TdTpdB7Fl7HCMYfQU1k6ErI0Djmehgr3GpxMkc8obCQMed5D5OCNStXBmC05x4r9Gz izcCMz8zlbOW.KPIjqVK.RXzI8_vfbzHg.JEjDwcJNVk03UbG_VM4UwDTMJAWII86yQY1GEClYtU LQyo_99J5DIYyG9.n8z_Fzo_9GCD2KbsOnaBNbpf5AWbo_oT15gNajVOMWEdJLnoPiha061o39lA do6DngFqC9RCEUiJVrp872mvFG01s_APbqpIrDRllvar37maIwBjlgCO7WxvBwEo345IwR4yWM9l 7CyjV8jX7o90E8bZ6Uq0kxFNsCvp1iYWdPVtpnRtRHfBb0b8rNT639onmautEGAXWi.Y2paJSTd. fYz7WpmRErnkat151.fhq96YDeSZg_8NRYIy5u4.TP.owr60RyaHD6Em8KQOziZrPAm3JxZvX6Sq PoCdSCLb9VDLtu0eLe2KkHKLLnrFZQj5MkJu9wzUpjpYlSeE77GcLlp0vYfqM6bEcTRhl8jjoOrR KY2uHp6nq7NNcYmtWa_q4OiHtAgaxlDmVgM18o0kyRE1uHM8MDFRdnH1u4ZKg1E7ckobkDHBA2O4 a8cXpDTCRECV2blJuMr_7Kq_DV6hxVL6n3AFbhO8EPerbqxMOqkXeIYVQD5SlKydX1X4O3Q8ZZuJ 6Hmsxi.Da6GSjc_8YhDpUU9BeXyJp.zD4rmn6rMkNBpuunl9ao3Ljisnmiv8m0DZIrLKmx92vcph eJO6Avl26WZJ.9UV4O4kRdknm784oeF8uWRYZLNweZn8oF482q5mbC0I_.MLQKeljo0POnsXoCaD 1WgtjcbX6TTTweLxEwmkq225k_b_meA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jul 2020 10:10:47 +0000 Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d518534d9e200e8d3d68197590e1386b; Wed, 08 Jul 2020 10:10:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) From: Mark Millard In-Reply-To: Date: Wed, 8 Jul 2020 03:10:44 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Toolchain , freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: References: <64523602-7EFC-4A97-90EA-C776BF2A0AF7.ref@yahoo.com> <64523602-7EFC-4A97-90EA-C776BF2A0AF7@yahoo.com> To: =?utf-8?Q?Stefan_E=C3=9Fer?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4B1w6x2g14z3bQD X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.51 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.02)[-1.021]; 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)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.99)[-0.992]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.33 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, 08 Jul 2020 10:10:51 -0000 On 2020-Jul-8, at 01:28, Stefan E=C3=9Fer wrote: > Am 08.07.20 um 09:01 schrieb Mark Millard: >> The following is more informational than anything as far >> as I'm concerned. But there may be implications that I'm >> unaware of. (I sometimes experiment with toolchain use >> to see what the current status is for such use.) >>=20 >> I attempted to build a system for 32-bit powerpc using clang >> and binutils, building head -r363000 ( from -r363000 ). (This >> was a cross build, amd64 -> powerpc.) It got a new type of >> failure, compared to my past experience: >=20 > Hi Mark, >=20 > thank you for the report. I have tested with "make universe" (with > default settings) that this version builds on all architectures, > but Ed Maste has already disabled -flto for powerpc64, due to run > time issues (floating point exception, IIRC). The builds I actually run are based on pure-llvm, not such odd mixes --nor even gcc+binutils. Also, I've not even tried a build since updating to head -r360311 --until now trying to update things to head -r363000 (or so). It is not obvious to me that FreeBSD intends for gcc based builds or binutils based buildworld buildkernel to be supported, even without mixing in LLVM. The ci.freebsd.org builds via gcc6 for amd64 have not completed in a very long time. My standard build procedure historically builds combinations like clang-with-binutils that used to completely build. (Not that the result worked to boot and operate an old PowerMac in recent times.) So I noticed this just by the build procedure failing. There are other combinations that failed some time ago that I turned off in my build procedure after sending a notice to the lists. As of the official switch to llvm-based for powerpc64 and powerpc, I've not been able to boot and operate anything but pure-llvm based builds, even for other types of builds that did "complete". That includes not being able to build and operate system based on modern gcc+binutils without LLVM. It appears to me that it would be a fair sized effort to get gcc+binutils working for powerpc64 or powerpc. My history with odd combinations derived from experimenting with more modern toolchains for powerpc64 and powerpc back in the gcc 4.2.1 days when no llvm based linker was affectively available. Although, I do like the idea of having code pass through and the result operate based on multiple toolchains, not just one, say, modern gcc+binutils as an alternate. Still, if FreeBSD declared "gcc not supported" and "binutils not supported" and "gcc+binutils not supported" for building FreeBSD, I'd just stick to llvm based. > I know that you are actively working on PowerPC and I'd appreciate, > if you could provide me with information on which parameters cause > breakage and which work for you. I think that the answer is: only pure llvm-based has worked for booting and operating since the switch away from gcc 4.2.1 for powerpc64 and powerpc. Everything else either stops the build early or does not operate correctly (as I remember anyway). Apparently, more combinations are landing in the "stops the build early" category over time. > The combination of CLANG with LTO > and GNU binutils cannot work - CLANG and GCC use incompatible file > formats to represent the intermediate object files. To my knowledge, a modern gcc+binutils does not work as the basis for a FreeBSD build for powerpc64 or powerpc. No need to have a mixed toolchain involved or -flto involved to have blocking issues. > This version of bc uses advanced algorithms (compared to the one > it replaced) for much reduced time complexity (a factor of more > than 100 for large numbers has been observed). It uses layering > for correctness, e.g. a set of "vector" management functions, that > are built as a separate compile unit. Compiling with -flto lets the > linker replace many function calls with constant parameters with > much more efficient inline instructions, resulting in 30% higher > performance. The code could be re-arranged to use inline functions > instead of relying on -flto, but this would be a lot of effort and > might make the code much harder to maintain. I'm not objecting to -flto use, even if it constrains what can be used as a basis for building and operating FreeBSD. There are issues that well predate -flto use that block other toolchains for powerpc64 and powerpc. If more than llvm-based is to be supported, I'd just suggest modern gcc+binutils, avoiding claiming support for mixes such as llvm+binutils. > If there is a condition that could be added to the Makefile to not > enable LTO if CLANG+binutils or GCC+LLD are mixed, then I'm willing > to add it. If it happened that -flto use vs. not needs to be configurable for other reasons and it happens to end up that turning it off allows the mixes, that would be fine. (But there could be more issues before any mixes would work.) This would not be the same as targeting being sure that some specific mix(es) would work (all issues handled for the mix). > If more programs were to be built with LTO for performance > reasons, then it might be a good idea to have a global parameter that > controls whether lTO may be used, though. Yep. It avoids needing to find and adjust each individually. > TL;DR >=20 > Perhaps we could add a WITH(OUT)_LTO option that only affects specific > programs that get a significant performance boost from building with > LTO. IMHO, using LTO is preferable to the introduction of inline > functions in source files that fall into that category. >=20 > WITHOUT_LTO could be implied on platforms that are known to not fully > support -flto with default their compiler and linker. And it could be > set by the user when non-default build tools are used. I've no clue if there are platforms for which -flto needs to be avoided in general, even without mixed toolchains getting involved. > This would allow to use -flto for specific programs without the need > to make this optimization conditional on compilers or architectures. FYI: I have disabled attempting to build the failing combination in my environment. There are new non-flto issues also causing more examples of disabled build attempts. But I do not expect that anything disabled was able to boot and operate okay for powerpc64 or for powerpc. > Best regards, STefan >=20 >> --- gh-bc.full --- >> /usr/local/powerpc-unknown-freebsd13.0/bin/ld: = /usr/bin/../lib/LLVMgold.so: error loading plugin: Cannot open = "/usr/bin/../lib/LLVMgold.so" >> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >> *** [gh-bc.full] Error code 1 >>=20 >> Yep: /usr/lib/LLVMgold.so when = -B/usr/local/powerpc-unknown-freebsd13.0/bin/ >> was in use. >>=20 >> I turns out that the link of gh-bc used -flto : >>=20 >> make[4]: stopped in /usr/src/usr.bin/gh-bc >> .ERROR_TARGET=3D'gh-bc.full' >> = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc= /usr/src/powerpc.powerpc/usr.bin/gh-bc/gh-bc.full.meta' >> .MAKE.LEVEL=3D'4' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'cc -target powerpc-unknown-freebsd13.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src= /powerpc.powerpc/tmp -B/usr/local/powerpc-unknown-freebsd13.0/bin/ -O2 = -pipe -fno-common -B/usr/local/powerpc-unknown-freebsd13.0/bin/ = -DMAINEXEC=3Dbc -DNLSPATH=3D/usr/share/nls/%L/%N.cat -DBC_ENABLED = -DBC_ENABLE_PROMPT -DBC_ENABLE_LONG_OPTIONS -DBC_ENABLE_EXTRA_MATH = -DBC_ENABLE_HISTORY -DBC_ENABLE_RAND -DDC_ENABLED -DNDEBUG = -DVERSION=3D3.1.1 -I/usr/src/contrib/bc/include -DBC_ENABLE_NLS=3D1 = -flto -g -std=3Dgnu99 -Wno-format-zero-length -fstack-protector-strong = -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 = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments = -Wl,--secure-plt -o gh-bc.full args.o data.o file.o lang.o lex.o main.o = num.o parse.o program.o read.o vector.o vm.o bc/bc.o bc/lex.o bc/parse.o = dc/dc.o dc/lex.o dc/parse.o history/history.o bc_help.o dc_help.o lib.o = lib2.o opt.o rand/rand.o ;' >> .CURDIR=3D'/usr/src/usr.bin/gh-bc' >> .MAKE=3D'make' >> = .OBJDIR=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/= powerpc.powerpc/usr.bin/gh-bc' >> .TARGETS=3D'all' >> = DESTDIR=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/= powerpc.powerpc/tmp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'powerpc' >> MACHINE_ARCH=3D'powerpc' >> MAKEOBJDIRPREFIX=3D'' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20200606' >> = PATH=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/pow= erpc.powerpc/tmp/usr/sbin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.p= owerpc/usr/src/powerpc.powerpc/tmp/usr/bin:/usr/obj/powerpcvtsc_clang_altb= inutils/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/sbin:/usr/o= bj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/t= mp/legacy/usr/bin:/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/u= sr/src/powerpc.powerpc/tmp/legacy/bin:/usr/obj/powerpcvtsc_clang_altbinuti= ls/powerpc.powerpc/usr/src/powerpc.powerpc/tmp/legacy/usr/libexec::/sbin:/= bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> = OBJTOP=3D'/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/p= owerpc.powerpc' >> .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.powerpc-clang_altbinutils-bootstrap.amd64-host = /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/usr.bin/gh-bc/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.init.mk = /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk = /usr/src/usr.bin/gh-bc/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.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.man.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/usr.bin/gh-bc /usr/src/contrib/bc/src = /usr/src/contrib/bc/gen /usr/src/contrib/bc/manuals = /usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.pow= erpc/usr.bin/gh-bc' >> 1 error >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)