public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
@ 2023-06-13 15:27 seurer at gcc dot gnu.org
2023-06-14 4:29 ` [Bug other/110239] " redi at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: seurer at gcc dot gnu.org @ 2023-06-13 15:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
Bug ID: 110239
Summary: [14 regression] std/format/functions/format.cc fails
after r14-1648-g628ba410b9265d
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:628ba410b9265dbd4278c1f1b1fadf05348adef2, r14-1648-g628ba410b9265d
make -k check RUNTESTFLAGS="--target_board=unix'{-m32}'
conformance.exp=std/format/functions/format.cc"
FAIL: std/format/functions/format.cc execution test
# of expected passes 1
# of unexpected failures 1
This only happens for 32 bits on a big endian system.
/home/seurer/gcc/git/gcc-trunk/libstdc++-v3/testsuite/std/format/functions/format.cc:368:
void test_pointer(): Assertion 's == (str_int + ' ' + str_int + " 0x0")'
failed.
commit 628ba410b9265dbd4278c1f1b1fadf05348adef2 (HEAD)
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Jun 8 21:35:21 2023 +0100
libstdc++: Fix P2510R3 "Formatting pointers" [PR110149]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug other/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
@ 2023-06-14 4:29 ` redi at gcc dot gnu.org
2023-06-23 18:36 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-14 4:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-06-14
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Target Milestone|--- |14.0
Keywords| |testsuite-fail
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug other/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
2023-06-14 4:29 ` [Bug other/110239] " redi at gcc dot gnu.org
@ 2023-06-23 18:36 ` redi at gcc dot gnu.org
2023-06-26 13:36 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-23 18:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
==55393==ERROR: AddressSanitizer: global-buffer-overflow on address
0x0000004c9324 at pc 0x000000432970 bp 0x7ffe2c7fcf80 sp 0x7ffe2c7fcf78
READ of size 4 at 0x0000004c9324 thread T0
#0 0x43296f in std::pair<unsigned short, wchar_t const*>
std::__format::__parse_integer<wchar_t>(wchar_t const*, wchar_t const*)
/home/jwakely/gcc/14/include/c++/14.0.0/format:301
#1 0x431604 in
std::__format::_Spec<wchar_t>::_S_parse_width_or_precision(wchar_t const*,
wchar_t const*, unsigned short&, bool&,
std::basic_format_parse_context<wchar_t>&)
/home/jwakely/gcc/14/include/c++/14.0.0/format:484
#2 0x432166 in std::__format::_Spec<wchar_t>::_M_parse_precision(wchar_t
const*, wchar_t const*, std::basic_format_parse_context<wchar_t>&)
/home/jwakely/gcc/14/include/c++/14.0.0/format:539
#3 0x430473 in
std::__format::__formatter_str<wchar_t>::parse(std::basic_format_parse_context<wchar_t>&)
/home/jwakely/gcc/14/include/c++/14.0.0/format:806
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug other/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
2023-06-14 4:29 ` [Bug other/110239] " redi at gcc dot gnu.org
2023-06-23 18:36 ` redi at gcc dot gnu.org
@ 2023-06-26 13:36 ` redi at gcc dot gnu.org
2023-06-26 16:43 ` [Bug libstdc++/110239] " cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-26 13:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> ==55393==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x0000004c9324 at pc 0x000000432970 bp 0x7ffe2c7fcf80 sp 0x7ffe2c7fcf78
> READ of size 4 at 0x0000004c9324 thread T0
> #0 0x43296f in std::pair<unsigned short, wchar_t const*>
> std::__format::__parse_integer<wchar_t>(wchar_t const*, wchar_t const*)
> /home/jwakely/gcc/14/include/c++/14.0.0/format:301
That's actually a separate bug that only affects formatting wide strings. I
have a fix for that, but the bug for 32-bit targets is simply:
@@ -2118,7 +2105,7 @@ namespace __format
typename basic_format_context<_Out, _CharT>::iterator
format(const void* __v, basic_format_context<_Out, _CharT>& __fc) const
{
- auto __u = reinterpret_cast<__UINT64_TYPE__>(__v);
+ auto __u = reinterpret_cast<__UINTPTR_TYPE__>(__v);
char __buf[2 + sizeof(__v) * 2];
auto [__ptr, __ec] = std::to_chars(__buf + 2, std::end(__buf),
__u, 16);
Casting the pointer to uint64_t sign extends it, which produces a very large
64-bit integer that doesn't fit in __buf.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2023-06-26 13:36 ` redi at gcc dot gnu.org
@ 2023-06-26 16:43 ` cvs-commit at gcc dot gnu.org
2023-06-26 16:45 ` redi at gcc dot gnu.org
2023-06-29 23:01 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-26 16:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:3bb9f9329c378934541ae4cff9977b7487e97cf0
commit r14-2105-g3bb9f9329c378934541ae4cff9977b7487e97cf0
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Mon Jun 26 14:46:46 2023 +0100
libstdc++: Fix std::format for pointers [PR110239]
The formatter for pointers was casting to uint64_t which sign extends a
32-bit pointer and produces a value that won't fit in the provided
buffer. Cast to uintptr_t instead.
There was also a bug in the __parse_integer helper when converting a
wide string to a narrow string in order to use std::from_chars on it.
The function would always try to read 32 characters, even if the format
string was shorter than that. Fix that bug, and remove the constexpr
implementation of __parse_integer by just using __from_chars_alnum
instead of from_chars, because that's usable in constexpr even in
C++20.
libstdc++-v3/ChangeLog:
PR libstdc++/110239
* include/std/format (__format::__parse_integer): Fix buffer
overflow for wide chars.
(formatter<const void*, C>::format): Cast to uintptr_t instead
of uint64_t.
* testsuite/std/format/string.cc: Test too-large widths.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2023-06-26 16:43 ` [Bug libstdc++/110239] " cvs-commit at gcc dot gnu.org
@ 2023-06-26 16:45 ` redi at gcc dot gnu.org
2023-06-29 23:01 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-26 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk.
This needs to be backported because the formatter is wrong in gcc-13, we just
don't have a test on the branch to reveal the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libstdc++/110239] [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2023-06-26 16:45 ` redi at gcc dot gnu.org
@ 2023-06-29 23:01 ` cvs-commit at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-06-29 23:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110239
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:
https://gcc.gnu.org/g:2d40cd2f199e32f185d4b72db2043e91313ab7f2
commit r13-7511-g2d40cd2f199e32f185d4b72db2043e91313ab7f2
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Mon Jun 26 14:46:46 2023 +0100
libstdc++: Fix std::format for pointers [PR110239]
The formatter for pointers was casting to uint64_t which sign extends a
32-bit pointer and produces a value that won't fit in the provided
buffer. Cast to uintptr_t instead.
There was also a bug in the __parse_integer helper when converting a
wide string to a narrow string in order to use std::from_chars on it.
The function would always try to read 32 characters, even if the format
string was shorter than that. Fix that bug, and remove the constexpr
implementation of __parse_integer by just using __from_chars_alnum
instead of from_chars, because that's usable in constexpr even in
C++20.
libstdc++-v3/ChangeLog:
PR libstdc++/110239
* include/std/format (__format::__parse_integer): Fix buffer
overflow for wide chars.
(formatter<const void*, C>::format): Cast to uintptr_t instead
of uint64_t.
* testsuite/std/format/string.cc: Test too-large widths.
(cherry picked from commit 3bb9f9329c378934541ae4cff9977b7487e97cf0)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-06-29 23:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-13 15:27 [Bug other/110239] New: [14 regression] std/format/functions/format.cc fails after r14-1648-g628ba410b9265d seurer at gcc dot gnu.org
2023-06-14 4:29 ` [Bug other/110239] " redi at gcc dot gnu.org
2023-06-23 18:36 ` redi at gcc dot gnu.org
2023-06-26 13:36 ` redi at gcc dot gnu.org
2023-06-26 16:43 ` [Bug libstdc++/110239] " cvs-commit at gcc dot gnu.org
2023-06-26 16:45 ` redi at gcc dot gnu.org
2023-06-29 23:01 ` cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).