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.
On Wed, 20 May 2026, 09:17 Avi Kivity, avi@scylladb.com wrote:
On Tue, May 19, 2026 at 4:03 PM Jonathan Wakely jwakely.gcc@gmail.com wrote:
On Tue, 19 May 2026 at 11:57, Jonathan Wakely jwakely.gcc@gmail.com wrote:
On Tue, 19 May 2026 at 10:29, Avi Kivity avi@scylladb.com wrote:
On Tue, May 19, 2026 at 11:03 AM Avi Kivity avi@scylladb.com wrote:
On Tue, May 19, 2026 at 2:22 AM ci_notify@linaro.org 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 avi@scylladb.com | 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 _ForwardIteratorstd::__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>::iteratorstd::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
linaro-toolchain@lists.linaro.org 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/1...
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/1...
The list of [ignored] baseline and flaky failures are in
http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/1...
Current build :
http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/1...
Reference build :
http://54.172.246.49:9090/jobs/tcwg_gcc_check--master-aarch64-build/builds/1...
Instruction to reproduce the build :
https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/gcc/sh...
Full commit : See in git+ssh://linaroci@gcc.gnu.org/git/gcc.git