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.
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
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).
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
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
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.
My guess is that the patch disturbed the analysis of the reallocation path by simplifying it to memcpy. The simplification allowed the faulty analysis to come to the wrong conclusion; previously the code was too complicated.
I also think it's a regression compared to when I wrote the patch, since I think I ran the entire test suite. If so I'll bisect to find the offender.
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
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
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
On Wed, May 20, 2026 at 12:00 PM Jonathan Wakely jwakely.gcc@gmail.com 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, 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
linaro-toolchain@lists.linaro.org
-
Avi Kivity -
Jonathan Wakely