From owner-svn-src-head@freebsd.org Wed Sep 18 15:26:22 2019 Return-Path: Delivered-To: svn-src-head@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 DCBBF121208 for ; Wed, 18 Sep 2019 15:26:22 +0000 (UTC) (envelope-from kevans@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 46YP2k5cG3z4S8H for ; Wed, 18 Sep 2019 15:26:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 91F651E60 for ; Wed, 18 Sep 2019 15:26:22 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f180.google.com with SMTP id c3so177881qtv.10 for ; Wed, 18 Sep 2019 08:26:22 -0700 (PDT) X-Gm-Message-State: APjAAAW5ha0XJF0lhDg5BzPoC5iU39ZtynxSD1Oz5o7QkzEvgYUEVsPc qu6S/urlq9BLGX8TUjjbKUcn/XWQLvRbPE41O9U= X-Received: by 2002:ac8:2bca:: with SMTP id n10mt4641633qtn.242.1568820382118; Wed, 18 Sep 2019 08:26:22 -0700 (PDT) MIME-Version: 1.0 References: <201909180158.x8I1wuZu011258@repo.freebsd.org> <0FBC9A62-AE3B-4F27-AABC-06FF45F415F1@gmail.com> <81382CF5-A928-48EF-93A9-BBBBA174F4BD@gmail.com> In-Reply-To: From: Kyle Evans Date: Wed, 18 Sep 2019 10:26:10 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r352465 - head/share/mk Cc: Enji Cooper , src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 15:26:22 -0000 On Wed, Sep 18, 2019 at 10:13 AM Kyle Evans wrote: > > On Wed, Sep 18, 2019 at 10:04 AM Enji Cooper wrot= e: > > > > > > > On Sep 18, 2019, at 07:58, Kyle Evans wrote: > > > > > >> On Wed, Sep 18, 2019 at 9:46 AM Enji Cooper = wrote: > > >> > > >> > > >>> On Sep 18, 2019, at 07:33, Enji Cooper wrot= e: > > >>> > > >>> > > >>>>> On Sep 18, 2019, at 05:40, Kyle Evans wrote: > > >>>>> > > >>>>> On Wed, Sep 18, 2019 at 7:34 AM Enji Cooper wrote: > > >>>>> > > >>>>> > > >>>>>> On Sep 17, 2019, at 18:58, Kyle Evans wrote= : > > >>>>>> > > >>>>>> Author: kevans > > >>>>>> Date: Wed Sep 18 01:58:56 2019 > > >>>>>> New Revision: 352465 > > >>>>>> URL: https://svnweb.freebsd.org/changeset/base/352465 > > >>>>>> > > >>>>>> Log: > > >>>>>> googletest: default-disable on all of MIPS for now > > >>>>>> > > >>>>>> Parts of the fusefs tests trigger a bug in current versions of l= lvm: IR > > >>>>>> representation of some routine for the MIPS targets is a functio= n with a > > >>>>>> large number of arguments. This then leads the compiler on an ho= ur+ long > > >>>>>> goose chase, which is OK if you build the current tree but less-= so if you're > > >>>>>> trying external toolchain or doing a universe build involving mi= ps when it > > >>>>>> eventually gets switched over to LLVM. > > >>>>>> > > >>>>>> Better, accurate details can be found in LLVM PR43263. > > >>>>> > > >>>>> Uhhhhh... why not do this in tests/sys/... instead? > > >>>> > > >>>> Because there's still value in being able to easily enable these f= or > > >>>> building/running the complete set of tests through standard build > > >>>> infrastructure, but it's not worth adding a knob specifically for = the > > >>>> fusefs tests. I also prefer the communication of it being an > > >>>> off-by-default option and easily deduced from src.conf(5) that thi= s > > >>>> part of the build is default-disabled on mips/mips. > > >>> > > >>> Let me rephrase things a bit: is googlemock broken for all of mips,= or is it just the tests? If the latter, the tests should be blacklisted fo= r mips with a justification. If the former, I agree your method of dealing = with the situation is ok, but more investigation needs to be done to see wh= ether or not the port (in general) is broken and mark it broken if need be. > > >> > > >> It looks like the latter case, based on the PR, and it=E2=80=99s a b= uild performance issue... Is this impacting CI pipelines? > > >> > > > > > > It is the latter, and I do not want to *blacklist* them because as fa= r > > > as I can tell, the tests aren't necessarily broken. I want to > > > workaround them for default by now. > > > > > >>> The problem with src.opts.mk=E2=80=99s per-architecture options, is= that it can be very heavy handed enabling/disabling features. I=E2=80=99m = not sure that everything in there warrants disabling at that level. > > >> > > >> My investigation suggests that the course of action was overly heavy= handed. While I=E2=80=99m not asking for a revert, it would be really nice= if whole features weren=E2=80=99t disabled, unless there=E2=80=99s an issu= e with the feature. > > >> > > > > > > We do not have a lighter method for dealing with this that I can tell= , > > > because as I said above: I do not want to blacklist them or completel= y > > > kill them off. I still want the option to build and test them, but as > > > I aim to switch mips over to llvm I do not want to subject CI and the > > > rest of the world to an extra 1.5+ hour build time for this during > > > tinderbox runs. > > > > > > Given that it's mips, so already tier-high, and I'm one of few people > > > that care about it (and I only care about it for the time being), I > > > intend to leave it as-is since it's still a default in the rest of th= e > > > world. > > > > Ok, valid straw man argument: in this particular case, should llvm / c+= + support be disabled instead, since it=E2=80=99s the real underlying issue= ? I=E2=80=99m guessing (non-ancient) g++ doesn=E2=80=99t have this issue. > > > > Again, disabling a framework because of a single issue in the tests doe= sn=E2=80=99t make sense. Unless you have proof that the build times for all= of googletest/googlemock with llvm is an issue, this seems like the wrong = remediation to perform. > > > > -Enji > > > > PS A heads up to asomers and myself would have been nice. I don=E2=80= =99t like post-commit nitpicking, since the issue could have been discussed= /reviewed before commit. > > If this was any less than a temporary workaround that will get > reverted in due time, I would sympathize with your argument > completely. I had no intention of wasting your time or asomers' time > with this tier-2 problem that had already been diagnosed as an > LLVM/mips bug. > > The unfortunate reality is that no one (including CI) is running tests > on FreeBSD/mips, and no one will feel the fallout of this decision. Sorry, this was supposed to read: "this decision, and anyone else will simply flip it back on for MIPS in the meantime."