[Bug libstdc++/113376] [14/15 Regression] Confusing notes when using C++17 parallel algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4411.html Keywords||patch --- Comment #7 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654411.html
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4410.html Keywords||patch --- Comment #13 from Jonathan Wakely --- Full patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654410.html (In reply to Kristian Spangsege from comment #12) > These changes look good to me. > > A couple of points: > * Should the `else`s still be there now that the preceding branches > terminate with `break`? Doesn't really matter either way. > * `do_out()` has the same problem as `do_in()`. Yes, addressed in the posted patch. > * If there is already testing of `codecvt`, should a test be added for the > "empty output" case? Yes, addressed in the posted patch. > * This could break code that expects the incorrect behavior. That's true for every bug fix. We should conform to the standard though.
[Bug target/97367] powerpc64 g5 and cell optimizations result in .machine power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 Jonathan Wakely changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2020-Decembe |il/gcc-patches/2024-June/65 |r/560994.html |4217.html --- Comment #8 from Jonathan Wakely --- Updated patch https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654217.html
[Bug libstdc++/115399] std::tr2::dynamic_bitset shift behaves differently from std::bitset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115399 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 --- Comment #5 from Jonathan Wakely --- Fixed on trunk. I'll probably backport it to the release branches at some point.
[Bug libstdc++/113376] [14/15 Regression] Confusing notes when using C++17 parallel algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376 Jonathan Wakely changed: What|Removed |Added Known to fail||14.1.0, 15.0 Known to work||13.3.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.2 Summary|Confusing notes when using |[14/15 Regression] |C++17 parallel algorithms |Confusing notes when using ||C++17 parallel algorithms
[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376 --- Comment #6 from Jonathan Wakely --- (In reply to Pilar Latiesa from comment #3) > It seems that what is missing is a corresponding change in the macro > definition logic. It should have been changed to: > > // Check the user-defined macro for warnings > #if defined(PSTL_USAGE_WARNINGS) > #define _PSTL_USAGE_WARNINGS > #endif > > See > https://github.com/llvm/llvm-project/blob/ > 5ccf19ded09f68bef43275c81c20b0e65f7c0b75/pstl/include/pstl/internal/ > pstl_config.h#L26 The upstream change breaks the previous API though. It looks like users were able to define PSTL_USAGE_WARNINGS=0 or PSTL_USAGE_WARNINGS=1 to request warnings to be off or on, respectively. But the LLVM change means that it only matters whether it's defined or not. This seems to have been a misguided change to make sure *all* macros are used with #ifdef not #if. But that breaks the intended use for some of them. So I think we should either revert the change later in the file which checks _PSTL_USAGE_WARNINGS, or we should take the user-facing macro's value into account when deciding whether to define it: // Check the user-defined macro for warnings #if defined(PSTL_USAGE_WARNINGS) && PSTL_USAGE_WARNINGS != 0 #define _PSTL_USAGE_WARNINGS #endif
[Bug libstdc++/113376] Confusing notes when using C++17 parallel algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113376 --- Comment #5 from Jonathan Wakely --- I think https://github.com/llvm/llvm-project/commit/3b9a1bb1af90db9472340ef2122d3855eb9ba3fc#r142768040 is the real cause of the problem. They wanted to avoid -Wundef errors, so changed all the macro tests to use #ifdef instead of #if That is what requires a change to how _PSTL_USAGE_WARNINGS is defined. It also caused other problems elsewhere downstream: https://github.com/oneapi-src/oneDPL/issues/1602
[Bug driver/115440] unrecognized command-line option '--c++17'; did you mean '--stdc++17'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115440 --- Comment #2 from Jonathan Wakely --- People certainly do write --std, I see it all the time. I don't like it though.
[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.3|12.4 --- Comment #19 from Jonathan Wakely --- Fixed for 12.4 now anyway.
[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- Fixed for 12.4 and 13.3
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Also fixed for 12.4
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #11 from Jonathan Wakely ---
This changes the loop to always run if the input is non-empty, and so return
partial if the destination is empty.
--- a/libstdc++-v3/config/locale/gnu/codecvt_members.cc
+++ b/libstdc++-v3/config/locale/gnu/codecvt_members.cc
@@ -131,10 +131,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// mbsnrtowcs is *very* fast but stops if encounters NUL characters:
// in case we store a L'\0' and then continue, in a loop.
// NB: mbsnrtowcs is a GNU extension
-for (__from_next = __from, __to_next = __to;
-__from_next < __from_end && __to_next < __to_end
-&& __ret == ok;)
+__from_next = __from;
+__to_next = __to;
+while (__from_next < __from_end)
{
+ if (__to_next >= __to_end)
+ {
+ __ret = partial;
+ break;
+ }
+
const extern_type* __from_chunk_end;
__from_chunk_end = static_cast(memchr(__from_next,
'\0',
__from_end
@@ -162,12 +168,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__from_next = __from;
__state = __tmp_state;
__ret = error;
+ break;
}
else if (__from_next && __from_next < __from_chunk_end)
{
// It is unclear what to return in this case (see DR 382).
__to_next += __conv;
__ret = partial;
+ break;
}
else
{
@@ -175,7 +183,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__to_next += __conv;
}
- if (__from_next < __from_end && __ret == ok)
+ if (__from_next < __from_end)
{
if (__to_next < __to_end)
{
@@ -185,7 +193,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*__to_next++ = L'\0';
}
else
- __ret = partial;
+ {
+ __ret = partial;
+ break;
+ }
}
}
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #10 from Jonathan Wakely ---
Whereas the GNU locale has that check inside a loop, which is never entered
when the destination buffer is zero sized, i.e. __to == __to_end
if (__from_next < __from_end && __ret == ok)
{
if (__to_next < __to_end)
{
// XXX Probably wrong for stateful encodings
__tmp_state = __state;
++__from_next;
*__to_next++ = L'\0';
}
else
__ret = partial;
}
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 --- Comment #9 from Jonathan Wakely --- (In reply to Kristian Spangsege from comment #7) > Curiously, this bug does not occur when using the Cygwin or MinGW versions > of GCC. In these cases, the result is `partial` as it should be. I assume > this is because on Cygwin and MinGW, libstdc++ uses a generic locale > implementation that is different from the one ordinarily used on Linux. It has an explicit check for this condition: // It is not clear that __from < __from_end implies __ret != ok // (see DR 382). if (__ret == ok && __from < __from_end) __ret = partial;
[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #8 from Jonathan Wakely --- I assume you mean 14.1.0 Since 382 indeed doesn't seem relevant here, let's unsuspend this.
[Bug c++/59246] GCC should issue runtime error for calling pure virtual function with definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115435 Last reconfirmed|2021-11-10 00:00:00 |2024-6-11 --- Comment #4 from Jonathan Wakely --- On further thought, I think GCC's behaviour of calling the definition if one exists is reasonable (possibly better than aborting the process by calling __cxa_pure_virtual). But when UBsan is active we should diagnose it as requested. Clang doesn't seem to handle this in UBsan, it just always calls __cxa_pure_virtual. I stated in comment 2 that GCC does give a warning about this even if it doesn't diagnose it at runtime. That's only true for a direct call, for indirect calls to the pure virtual function there's no warning, see PR 115435
[Bug c++/115435] New: Issue warning for indirect call to pure virtual function in ctor or dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115435
Bug ID: 115435
Summary: Issue warning for indirect call to pure virtual
function in ctor or dtor
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 87403
Target Milestone: ---
We warn about undefined calls to pure virtual functions from constructors and
destructors:
struct Base {
virtual void f() = 0;
Base() { f(); }
};
: In constructor 'Base::Base()':
:3:15: warning: pure virtual 'virtual void Base::f()' called from
constructor
3 | Base() { f(); }
| ~^~
But for indirect calls we don't warn:
struct Base {
virtual void f() = 0;
Base() { g(); }
void g() { f(); }
};
It would be good if IPA could warn for this case too. After g() is inlined into
the constructor we know that the call to f() is undefined.
I assume this would mean moving the warning from the front end to the middle
end.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug libstdc++/115433] unexpected increase of testsuite execution time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115433
--- Comment #2 from Jonathan Wakely ---
I haven't noticed this myself because my ~/.dejagnurc contains:
if { [info exists v3-use-std-list] } {
# v3-dg-runtest supports running tests with multiple -std options.
set v3_std_list { 98 11 14 17 20 23 26 }
set target_list {
"unix{-D_GLIBCXX_ASSERTIONS,-D_GLIBCXX_USE_CXX11_ABI=0,-m32}" }
} else {
set target_list {
"unix{,-D_GLIBCXX_USE_CXX11_ABI=0,-std=gnu++2b,-std=gnu++11}" }
}
So I run all tests 21 times (seven -std options, each repeated for three target
boards).
[Bug libstdc++/115433] unexpected increase of testsuite execution time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115433
--- Comment #1 from Jonathan Wakely ---
What's the baseline for comparisons, the 13.x releases?
We could make this change for release branches, so that C++20 and C++23 tests
are not also run for C++26:
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -536,10 +536,6 @@ proc v3-dg-runtest { testcases flags default-extra-flags }
{
set min_std [v3-minimum-std $test $default_std $max_std]
if { $min_std > $default_std } {
set std_list $min_std
- if { $min_std != $max_std } {
- # Also test the latest version.
- lappend std_list "$max_std"
- }
} else {
# Only run each test once with the default -std option.
# This avoids increasing the run time for most testers.
That could make a difference, because many of the C++20 tests are very slow to
compile (std::ranges, std::format, std::chrono::parse are all slow to compile).
Another possible culprit is that you now have tbb-devel installed on the test
machine, which causes the PSTL tests to be run instead of skipped. Some of
those are slow too.
[Bug libstdc++/115420] Default constructor of unordered_map deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420 --- Comment #6 from Jonathan Wakely --- We could even do: /home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h:78:58: error: static assertion failed: std::hash specialization is disabled; maybe the correct header has not been included
[Bug libstdc++/115420] Default constructor of unordered_map deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420 --- Comment #5 from Jonathan Wakely --- And if _Check_hash_requirements is defined at namespace scope not inside _Hashtable then the first location is much easier to read: /home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h: In instantiation of 'struct std::_Check_hash_requirements > >':
[Bug libstdc++/115420] Default constructor of unordered_map deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed||2024-06-11
Status|CLOSED |NEW
Ever confirmed|0 |1
Resolution|INVALID |---
--- Comment #4 from Jonathan Wakely ---
If we add this to _Hashtable:
template
struct _Check_hash_requirements : true_type
{
static_assert(is_copy_constructible<_Hash>::value,
"custom hash function must be copy constructible");
static_assert(is_destructible<_Hash>::value,
"custom hash function must be destructible");
};
template
struct _Check_hash_requirements> : true_type
{
static_assert(is_default_constructible>::value,
"the std::hash specialization is disabled");
};
static_assert(_Check_hash_requirements<_Hash>::value, "");
Then the first error is much clearer where the problem lies:
In file included from
/home/jwakely/gcc/15/include/c++/15.0.0/bits/unordered_map.h:33,
from /home/jwakely/gcc/15/include/c++/15.0.0/unordered_map:41,
from un.cc:1:
/home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h: In instantiation of
'struct std::_Hashtable, std::pair, long unsigned int>,
std::allocator, long unsigned
int> >, std::__detail::_Select1st,
std::equal_to >,
std::hash >,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits
>::_Check_hash_requirements > >':
/home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h:221:54: required
from 'class std::_Hashtable, std::pair, long unsigned int>,
std::allocator, long unsigned
int> >, std::__detail::_Select1st,
std::equal_to >,
std::hash >,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >'
221 | static_assert(_Check_hash_requirements<_Hash>::value, "");
| ^
/home/jwakely/gcc/15/include/c++/15.0.0/bits/unordered_map.h:112:18: required
from 'class std::unordered_map, long unsigned
int>'
112 | _Hashtable _M_h;
| ^~~~
un.cc:5:45: required from here
5 | std::unordered_map bar;
| ^~~
/home/jwakely/gcc/15/include/c++/15.0.0/bits/hashtable.h:218:62: error: static
assertion failed: the std::hash specialization is disabled
218 | static_assert(is_default_constructible>::value,
| ^
So let's reopen this as a diagnostic RFE for the library.
[Bug c++/115429] requires clause wrongly accepts unqualified access to inherited static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115429 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-06-11 Keywords||accepts-invalid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed, the requires clause should not do name lookup in the dependent base.
[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421 --- Comment #15 from Jonathan Wakely --- (In reply to Liviu Ionescu from comment #12) > Isn't it possible to fix libstdc++ in order to run static multi-threaded > apps on older systems too? Just link all of libpthread.a as Andrew said.
[Bug libstdc++/115421] Multi-threaded condition_variable app throws when linking as -static on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421 --- Comment #14 from Jonathan Wakely --- This is just a dup of PR 58909
[Bug libstdc++/115399] std::tr2::dynamic_bitset shift behaves differently from std::bitset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115399 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/115402] std::atomic_ref compile-error in compare_exchange_[weak/strong]() and wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402 --- Comment #6 from Jonathan Wakely --- There is a paper being written to address both those issues, but it hasn't been published yet. It should be P3323 when it's ready.
[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410 --- Comment #8 from Jonathan Wakely --- (In reply to user202729 from comment #7) > (In reply to Andrew Pinski from comment #6) > > They can be different due to the way shared libraries work. > > Ah, too bad. > > Is it safe to at least assume that the function pointers inside the virtual > pointer table be equal then? No, there can be multiple definitions of a symbol, with different addresses. The original motivation was to devirtualize the > function call inside something like (though this would be a different PR) > > if(typeid(*x)==typeid(A)) > x->f(); > > then would it be safe to assume `x->_vptr[0] == ::f`? No, but the transformation might be valid anyway. There could be multiple copies of A::f with different addresses, but they all have to have the same effects and so it doesn't matter which one gets called.
[Bug libstdc++/115402] std::atomic_ref compile-error in compare_exchange_[weak/strong]() and wait()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402 --- Comment #5 from Jonathan Wakely --- And https://cplusplus.github.io/LWG/issue4069 too.
[Bug libstdc++/115399] std::tr2::dynamic_bitset shift behaves differently from std::bitset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115399 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-06-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Jonathan Wakely --- The tr2 extensions never even got proposed for standardization and are not in any ISO document at all. They're not well tested and nobody uses them.
[Bug web/115391] Suggest add current size of git repository to git page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391 --- Comment #6 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #3) > Also you can use `--depth=1` to speed up the checkout if you don't need the > full history. Or partial clones, which avoid the problems of truncated history that shallow (i.e. --depth=N) clones have. https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/
[Bug web/115391] Suggest add current size of git repository to git page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391 --- Comment #1 from Jonathan Wakely --- You really shouldn't ever need to start again, you can just do: git fetch origin && git reset --hard origin/master
[Bug driver/115368] Wrong order of gcc include paths on musl systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368 --- Comment #3 from Jonathan Wakely --- Please send patch to the gcc-patches mailing list rather than attaching them here. https://gcc.gnu.org/contribute.html#patches
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949
--- Comment #21 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #20)
> It's nonsense to suggest that only maintainers can make such changes to the
> docs, since it's clear and obvious that GCC does not provide everything the
> standard refers to as "the implementation", that doesn't require specialized
> knowledge.
>
> Unfocused ranting and complaining isn't going to achieve anything. If you're
> not happy with the docs, suggest changes.
For example, anybody could propose something like this:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -136,6 +136,14 @@ designated by @var{byte-size} in the following text.
Refer to the NIST,
IEC, and other relevant national and international standards for the full
listing and explanation of the binary and decimal byte size prefixes.
+GCC only provides part of what the C and C++ standards refer to as
+"an implementation" of the language. To get a conforming hosted implementation
+it is necessary to combine GCC with a C library, libc, which is usually part
+of the operating system, e.g., the GNU C Library provides libc for GNU/Linux
+systems. Some C and C++ programs might require linking to additional libraries
+in order to get a complete hosted implementation, e.g., @option{-lm},
+@option{-latomic}, and @option{-pthread} may be required in some cases.
+
@c man end
@xref{Option Index}, for an index to GCC's options.
I'm sure this could be improved, but it's a concrete suggestion instead of
unfocused complaints.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #20 from Jonathan Wakely --- (In reply to frankhb1989 from comment #19) > It may be quite difficult to improve the docs without the first step from > the maintainers to make the sensible default clear enough. Anyway, whether > the issue a bug or an enhancement depends on how the spec says, but this > does not work when the spec in the doc is just missing. What does "when the spec in the doc is just missing" mean? > Besides the > supported standards (which are specs), users have to guess what features are > expected by default, or silently accept the status quo (everything is by > design). This will need additional communication between the maintainers to > prevent real bugs being ignored, hence, inefficient and error-prone. What **concrete** issue are you talking about? I see nothing actionable in what you've written above. We need communication ... OK. The maintainers communicate. What are you expecting to happen? > This even happens when the spec is clear. For example, [intro.multithread]/1 > explicitly allows the programs under a hosted implementation having > concurrent threads (not in C++98/03, though), and whether multi-threading is > supported in a freestanding implementation is implementation-defined. As > I've checked > (https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Implementation.html) this > entry is missing, which is a bug because it fails to meet the mandated > requirements for conformance in the spec (the standard). It fails to meet the requirements for a freestanding implementation, yes. But not for a hosted implementation. If you have concrete suggestions for changes to the docs, please make them. This bug report is just long, unfocused complaints and so is not going to achieve much. > However, usually > users have no enough knowledge to fix it. Virtually only the maintainers > know what should be here. No *policies* are visible for others. Well it should be pretty obvious from other docs that --enable-threads=single means no threads (for both hosted and freestanding). What "policies" are you asking for? > In this issue, about the some parts of C++, silent degradation of > performance is certainly bad, so keeping `-pthread` away by default makes > sense, esp. for programs without knowledge of multi-threading environment > (which can be at least conforming to C++98/03) as the assumptions. It is > also not a bug in the sense that the standard actually allows > single-threading if the doc bug above is fixed (with the acknowledgement > that single-thread model for host implementations are not conforming after > C++03). If you configure GCC in a non-conforming configuration then it's non-conforming. That's not a bug. If you don't want threads to be disabled, don't disable them when configuring GCC. If you got a build of GCC from somebody else and they configured it in a non-conforming way, you should talk to them. It's not a GCC bug. Anyway, the standard doesn't require that new threads can actually be created, it's always possible for the std::thread constructor to fail due to reaching resource limits, and it's conforming for the limit to be a single thread in the program. > However, chasing for performance over other concerns cannot be the > policy in general. In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937 > the direction is actually the opposite. AFIAK all the primary platforms in > the release criteria (https://gcc.gnu.org/gcc-14/criteria.html) support ELF > and (most of) POSIX, so it seems that preventing to sacrifice the features > available on these platforms is one of the candidate of the policies. But > this is just my guess, and specific for the releases; I fail to find any > closer to guarantees in other GCC docs. So, please clarify such concerned > meta issues to reduce potential disagreements at first. I have absolutely no idea what you're saying here. As stated previously, the standard doesn't say you the compiler needs to be invoked, and GCC never claims that -std=c11 is sufficient to link to libm. It might be an improvement if the GCC manual documented that additional options such as -lm or -pthread might be needed for a conforming environment, and that some parts of "the implementation" need to be provided outside of GCC, e.g. by your OS libc (as stated previously, the C++ library already *does* document that -pthread might be required for std::thread support). It's nonsense to suggest that only maintainers can make such changes to the docs, since it's clear and obvious that GCC does not provide everything the standard refers to as "the implementation", that doesn't require specialized knowledge. Unfocused ranting and complaining isn't going to achieve anything. If you're not happy with the docs, suggest changes. I'm inclined to close this bug because there is nothing actionable here (except "make everything work how I want when I say -std=c11" which seems unlikely to happen).
[Bug c++/115371] Hard to decode error message when fixed underlying type of enum is not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115371 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- . *** This bug has been marked as a duplicate of bug 64758 ***
[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758 Jonathan Wakely changed: What|Removed |Added CC||kamil_tym at wp dot pl --- Comment #8 from Jonathan Wakely --- *** Bug 115371 has been marked as a duplicate of this bug. ***
[Bug other/115241] header-tools scripts not compatible to python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jonathan Wakely --- Fixed on trunk now, thanks for the patch
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 Jonathan Wakely changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||3731.html Keywords||patch --- Comment #9 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653731.html Rerunning benchmarks with this patch would be very welcome.
[Bug c++/115357] template argument deduction/substitution failed on lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115357 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- reported twice *** This bug has been marked as a duplicate of bug 115358 ***
[Bug c++/115358] template argument deduction/substitution failed on lambda function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115358 --- Comment #3 from Jonathan Wakely --- *** Bug 115357 has been marked as a duplicate of this bug. ***
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 --- Comment #8 from Jonathan Wakely --- Yes, but it's only a missed-optimization bug so there are much higher priorities.
[Bug libstdc++/115335] std::span at method is missing feature test macro __cpp_lib_span >= 202311L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115335 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.2 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 14.2, thanks for the report.
[Bug c++/110137] implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137 --- Comment #11 from Jonathan Wakely --- If a program really does need to ensure a particular TU assumes new can modify global memory (e.g. in the TU defining operator new, which makes use of some data structure) then that TU should probably be firewalled from the rest of the program, and not use LTO.
[Bug c++/110137] implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137 --- Comment #10 from Jonathan Wakely --- But replacing operator new is a global property of the program. It seems to me that any translation unit claiming that operator new is sane must imply that it's sane globally. It doesn't make sense for a function assuming A is true to be inlined into a function assuming A is false, when A will actually be the same for both.
[Bug libstdc++/115335] std::span at method is missing feature test macro __cpp_lib_span >= 202311L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115335 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-06-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I updated the macro value but seem to have forgotten to check it in
[Bug libstdc++/100667] [11/12 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jonathan Wakely --- I think this is fixed now then.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #52 from Jonathan Wakely ---
(In reply to Christopher Nerz from comment #45)
> This is a critical bug which renders gcc unusable for safety relevant
> systems using expected/variant or simple ipc.
I don't think your example demonstrates that.
> alignas(8) std::byte buffer[8]; // some buffer
> new (buffer) double{1}; // some completely trivial data
> // reuse memory -> double ends lifetime, uint64 starts lifetime
> std::uint64_t * res = new (buffer) std::uint64_t;
This starts the lifetime of a new object, but it has indeterminate value.
> // *res is allowed to be used as it is the correct pointer returned by
> new
The pointer does point to the new object, but derefencing it causes a read of
an indeterminate value, which is undefined behaviour.
> // *res == 0x3ff0 // and gives correct value
> // The very definition of std::launder says that it is suppose to be
> used as:
> return (*res == *std::launder(reinterpret_cast(buffer)));
It looks like what you're actually trying to do is:
alignas(8) std::byte buffer[8];
new (buffer) double{1};
std::uint64_t* res = std::start_lifetime_as(buffer);
return *res == 0x3ff0;
This is not what std::launder is for.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #51 from Jonathan Wakely --- (In reply to Richard Biener from comment #48) > (In reply to Christopher Nerz from comment #47) > > But shouldn't both give the same value? > > I'm not sure what the standard says to this. Does std::launder(...) > sanitize earlier "undefined behavior"? For example failing to initialize > an object? No. The example appears to be trying to use std::launder as std::start_lifetime_as, but they're not the same.
[Bug libstdc++/105258] std::get_temporary_buffer() does not respect alignment (affects std::stable_sort())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258 Jonathan Wakely changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||3296.html --- Comment #8 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653296.html
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.5 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed on all active branches. Thanks for the report.
[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572 Jonathan Wakely changed: What|Removed |Added CC||martin at martin dot st --- Comment #11 from Jonathan Wakely --- CC Martin Storsjo to see if changing Clang would be possible, or if he has a better idea for the preprocessor check suggested in comment 9. It might be that Clang can't pre-define this macro because it has different values for different mingw/mingw-w64/w64devkit toolchains, and clang wouldn't know which one to be compatible with a priori.
[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572 --- Comment #10 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > I would argue that the root cause is that Clang does not conform to the > platform ABI for mingw-w64, which requires __GXX_TYPEINFO_EQUALITY_INLINE=0 > to be defined. I stand by this comment though. If Clang wants to be able to use libstdc++ headers on Windows, it should be compatible (i.e. define the same ABI-impacting macros) with g++ on Windows.
[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #9 from Jonathan Wakely ---
Right, for Clang we need:
--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -73,7 +73,7 @@ namespace __cxxabiv1
// By default follow the old inline rules to avoid ABI changes.
#ifndef __GXX_TYPEINFO_EQUALITY_INLINE
-# if !__GXX_WEAK__
+# if !__GXX_WEAK__ || defined(_WIN32)
#define __GXX_TYPEINFO_EQUALITY_INLINE 0
# else
#define __GXX_TYPEINFO_EQUALITY_INLINE 1
@@ -188,6 +188,9 @@ namespace std
#endif
#if __GXX_TYPEINFO_EQUALITY_INLINE || __cplusplus > 202002L
+#if ! __GXX_TYPEINFO_EQUALITY_INLINE
+ [[__gnu__::__always_inline__]]
+# endif
_GLIBCXX23_CONSTEXPR inline bool
type_info::operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT
{
Because otherwise the macro gets defined to 1 and so the always_inline
attribute isn't used.
[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #7 from Jonathan Wakely ---
This is the fix I'm suggesting:
--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -188,6 +188,9 @@ namespace std
#endif
#if __GXX_TYPEINFO_EQUALITY_INLINE || __cplusplus > 202002L
+# if ! __GXX_TYPEINFO_EQUALITY_INLINE
+ [[__gnu__::__always_inline__]]
+# endif
_GLIBCXX23_CONSTEXPR inline bool
type_info::operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT
{
[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572
--- Comment #6 from Jonathan Wakely ---
(In reply to Peter Damianov from comment #5)
> #include
> int main() { return typeid(0) == typeid(0); }
>
> The following reproduces for me, although strangely only with -std=c++23 and
> -static-libstdc++.
Because it's constexpr (and so always inline) in C++23, and not in C++20.
I think I probably meant to type c++23 in comment 3.
[Bug libstdc++/105258] std::get_temporary_buffer() does not respect alignment (affects std::stable_sort())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258 --- Comment #7 from Jonathan Wakely --- The patch needs a little refactoring to share code with std::stacktrace, but it will be fixed soon.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #35 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #31) > Bisection points to r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 for > that remaining FAIL as well (and it isn't fixed by the new patch). > > It introduced a new warning which wasn't present before: > > /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437: > warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' > writing between 2 and 9223372036854775806 bytes into a region of size 0 > overflows the destination [-Wstringop-overflow=] I don't know why we only get a warning for C++98 and not other modes, but this seems to fix it: --- a/libstdc++-v3/include/bits/vector.tcc +++ b/libstdc++-v3/include/bits/vector.tcc @@ -933,6 +933,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER const size_type __len = _M_check_len(__n, "vector::_M_range_insert"); + if (__len < (__n + (__old_finish - __old_start))) + __builtin_unreachable(); + pointer __new_start(this->_M_allocate(__len)); pointer __new_finish(__new_start); __try So it looks like the compiler can't tell that _M_check_len(n) doesn't undergo unsigned wraparound.
[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #10 from Jonathan Wakely ---
When deciding whether a key already exists in the hash set we use these
overloads:
template
static __conditional_t<
__and_<__is_nothrow_invocable<_Hash&, const key_type&>,
__not_<__is_nothrow_invocable<_Hash&, _Kt>>>::value,
key_type, _Kt&&>
_S_forward_key(_Kt&& __k)
{ return std::forward<_Kt>(__k); }
static const key_type&
_S_forward_key(const key_type& __k)
{ return __k; }
If the value being inserted, __k, can be hashed directly using the hash
function then we return it unchanged, and then hash it. If it can't be hashed
directly, we convert it to the container's key_type, which is TrimmedStr.
In this case, a std::string can be hash directly without constructing a
TrimmedStr (because of the questionable std::hash specialization using
inheritance). So we don't convert it to TrimmedStr and just hash it directly.
Hashing "foo"s and "foo "s give different hash values, so we do not consider
them to be equivalent keys.
While I think the code is highly questionable, the standard does say that
inserting [first, last) is equivalent to insert(*first) for each iterator, and
that would force an implicit conversion to value_type.
So I'm not sure if the optimization to avoid temporaries (PR 96088) is actually
allowed by the standard.
[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #7)
> I am suspecting it was
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=2c43f5ec9db163696de8691eb529df06c4999bcc which caused the issue.
Ah no, I think you're right about this.
The problem is not std::equal_to, but in std::hash, because it
takes an argument of type std::string not TrimmedStr.
This means that hashing "foo "s does not convert to a TrimmedStr first, so it
hashes the un-trimmed string.
This fixes the code:
template<> struct hash {
bool operator()(const TrimmedStr& s) const noexcept
{ return std::hash{}(s); }
};
I'm not sure if the code is valid or not. It certainly seems like a problem
that a plain std::string can be compared to a TrimmedStr using
std::equal_to *and* can be hashed using std::hash, when
a plain std::string is *not* a TrimmedStr.
Using inheritance this way is a bad idea, certainly for the std::hash
specialization. IMHO also for the TrimmedStr itself.
[Bug libstdc++/115285] [12/13/14/15 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #8 from Jonathan Wakely ---
Or r12-6272-ge3ef832a9e8d6a
I think the testcase is invalid. The unordered_set uses
std::equal_to to decide if a key already exists in the container,
and that just uses operator== which is not defined for TrimmedStr, so it uses
the equality comparison for std::string. When that is used to compare
TrimmedStr("foo") == "foo "s it's equivalent to "foo"s == "foo "s which is
obviously false.
[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852 --- Comment #5 from Jonathan Wakely --- Bug 114600 comment 10 has a std module implementation attached.
[Bug libstdc++/115269] Hardcoded links in 14.1 docs to pages from release 4.3.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115269 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-05-29 --- Comment #1 from Jonathan Wakely --- (In reply to Phil Miller from comment #0) > A couple spots in the current-version documentation seem to spuriously point > to pages specifically from release version 4.3.2: > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/doc/xml/manual/ > using.xml;hb=b644126237a1aa8599f767a5e0bbada1d7286f44#l10 > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/doc/html/manual/ > using.html;hb=b644126237a1aa8599f767a5e0bbada1d7286f44#l7 Just one spot, the html page is generated from the xml.
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #11 from Jonathan Wakely --- Dave, does this fix it for hppa-linux-gnu too?
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- Fixed for 13.4 and 14.2
[Bug c++/110137] implement clang -fassume-sane-operator-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137 --- Comment #7 from Jonathan Wakely --- Thanks for the patch, but patch review happens on the mailing list, not in bugzilla. Please repost to gcc-patches as documented in the submission guidelines, thanks.
[Bug libstdc++/115209] The implementation of concat_view refers to p2542r7 rather than the p2542r8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209 --- Comment #1 from Jonathan Wakely --- As already noted at https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652571.html
[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 --- Comment #11 from Jonathan Wakely --- The fix is in 13.1
[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57025 --- Comment #13 from Jonathan Wakely --- (In reply to Alan Coopersmith from comment #11) > While Solaris 11.3 support has been dropped from gcc now, Jonathan Perkins > from pkgsrc found that just removing the definition of __STDC_VERSION__ > didn't work with some of the illumos headers: > https://github.com/jperkin/notes/blob/main/gcc-cpp-stdc/README.md So the illumos sys/feature_tests.h is using __STD_VERSION__ to mean "the version of the C library to expose for the current language mode", whether that language mode is a C language mode or a C++ one. And that's an entirely reasonable use of it IMHO, and conforms to the C++ standard. I stick by what I said in comment 4: code which assumes that __STDC_VERSION__ being defined implies a C compiler is being used is **broken C++ code**. There is no compliance requirement why GCC should stop defining __STDC_VERSION__, and there's a good reason to keep defining it if defining it is needed (or just helpful) for a target's libc headers. The Cython code quoted in the illumos notes should be fixed to check the __cplusplus condition first, then if __cplusplus is not defined check __STDC_VERSION__. It's just bad code. N.B. since C++23 #include works in C++ anyway: https://wg21.link/P0943R6
[Bug c++/115196] Bad error message when using library functions from versions before they were introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196 --- Comment #4 from Jonathan Wakely --- (In reply to Halalaluyafail3 from comment #0) > This note doesn't seem to be very helpful, it mentions adding an extra > '#include' when one is already present. A better error message here > would be to omit the note, or to make it mention changing the selected C++ > standard version. If you'd tried gcc trunk on godbolt you'd have seen that's exactly what happens: :3:10: note: 'std::to_address' is only available from C++20 onwards There was just a typo which made gcc think std::to_address is part of in C++11, so if it wasn't declared in your program then it must be because you didn't include . After the fix it correctly suggests using at least C++20.
[Bug c++/115196] Bad error message when using library functions from versions before they were introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115196 --- Comment #3 from Jonathan Wakely --- You seem to imply it's a general problem, but I think it's specific to sd::to_address, and that's already fixed.
[Bug c++/107500] [12 Regression] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #29 from Jonathan Wakely --- Fixed for 12.4 and up.
[Bug libstdc++/115099] compilation error: format thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 14.2, thanks for the report.
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.4 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940 --- Comment #8 from Jonathan Wakely --- We have the same problem in
[Bug libstdc++/79384] Clang doesn't like variant's std::visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79384 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Jonathan Wakely --- I can't reproduce this now. It might have been the same as Bug 90397 which was fixed for 9.2, or it might have been related to https://bugs.llvm.org/show_bug.cgi?id=31852 The test case compiles fine with clang 17 and libstdc++ headers from GCC 7.5, 8.x, 9.2, or later.
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jonathan Wakely --- Fixed for 13.4 and 14.2
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Jonathan Wakely --- Fixed for 13.4 and 14.1
[Bug c++/102774] Stop showing "error: variable or field ‘f’ declared void" after an earlier error in a declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102774
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-05-18 00:00:00 |2024-5-21
--- Comment #5 from Jonathan Wakely ---
Another one:
template void func(T) { }
f.cc:1:48: error: variable or field ‘func’ declared void
1 | template void func(T) { }
|^~~~
f.cc:1:53: error: ‘T’ was not declared in this scope
1 | template void func(T) { }
| ^
[Bug c++/115173] GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
--- Comment #2 from Jonathan Wakely ---
Further reduced:
struct string { string(int) { } };
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
Still garbage though.
[Bug c++/115173] GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-21
Keywords||diagnostic,
||ice-on-invalid-code,
||memory-hog
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
I'm marking this as ice-on-invalid-code, even though it gets killed rather than
ICE-ing. But it is invalid.
The summary seems misleading, there are no nested initializer lists here. It's
just syntactically ill-formed code with mismatched braces and parentheses.
And most of the functions are irrelevant to the exponential code.
Reduced:
#include
struct string { string(std::initializer_list) { } };
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
}
This seems like auto-generated garbage, not something anybody would ever write
by accident, so should be very low priority.
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 --- Comment #8 from Jonathan Wakely --- (In reply to Amatul Adeeba from comment #6) > I mean even after trying the typo that is mentioned above, the error still > occurs. No it doesn't, it gives the correct error: 107800.cc: In function 'int main()': 107800.cc:5:8: error: 'to_address' is not a member of 'std' 5 | std::to_address(p); |^~ 107800.cc:5:8: note: 'std::to_address' is only available from C++20 onwards N.B. after fixing the typo you need to remove gcc/cp/std-name-hint.* in the GCC source dir, so that those files are recreated from the csv file. If you don't do that, you won't get the fix.
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|13.4|14.0 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > Fixed on trunk so far. I'm not sure why I set the target milestone to 13.3, as chrono::parse isn't present in the gcc-13 branch at all. So this bug only affected gcc-14 and was fixed in time for the 14.1 release.
[Bug c++/115160] Enabling undefined behaviour sanitizer causes or'ed bit shift to report wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115160 --- Comment #5 from Jonathan Wakely --- Specifically, std::vector::iterator::operator++(int) is "just a function", so the compiler doesn't "know" that it modifies the iterator every time it's called. To the compiler, the code looks like: (deref(inc(b)) | (deref(inc(b)) << 8) | (deref(inc(b)) << 16) | (deref(inc(b)) << 24) And this isn't clear that this modifies b and that the result depends on the unspecified order that each deref(inc(b)) subexpression is evaluated. But that doesn't really matter anyway. I don't think there is actually any undefined behaviour here at all, so UBsan should not give any errors. Evaluation of each *b++ subexpression happens before the evaluation of the next one. But the standard doesn't specify which one is "the next one". It's not undefined, but it's unspecified. So it's valid for the compiler to evaluate it left-to-right, but also valid to evaluate it right-to-left, or any other order as long as the b++ evaluations do not interleave.
[Bug c++/115163] Requesting better diagnostic for explicit constructor failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115163 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/111230] show explicit functions in possible candidates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111230 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=36183 --- Comment #2 from Jonathan Wakely --- Dup of PR 36183? There Jason said: We'd probably get that by changing add_candidates to mark an explicit candidate as bad rather than non-viable, and then adding the explanation to convert_like_real.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.2 --- Comment #9 from Jonathan Wakely --- Fixed for 14.2, thanks for the report (and to the dup reporters).
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added CC||pilarlatiesa at gmail dot com --- Comment #6 from Jonathan Wakely --- *** Bug 115134 has been marked as a duplicate of this bug. ***
[Bug libstdc++/115134] Possible typo in _Grapheme_cluster_iterator iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115134 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Already reported twice in the past 24 hours *** This bug has been marked as a duplicate of bug 115119 ***
[Bug libstdc++/115099] compilation error: format thread::id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115099 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-17 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.2 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115121 --- Comment #4 from Jonathan Wakely --- I've opened PR 115121 for the accepts-invalid compiler bug.
[Bug c++/115121] New: ++this is accepted in uninstantiated template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115121
Bug ID: 115121
Summary: ++this is accepted in uninstantiated template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct iter
{
void operator++(int) {
auto tmp = *this;
++this;
return tmp;
}
};
This has a typo, it should be ++*this
I assume this compiles because `this` is dependent, but we could reject it
earlier. Incrementing `this` is never valid, it doesn't matter how the template
is instantiated.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jonathan Wakely --- It fails to compile if that member function is instantiated (which libstdc++ itself never does). /home/jwakely/gcc/15/include/c++/15.0.0/bits/unicode.h:805:11: error: increment of read-only location '(std::__unicode::__v15_1_0::_Grapheme_cluster_view >::_Iterator*)this' 805 | ++this; | ^~ /home/jwakely/gcc/15/include/c++/15.0.0/bits/unicode.h:805:11: error: lvalue required as increment operand But ++this could be rejected without treating it as a dependent expression. Anyway, I'll fix the library typo.
[Bug libstdc++/115119] Typo in _Grapheme_cluster_view::_Iterator::operator++(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115119 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-16 --- Comment #2 from Jonathan Wakely --- Which would be ++*this ++this shouldn't even compile.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-05-15 Resolution|INVALID |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #10 from Jonathan Wakely --- I'm reopening this to deal with it as a libstdc++ bug, because LWG seems to support changing the standard so that this Just Works. https://cplusplus.github.io/LWG/issue4101
[Bug c++/104426] -fsanitize=undefined causes constexpr failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-15 Ever confirmed|0 |1
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- Fixed for 14.2
[Bug libstdc++/115015] [14/15 Regression] libstdc++ build with '-fno-rtti' is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115015 Jonathan Wakely changed: What|Removed |Added Summary|libstdc++ build with|[14/15 Regression] |'-fno-rtti' is broken |libstdc++ build with ||'-fno-rtti' is broken Keywords||build Target Milestone|--- |14.2
[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for 13.3 and 14.2, thanks for the report.
