Re: [lmi] UBSAN flags

[Greg Chicares]

On 6/4/22 20:19, Greg Chicares wrote:
> On 6/4/22 15:03, Vadim Zeitlin wrote:
>> On Sat, 4 Jun 2022 00:26:14 +0000 Greg Chicares <gchicares@sbcglobal.net> 
>> wrote:
>> 
>> GC> This attempt to compile only 'i7702.cpp' didn't look like
>> GC> it would succeed, so I Ctrl-C'd it after 78 minutes.
[...]
>> it's the -Wduplicated-branches option.
> 
> Confirmed. With that option suppressed, all unit tests build in about
> five minutes ("5:21.16 total").

Here are some measurements that suggest appropriate flags.

These four diagnostics appear while compiling lmi's unit tests:

product_data.cpp:150:1: note: variable tracking size limit exceeded
dbdict.hpp:51:5: note: variable tracking size limit exceeded
input.cpp:251:1: note: variable tracking size limit exceeded
ledger_invariant.cpp:73:1: note: variable tracking size limit exceeded

and that suggests investigating gcc's variable-tracking options.
I've also investigated optimization options. For these experiments,
I temporarily backed out changes that fixed UB (variously, either
uncommitted, committed to local HEAD, or pushed to origin/master),
to make sure we catch all of them.

Key:
  no VTA = -fno-var-tracking-assignments
  no VT  = -fno-var-tracking

This is the command I used for all:

$make build_type=ubsan clean; time UBSAN_OPTIONS=print_stacktrace=1 make 
$coefficiency unit_tests build_type=ubsan >../log 2>&1

Each datum begins with a left-aligned clock time.

5:22.66 -O1 only found two errors:
  input_test.cpp:165:5: runtime error: load of value 25000
  fdlibm_expm1.c:243:13: runtime error: left shift of negative value -2
2:10.97 -O1 no VTA: same two errors

* -O1 is inadequate. It caught only two of three instances of UB.

5:07.56 -O2 three errors:
  any_member.hpp:177:33: runtime error: load of value 80
  input_test.cpp:165:5: runtime error: load of value 25000
  fdlibm_expm1.c:243:13: runtime error: left shift of negative value -2
  -ftime-report: VT + VTA = up to 78% of total, apparently for zero_test
3:25.79 -O2 no VTA: same three errors

* -O2 is the lmi default. It catches all three errors. Oddly,
it's faster than -O1 with VTA, but slower with "no VTA".

4:58.01 -Og same three errors

* -Og is hardly faster than -O2. I've never used -Og before,
whereas we use -O2 all the time, so it doesn't seem worth
the effort to consider -Og for lmi UBSAN builds.

5:30.70 -O3 same three errors, as well as a fourth:
  actuarial_table_test.cpp:24: [illegal memory operations] fails to compile
3:59.64 -O3 no VTA: same four errors
3:47.42 -O3 no VT and no VTA: same four errors
4:01.46 -O3 no VTA; '-ggdb' instead of '-g': same four errors

* -O3 seems best of all, because it identified one more issue.
It doesn't cost much more than -O2. Neither VT nor VTA seems
to help at all in a UBSAN build, which has exactly one purpose
and doesn't need to be used in a debugger; similarly, '-ggdb'
costs the same as '-g' (the measured difference looks like noise),
so I see no need to change the lmi default, which is '-ggdb'.
Another advantage is that we don't regularly exercise -O3,
so adding a routine -O3 UBSAN build lets us find any issue
that might arise only with -O3.

Can you reproduce the 'actuarial_table_test' problem?
Of course, if you find that the problem is not real, and
it's just an artifact of some 'gcc -O3' defect, then I'll
change my recommendation, but for now it's this:

ubsan_options := \
  -fno-omit-frame-pointer \
  -fno-var-tracking-assignments \
  -fsanitize=undefined \
  -ggdb \
  -Wno-duplicated-branches \
  -O3 \

> Maybe we should turn off all warnings for "sanitizer" builds? No: that
> saves zero time ("5:22.59 total"), and while it still catches this:
>   input_test.cpp:165 ... runtime error: load of value 25000
> it doesn't catch the other error you reported (something like bool=2).

Since writing that, I haven't further experimented with it.
I'm curious which warning prevented recognition of the
'any_member.hpp' problem, but ascertaining that would
cost a lot of work for no real gain.