On Wed, May 20, 2026 at 12:00 PM Jonathan Wakely <[email protected]> wrote:
> I'm not sure yet another bug about these middle end warnings is useful! > I'll let somebody else decide that. > You can ignore it though, your patch isn't the problem here, it just > revealed it. > > But won't it bother others who run the testsuite? > > > On Wed, 20 May 2026, 09:17 Avi Kivity, <[email protected]> wrote: > >> >> >> On Tue, May 19, 2026 at 4:03 PM Jonathan Wakely <[email protected]> >> wrote: >> >>> On Tue, 19 May 2026 at 11:57, Jonathan Wakely <[email protected]> >>> wrote: >>> > >>> > On Tue, 19 May 2026 at 10:29, Avi Kivity <[email protected]> wrote: >>> > > >>> > > >>> > > >>> > > On Tue, May 19, 2026 at 11:03 AM Avi Kivity <[email protected]> >>> wrote: >>> > >> >>> > >> >>> > >> >>> > >> On Tue, May 19, 2026 at 2:22 AM <[email protected]> wrote: >>> > >>> >>> > >>> Dear contributor, >>> > >>> >>> > >>> Our automatic CI has detected problems related to your patch(es). >>> Please find some details below. >>> > >>> >>> > >>> In aarch64 native, after: >>> > >>> | commit gcc-17-570-g79e29562907b >>> > >>> | Author: Avi Kivity <[email protected]> >>> > >>> | Date: Thu Feb 26 19:59:41 2026 +0200 >>> > >>> | >>> > >>> | libstdc++: optimize std::uninitialized_move{,_n}() to >>> memcpy when possible [PR121789] >>> > >>> | >>> > >>> | std::uninitialized_move{,_n} delegates to the corresponding >>> > >>> | std::uninitialized_copy() variant after wrapping with a >>> move >>> > >>> | iterator, but the std::uninitialized_copy() doesn't unwrap >>> the >>> > >>> | ... 17 lines of the commit log omitted. >>> > >>> >>> > >>> Produces 1 regression: >>> > >>> | >>> > >>> | regressions.sum: >>> > >>> | Running g++:g++.dg/torture/dg-torture.exp ... >>> > >>> | FAIL: g++.dg/torture/pr118521.C -O1 (test for excess errors) >>> > >> >>> > >> >>> > >> I'll take a look. >>> > > >>> > > >>> > > In file included from /mnt/gcc.bin/include/c++/17.0.0/vector:67, >>> > > from ./gcc/testsuite/g++.dg/torture/pr118521.C:5: >>> > > In function ‘_ForwardIterator >>> std::uninitialized_fill_n(_ForwardIterator, _Size, const _Tp&) [with >>> _ForwardIterator = char*; _Size = long unsigned int; _Tp = char]’, >>> > > inlined from ‘constexpr _ForwardIterator >>> std::__uninitialized_fill_n_a(_ForwardIterator, _Size, const _Tp&, >>> allocator<_Tp>&) [with _ForwardIterator = char*; _Size = long unsigned int; >>> _Tp = char; _Tp2 = char]’ at >>> /mnt/gcc.bin/include/c++/17.0.0/bits/stl_uninitialized.h:778:39, >>> > > inlined from ‘constexpr void std::vector<_Tp, >>> _Alloc>::_M_fill_append(size_type, const value_type&) [with _Tp = char; >>> _Alloc = std::allocator<char>]’ at >>> /mnt/gcc.bin/include/c++/17.0.0/bits/vector.tcc:776:36, >>> > > inlined from ‘constexpr void std::vector<_Tp, >>> _Alloc>::_M_fill_insert(iterator, size_type, const value_type&) [with _Tp = >>> char; _Alloc = std::allocator<char>]’ at >>> /mnt/gcc.bin/include/c++/17.0.0/bits/vector.tcc:668:20, >>> > > inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator >>> std::vector<_Tp, _Alloc>::insert(const_iterator, size_type, const >>> value_type&) [with _Tp = char; _Alloc = std::allocator<char>]’ at >>> /mnt/gcc.bin/include/c++/17.0.0/bits/stl_vector.h:1565:16, >>> > > inlined from ‘void foo()’ at >>> ./gcc/testsuite/g++.dg/torture/pr118521.C:12:11: >>> > > /mnt/gcc.bin/include/c++/17.0.0/bits/stl_uninitialized.h:577:39: >>> warning: ‘void* __builtin_memset(void*, int, long unsigned int)’ writing 2 >>> bytes into a region of size 0 overflows the destination >>> [-Wstringop-overflow=] >>> > > 577 | __builtin_memset(__dest, (unsigned >>> char)__x, __n); >>> > > | >>> ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > > >>> > > I think it's a victim of an existing (and very annoying) >>> misdetection of memory overwrites ( >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125187). It's not directly >>> related to my patch (which optimizes moving a range, not filling it), but >>> my patch changes the detection logic causing gcc to think the region is of >>> size 0 (where it should be 4). >>> > >>> > Yes, these middle-end warnings are a plague, but I don't see why your >>> > patch (which I pushed yesterday) changes the >>> > __uninitialized_fill_n_a() path which uses memset. Your patch only >>> > affects the uninitialized_copy() path which uses memcpy. >>> >>> The __uninitialized_fill_n_a function on line 776 is only used when >>> there's enough room for it: >>> >>> if (size_type(this->_M_impl._M_end_of_storage >>> - this->_M_impl._M_finish) >= __n) >>> { >>> _GLIBCXX_ASAN_ANNOTATE_GROW(__n); >>> this->_M_impl._M_finish = >>> std::__uninitialized_fill_n_a(this->_M_impl._M_finish, __n, __x, >>> _M_get_Tp_allocator()); >>> >>> But the poxy warning decides maybe there's some way to reach it where >>> (end_of_storage - finish) == 0. >>> >>> As Avi said, it's likely that the else branch for the condition above >>> got simplified by the patch, which allowed GCC to make better (and >>> then eventually, much worse) analysis for the call above. >>> >>> >>> >> How to proceed? >> >> I suggest to file a bug and mark the failure as XFAIL. >> >> >> >>> >>> >>> >>> >>> > >>> > >>> > >>> > >>> > > >>> > > I enhanced the test code to be a full program and verified it works >>> with asan. >>> > > >>> > > I'm not sure how to proceed. I don't want to patch pr118521.C to >>> disable -Wstringop-overflow, since that's what it's testing. >>> > > >>> > > Copying Richard, the original author of the test >>> (a2755339c6c9832467c573d956e91565943ecdc1). >>> > > >>> > >> >>> > >> >>> > >>> >>> > >>> >>> > >>> Used configuration : >>> > >>> *CI config* tcwg_gcc_check aarch64-linux-gnu >>> > >>> *configure and test flags:* none, autodetected on >>> aarch64-unknown-linux-gnu--disable-multilib --enable-fix-cortex-a53-835769 >>> --enable-fix-cortex-a53-843419 --with-arch=armv8-a >>> > >>> >>> > >>> We track this bug report under >>> https://linaro.atlassian.net/browse/GNU-1906. Please let us know if you >>> have a fix. >>> > >>> >>> > >>> If you have any questions regarding this report, please ask on >>> [email protected] mailing list. >>> > >>> >>> > >>> >>> -----------------8<--------------------------8<--------------------------8<-------------------------- >>> > >>> >>> > >>> The information below contains the details of the failures, and >>> the ways to reproduce a debug environment: >>> > >>> >>> > >>> You can find the failure logs in *.log.1.xz files in >>> > >>> * >>> http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/10197/archive/artifacts/00-sumfiles/ >>> > >>> The full lists of regressions and improvements as well as >>> configure and make commands are in >>> > >>> * >>> http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/10197/archive/artifacts/notify/ >>> > >>> The list of [ignored] baseline and flaky failures are in >>> > >>> * >>> http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/10197/archive/artifacts/sumfiles/xfails.xfail >>> > >>> >>> > >>> Current build : >>> http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/10197/archive/artifacts/ >>> > >>> Reference build : >>> http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/10196/archive/artifacts/ >>> > >>> >>> > >>> Instruction to reproduce the build : >>> https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/gcc/sha1/79e29562907b454cdb867195b34cf63156d2d0cc/tcwg_gcc_check/master-aarch64/reproduction_instructions.txt >>> > >>> >>> > >>> Full commit : See in git+ssh://[email protected]/git/gcc.git >>> >>
