Advice debugging M1Mac check errors

M1mac numerical issues should be rare, but when they do pop up they can be disconcerting.

The following little script reveals what happens with no extended precision. A few months
ago I built this into a "package" and used https://mac.r-project.org/macbuilder/submit.html
to run it, getting the indicated result of 0 for (sum(vv1) - 1.0e0), with non-zero on my
Ryzen 7 laptop.

JN

# FPExtendedTest.R   J C Nash
loopsum <- function(vec){
    n <- length(vec)
    vsum<-0.0
    for (i in 1:n) { vsum <- vsum + vec[i]}
    vsum
}
small<-.Machine$double.eps/4 # 1/4 of the machine precision
vsmall <- rep(small, 1e4) # a long vector of small numbers
vv1 <- c(1.0, vsmall) # 1 at the front of this vector
vv2 <- c(vsmall, 1.0) # 1 at the end
(sum(vv1) - 1.0e0) # Should be > 0 for extended precision, 0 otherwise
(sum(vv2) - 1.0e0) # Should be > 0
(loopsum(vv1) - 1.0e0) # should be zero
(loopsum(vv2) - 1.0e0) # should be greater than zero

We were left to guess, but I doubt this has to do with the lack of 'extended precision' nor long doubles longer than 
doubles on arm64 macOS.? And issues with that are rather rare (much rarer than numerical issues for non-reference x86_64 
BLAS/LAPACKs).? Of the 20,300 CRAN packages just 18 have M1mac-specific errors, none obviously from numerical 
inaccuracy.? A quick look back suggests we get about 20 a year with M1mac numerical issues, about half of which were 
mirrored on the x86_64 'noLD' checks.