On Wed, Sep 18, 2019 at 9:46 AM Enji Cooper <yaneurab...@gmail.com> wrote: > > > > On Sep 18, 2019, at 07:33, Enji Cooper <yaneurab...@gmail.com> wrote: > > > > > >>> On Sep 18, 2019, at 05:40, Kyle Evans <kev...@freebsd.org> wrote: > >>> > >>> On Wed, Sep 18, 2019 at 7:34 AM Enji Cooper <yaneurab...@gmail.com> wrote: > >>> > >>> > >>>> On Sep 17, 2019, at 18:58, Kyle Evans <kev...@freebsd.org> 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 llvm: IR > >>>> representation of some routine for the MIPS targets is a function with a > >>>> large number of arguments. This then leads the compiler on an hour+ 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 mips 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 for > >> 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 this > >> 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 for 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 whether > > 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’s a build performance > issue... Is this impacting CI pipelines? >
It is the latter, and I do not want to *blacklist* them because as far 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’s per-architecture options, is that it can be > > very heavy handed enabling/disabling features. I’m 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’m not asking for a revert, it would be really nice if whole features > weren’t disabled, unless there’s an issue 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 completely 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 the world. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
