Tuning tests cover optimize zero

[ckormanyos]

I'd like to see how GCOV/LCOV play out with optimization zero -O0. It seems like we try and try for some cover lines that are elusive, even though other debug sessions show the lines clearly covered.

The GCOV/LCOV run is not very long, so hopefully -O0 won't influence the runner job length all that much.

Let's see if this is better, worse or the same.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.5%. Comparing base (fc669ff) to head (0fdffe5).
⚠️ Report is 7 commits behind head on develop.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #1336     +/-   ##
=========================================
- Coverage     98.9%   98.5%   -0.3%     
=========================================
  Files          283     282      -1     
  Lines        18327   22542   +4215     
  Branches      1939    1960     +21     
=========================================
+ Hits         18109   22190   +4081     
- Misses         218     352    +134     

Files with missing lines	Coverage Δ
include/boost/decimal/detail/cmath/lgamma.hpp	100.0% <100.0%> (+20.7%)	⬆️
test/test_acosh.cpp	100.0% <100.0%> (ø)
test/test_atanh.cpp	100.0% <100.0%> (ø)
test/test_lgamma.cpp	100.0% <100.0%> (ø)
test/test_zeta.cpp	100.0% <100.0%> (ø)

... and 240 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fc669ff...0fdffe5. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ckormanyos]

I don't like the switch from -O1 to -O0 since the changes are too large, including almost $5,000$ new lines and different coverage numbers. I hadn't expexcted such a large delta. There is too much experience at-O1 to warrant this change now. I'm switching back and re-running.

[mborland]

I don't like the switch from -O1 to -O0 since the changes are too large, including almost 5 , 000 new lines and different coverage numbers. I hadn't expexcted such a large delta. There is too much experience at-O1 to warrant this change now. I'm switching back and re-running.

I didn't realize that we were using O1 instead of O0. I think -O0 might be better because then we know what lines we are actually hitting as opposed to what the optimizer is choosing for us.

[ckormanyos]

I don't like the switch from -O1 to -O0

I didn't realize that we were using -O1 instead of -O0. I think -O0 might be better because then we know what lines we are actually hitting as opposed to what the optimizer is choosing for us.

That's fine too. Basically, we get about $5,000$ more lines total at -O0. We fall down to $98.5\%$ coverage, which is still quite high.

The disadvantage would be a slight retihinking in the project.
The advantage would be more clear coverage info.
I'll let this run through at -O1 then switch back to -O0 and be patient enough to let it run through.

We can take a look at -O0 then next week and decide if we want to go that way.

[ckormanyos]

OK I'll summarize here

Oprimization	Total Lines	Hits	Misses	Percent	Git Hash
-O1	18,332	18,118	214	98.9	c46e0cd
-O0	22,542	22,190	352	98.5	0fdffe5

I'm fine with either -O0 (which is a change from what we have) or -O1 (which is what we have).

I guess from a hopefully neutral, non-subjective tooling point of view, -O0 gives a more clear picture of the lines actually being hit since fewer optimizations are happening under the hood.

This PR at this moment is built with -O0 on the coverage job.

Let me know what you think Matt.