PSA: If you run -current, beware!
John Baldwin
jhb at freebsd.org
Thu Feb 5 16:19:10 UTC 2015
On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
> On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
> > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
> ...
>
> > > > > It is fixed (in the proper meaning of the word, not like worked
> > > > > around,
> > > > > covered by paper) by the patch at the end of the mail.
> > > > >
> > > > > We already have a story trying to enable much less ambitious option
> > > > > -fno-strict-overflow, see r259045 and the revert in r259422. I do
> > > > > not
> > > > > see other way than try one more time. Too many places in kernel
> > > > > depend on the correctly wrapping 2-complement arithmetic, among
> > > > > others
> > > > > are callweel and scheduler.
> > >
> > > Rather than depending on a compiler option, wouldn't it be better/more
> > > robust to change ticks to unsigned, which has specified wrapping
> > > behavior?
> >
> > Yes, but non-trivial. It's also not limited to ticks. Since the compiler
> > knows when it would apply these optimizations, it would be nice if it
> > could
> > warn instead (GCC apparently has a warning, but clang does not). Having
> > people do a manual audit of every signed integer expression in the tree
> > will take a long time.
>
> I think I misunderstood the problem as being limited to ticks,
> which is probably only one symptom of a fundamental change in behaviour
> of the compiler.
> Still, it might be worthwhile start looking at ints that ought to be
> implemented as u_int
I actually agree, I just think we are stuck with -fwrapv in the interval, but
it's probably not a short interval. I think converting ticks to unsigned
would be a good first start.
--
John Baldwin
More information about the freebsd-current
mailing list