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 _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.
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
The full lists of regressions and improvements as well as configure and make commands are in
The list of [ignored] baseline and flaky failures are in
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
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 _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.
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
The full lists of regressions and improvements as well as configure and make commands are in
The list of [ignored] baseline and flaky failures are in
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
linaro-toolchain@lists.linaro.org
-
Jonathan Wakely