Re: [Rd] array-bound error with GCC 13/14
> On 9 May 2025, at 19:29, Kevin Ushey wrote: > > Hopefully a member of the CRAN team will tell me I'm wrong, but I > think whether or not there is a compiler bug is ultimately irrelevant > -- packages on CRAN must compile cleanly even with potentially-buggy > development versions of compilers. I disagree. This would be even worse than rejecting packages that use deprecated code. xref: https://github.com/nx10/httpgd/issues/218 > > So, whether or not there is a bug in gcc is moot -- you'll need to > find a way to avoid triggering this issue in your package code. > > Best, > Kevin > > On Fri, May 9, 2025 at 6:18 AM Ivan Krylov via R-devel > wrote: >> >> В Fri, 9 May 2025 11:09:22 +1000 >> Stephen Wade пишет: >> >>>inlined from ‘std::vector literanger::adjust_pvalues(const >>> std::vector&)’ 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); >> >> The same problem (different reproducer, slightly different warning, but >> same place in the standard library and similar circumstances) has been >> reported as a false positive in GCC, Bug 109717: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 >> >> There are comments by GCC developers acknowledging that the overflow >> detection may "detect" overflows in code paths that cannot be taken, >> but they don't see an easy way to fix the warnings on the compiler side. >> >> -- >> Best regards, >> Ivan >> >> __ >> 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 -- benz0li.b-data.io | @benz0li | olivier.b...@b-data.ch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] array-bound error with GCC 13/14
В Fri, 9 May 2025 11:09:22 +1000 Stephen Wade пишет: > inlined from ‘std::vector literanger::adjust_pvalues(const > std::vector&)’ 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); The same problem (different reproducer, slightly different warning, but same place in the standard library and similar circumstances) has been reported as a false positive in GCC, Bug 109717: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 There are comments by GCC developers acknowledging that the overflow detection may "detect" overflows in code paths that cannot be taken, but they don't see an easy way to fix the warnings on the compiler side. -- Best regards, Ivan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] array-bound error with GCC 13/14
Hopefully a member of the CRAN team will tell me I'm wrong, but I think whether or not there is a compiler bug is ultimately irrelevant -- packages on CRAN must compile cleanly even with potentially-buggy development versions of compilers. So, whether or not there is a bug in gcc is moot -- you'll need to find a way to avoid triggering this issue in your package code. Best, Kevin On Fri, May 9, 2025 at 6:18 AM Ivan Krylov via R-devel wrote: > > В Fri, 9 May 2025 11:09:22 +1000 > Stephen Wade пишет: > > > inlined from ‘std::vector literanger::adjust_pvalues(const > > std::vector&)’ 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); > > The same problem (different reproducer, slightly different warning, but > same place in the standard library and similar circumstances) has been > reported as a false positive in GCC, Bug 109717: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717 > > There are comments by GCC developers acknowledging that the overflow > detection may "detect" overflows in code paths that cannot be taken, > but they don't see an easy way to fix the warnings on the compiler side. > > -- > Best regards, > Ivan > > __ > 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
