On 4 February 2015 at 09:29, Konstantin Belousov <kostikbel_at_gmail.com> wrote: > > So the issue is reproducable in 3 minutes after boot with the following > change in kern_clock.c: > volatile int ticks = INT_MAX - (/*hz*/1000 * 3 * 60); > > 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. Note that -fno-strict-overflow and -fwrapv are equivalent as far as Clang is concerned: | // -fno-strict-overflow implies -fwrapv if it isn't disabled, but | // -fstrict-overflow won't turn off an explicitly enabled -fwrapv. | if (Arg *A = Args.getLastArg(options::OPT_fwrapv, | options::OPT_fno_wrapv)) { | if (A->getOption().matches(options::OPT_fwrapv)) | CmdArgs.push_back("-fwrapv"); | } else if (Arg *A = Args.getLastArg(options::OPT_fstrict_overflow, | options::OPT_fno_strict_overflow)) { | if (A->getOption().matches(options::OPT_fno_strict_overflow)) | CmdArgs.push_back("-fwrapv"); | } > I do not see other way than try one more time. Agreed. As you noted elsewhere the original issue that triggered the revert was fixed by r259609, so we should be able to just re-apply r259045.Received on Wed Feb 04 2015 - 16:45:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC