NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: toolchain/51094: repeatable file-system corruption: 7.99.2{7,8} i386/athlon gcc-5.3.0



On Thu, Apr 28, 2016 at 08:00:02PM +0000, matthew green wrote:
> The following reply was made to PR toolchain/51094; it has been noted by GNATS.
> 
> From: matthew green <mrg%eterna.com.au@localhost>
> To: Jim Bernard <jbernard%mines.edu@localhost>
> Cc: toolchain-manager%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost,
>     netbsd-bugs%NetBSD.org@localhost, gnats-bugs%NetBSD.org@localhost
> Subject: re: toolchain/51094: repeatable file-system corruption: 7.99.2{7,8} i386/athlon gcc-5.3.0
> Date: Fri, 29 Apr 2016 05:57:28 +1000
> 
>  i have commited a hack to amd64 kernel builds to use this option
>  for ufs_lookup.c only.  if you update it should work without any
>  special options.  (i was running a kernel with everything built
>  -fno-tree-vrp -Wno-error=maybe-uninitialized to avoid the issues
>  you mentioned, but they don't apply to the problem source.)

I can confirm that using -fno-tree-vrp on just this file fixes the problem
for me.  Since my cpu is a 32-bit cpu, instead of using this change to the
amd64 Makefile, I just put it into my kernel config, passing it via
CPUOPTS, rather than COPTS with:

makeoptions	"CPUFLAGS.ufs_lookup.c"+="-fno-tree-vrp"

>  ideally, someone should do something like this:
>  
>  remove this hack and instead apply it directly inside ufs_lookup.c
>  itself.  there are only a relatively small number of functions so
>  it shouldn't be too hard to binary search.  you can use (i believe)
>  __attribute__((__optimize__("no-tree-vrp"))) on each function to
>  turn it off just here, and then test against a known failing case.

That works.  The function is ufs_direnter().  It's a fairly long one, though.

-- Jim



Home | Main Index | Thread Index | Old Index