[Rd] array-bound error with GCC 13/14

[Tomas Kalibera]

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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel