After (a lot) more work, including looking for MWE (see
https://godbolt.org/z/38nnaEcrf), I am confident this is a bug which
has already been resolved:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415.
The bug only occurs when optimisation is enabled (-O1 to -O3 at
least), on GCC 12.4, 13.1--13.3, and 14.1--14.2.
The question is "what is the correct remedy for the package on CRAN"?
Making the code _unnecessarily_ complicated compels GCC to avoid an
optimisation pattern that is causing the warning, e.g.
inline std::vector<double> adjust_pvalues(const std::vector<double> &
unadjusted) {
const size_t n_pvalue = unadjusted.size();
if (n_pvalue < 2) {
#if ( __GNUC__ == 12 && __GNUC_MINOR__ > 3 && __GNUC_MINOR__ < 5 ) || \
( __GNUC__ == 13 && __GNUC_MINOR__ < 4 ) || \
( __GNUC__ == 14 && __GNUC_MINOR__ < 3 )
std::vector<double> kludge(n_pvalue);
kludge = unadjusted;
return kludge; /* no warning produced */
#else
return unadjusted;
#endif
}
std::vector<double> adjusted(n_pvalue, 0);
/* Do some other stuff */
return adjusted;
}
That is _not_ "good" code practice (in my view). I would only put this
in a `cran_release` branch of the repository because it's not
something I'd like to see in `main`. That means a (manual) merge into
`cran_release` each time I release the package for the next few years
until CRAN uses compilers that don't produce that warning. Annoying,
but not a deal-breaker. All this tells me (not that it is a bad
policy) that the CRAN policy isn't always going to produce the best
outcome in terms of code practise (again, in my view).
On Mon, May 12, 2025 at 10:02 PM Tomas Kalibera
<tomas.kalib...@gmail.com> wrote:
>
>
> On 5/9/25 03:09, Stephen Wade wrote:
> > The literanger package is no longer passing on CRAN
> > (https://CRAN.R-project.org/package=literanger) due to array-bound
> > warnings in GCC 13.3 and 14.2 (more details below).
> >
> > This _looks_ to me like one of either a) a compiler bug, b) a false
> > positive, or c) (very unlikely) something in the standard library
> > implementation.
> >
> > Have others seen warnings like this recently, and if so, what have you
> > done about them? The warning did not appear in clang, nor with GCC
> > 15.1.0 on CRAN's Fedora test service.
> >
> > Firstly, the relevant code snippet:
> >
> > /** Compute adjusted p-values using Benjamini/Hochberg method */
> > inline std::vector<double> adjust_pvalues(const std::vector<double> &
> > unadjusted) {
> >
> > const size_t n_pvalue = unadjusted.size();
> > if (n_pvalue < 2) return unadjusted; /* <-- WARNING HERE */
> >
> > std::vector<double> adjusted(n_pvalue, 0);
> > /* Do some other stuff */
> > return adjusted;
> >
> > }
> >
> >
> > Secondly, the warning (on my own machine, using GCC 13.2.0, which also
> > has this problem):
> >
> > inlined from ‘std::vector<double> literanger::adjust_pvalues(const
> > std::vector<double>&)’ at ../src/literanger/utility_math.h:99:48:
> > /usr/include/c++/13/bits/stl_algobase.h:437:30: warning: ‘void*
> > __builtin_memmove(void*, const void*, long unsigned int)’ writing
> > between 9 and 9223372036854775807 bytes into a region of size 8
> > overflows the destination [-Wstringop-overflow=]
> > 437 | __builtin_memmove(__result, __first, sizeof(_Tp) *
> > _Num);
>
> Perhaps you could try creating a minimal reproducible example,
> standalone C++ program, which still reproduces the warning, and report
> to GCC (or libstdc++). You may get a response it is a duplicate of the
> bug Ivan identified, but it still might be useful to have that
> confirmed. It might also become clearer which problem the compiler seems
> to see there - so give a hint for a workaround.
>
> Even if it gets confirmed as a compiler bug, it might be useful to work
> it around when possible so that your code builds cleanly, particularly
> if it doesn't complicate the code much. We are doing the same thing with
> various warnings in base R - we try to simplify/change the code to help
> the compiler see it is correct. Also, sometimes one finds on the way
> that there actually is a (sometimes theoretical but, still) problem.
>
> Once you have a minimal reproducible example it might also be easier to
> experiment with work-arounds.
>
> Best
> Tomas
>
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
