[Bug libstdc++/99306] cross compiler bootstrap failure on msdosdjgpp: error: alignment of 'm' is greater than maximum object file alignment 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99306 --- Comment #3 from Jonathan Wakely --- It's intended to be the cacheline size, so would use std::hardware_destructive_interference_size, but that's not implemented yet for the reasons given in PR 88466. And also because it's just a very verbose way to say 64 :-P
[Bug libstdc++/99327] ENOTSUP macro does not exist on djgpp crt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-01 Target||*-pc-msdosdjgpp
[Bug c++/99335] Comma Operator Evaluation Order - C++ 11 and newer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99335 --- Comment #1 from Jonathan Wakely --- (In reply to AJ D from comment #0) > I was using CentOS6.8 with gcc 6.2. However, trying other versions of GCC > didn't make any difference. GCC 6.2 is no longer supported, so we don't want bug reports for it, and the C++17 changes to evaluation order were first implemented for GCC 7: https://gcc.gnu.org/projects/cxx-status.html#cxx17 So of course it doesn't work with GCC 6.
[Bug c++/99335] Comma Operator Evaluation Order - C++ 11 and newer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99335 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- I think this is a dup of PR 82959 *** This bug has been marked as a duplicate of bug 82959 ***
[Bug c++/82959] g++ doesn't appreciate C++17 evaluation order rules for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959 Jonathan Wakely changed: What|Removed |Added CC||aatsnps at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 99335 has been marked as a duplicate of this bug. ***
[Bug c++/82959] g++ doesn't appreciate C++17 evaluation order rules for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-02
[Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-02 Target||*-*-mingw*
[Bug libstdc++/99338] -f and -l variants of cmath functions missing (e.g. std::cosf() and std::cosl())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99338 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- It's a known bug. *** This bug has been marked as a duplicate of bug 79700 ***
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 Jonathan Wakely changed: What|Removed |Added CC||tilman.vogel at web dot de --- Comment #15 from Jonathan Wakely --- *** Bug 99338 has been marked as a duplicate of this bug. ***
[Bug libstdc++/99338] -f and -l variants of cmath functions missing (e.g. std::cosf() and std::cosl())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99338 --- Comment #2 from Jonathan Wakely --- As I said in bug 79700, their existence prior to C++17 was underspecified. They were never mentioned in the previous standards.
[Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333
--- Comment #1 from Jonathan Wakely ---
The problem is not path::is_absolute(), it's path::has_root_name(), which (by
design) only handles //rootname on Cygwin:
#ifdef __CYGWIN__
// Interpret "//x" as a root-name, not root-dir + filename
# define SLASHSLASH_IS_ROOTNAME 1
#endif
I don't have boost built for mingw. Does boost recognise "//disky/mosu" as a
valid path, or does a UNC root-name have to use backslashes?
i.e. is path("//disky/mosu").has_root_name() true?
[Bug libstdc++/99333] std::filesystem::path().is_absolute() thinks UNC paths aren't absolute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333 --- Comment #3 from Jonathan Wakely --- (In reply to Moritz Bunkus from comment #2) > while Boost recognizes both. That's what I wanted to know, thanks. > Note that __CYGWIN__ is not defined with the compiler from MXE! Obviously, because it's not cygwin. Which is why //x paths are not treated as a root-name. As I said, that's by design, but can be changed.
[Bug libstdc++/99341] New: [11 Regression] new std::call_once is not backwards compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341 Bug ID: 99341 Summary: [11 Regression] new std::call_once is not backwards compatible Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ABI Severity: blocker Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Target: *-*-*linux* Creating a new bug for bug 66146 comment 41 increased visibility, and to deal with it separately from the exception-handling bug that is the topic of bug 66146. Quoting from there: The new std::call_once using a futex is not backwards compatible, so I think it needs to be reverted, or hidden behind an ABI-breaking flag. The new std::once_flag::_M_activate() function sets _M_once=1 when an initialization is in progress. With glibc, if a call to the new std::call_once happens before a call to the old version of std::call_once, then glibc's pthread_once will find no fork generation value in _M_once and so will think it should run the init_function itself. Both threads will run their init_function, instead of the second one waiting for the first to finish. With musl, if a call to the old std::call_once happens before a call to the new std::call_once, then the second thread won't set _M_once=3 and so musl's pthread_once won't wake the second thread when the first finishes. The second thread will sleep forever (or until a spurious wake from the futex wait).
[Bug libstdc++/99341] [11 Regression] new std::call_once is not backwards compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.0
Known to work||10.2.1
Priority|P3 |P1
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |11.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-03-02
--- Comment #1 from Jonathan Wakely ---
More details ...
Although libstdc++ ignores any fork generation bits, glibc doesn't and
it *requires* a (possibly zero) fork generation to be present.
The __pthread_once_slow function uses CAS to set the once_control
variable, and if that succeeds and the IN_PROGRESS bit is set, it
compares the high bits with the current fork generation.
If the IN_PROGRESS bit was set by the new libstdc++ std::call_once
there won't be a fork generation. If the process' fork generation is
not zero then this check in glibc will be false:
/* Check whether the initializer execution was interrupted by a
fork. We know that for both values, __PTHREAD_ONCE_INPROGRESS
is set and __PTHREAD_ONCE_DONE is not. */
if (val == newval)
{
/* Same generation, some other thread was faster. Wait and
retry. */
futex_wait_simple ((unsigned int *) once_control,
(unsigned int) newval, FUTEX_PRIVATE);
continue;
}
If std::call_once in another thread set val=2 but the fork gen is 4,
then newval=4|1 and so val == newval is false. That means glibc
assumes that an in-progress initialization was interrupted by a fork
and so this thread should run it. That means two threads will be
running it at once.
Demo:
#include
#include
#include
#include
#include
extern std::once_flag once_flag;
extern void old();
#if __GNUC__ >= 11
std::once_flag once_flag;
int main()
{
// increase for generation:
switch (fork())
{
case -1:
abort();
case 0:
break;
default:
wait(nullptr);
return 0;
}
// This is the child process, fork generation is non-zero.
std::call_once(once_flag, [] {
std::cout << "Active execution started using new code\n";
old();
std::cout << "Active execution finished using new code\n";
});
}
#else
void old()
{
std::call_once(once_flag, [] {
std::cout << "Active execution started using old code\n";
std::cout << "Active execution finished using old code\n";
});
}
#endif
Compile this once with GCC 11 and once with GCC 10 and link with GCC
11, and instead of deadlocking (as it should do) you'll get:
Active execution started using new code
Active execution started using old code
Active execution finished using old code
Active execution finished using new code
And using a libstdc++ build with _GLIBCXX_ASSERTIONS you'll get:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/mutex.cc:79: void
std::once_flag::_M_finish(bool): Assertion 'prev & _Bits::_Active' failed.
because the "inner" execution changes the state to _Done when it
finishes, and the assertion in the "outer" execution fails.
[Bug libstdc++/99341] [11 Regression] new std::call_once is not backwards compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341 --- Comment #2 from Jonathan Wakely --- The new implementation added these new symbols to libstdc++.so: _ZNSt9once_flag11_M_activateEv _ZNSt9once_flag9_M_finishEb I think I'd like to keep them, but have the new implementation disabled by default (except for the ABI-changing gnu-versioned-namespace build). The new implementation is superior (it fixes PR 66146, and performs better in some cases due to inlining an initial check to see if executions should be passive) so I'd like to retain it for users who explicitly request it. By default we need to be compatible with the old version based on pthread_once. At some point (maybe when there are further ABI changes queued) maybe we'll do another painful transition like the cxx11-abi one and switch to the new std::once_flag by default. Maybe the new std::once_flag should be moved to an inline namespace, and then the symbols above defined as aliases for the equivalents using the inline namespace in the mangled name (the aliases are needed if we want to support binaries that are already using them, e.g. packages in the upcoming Fedora 34 which were compiled with gcc-11.0.1 already).
[Bug libstdc++/99356] Recursive std::shared_future:s with std::launch::deferred sporadically deadlock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99356 --- Comment #1 from Jonathan Wakely --- This is probably due to PR 97949 again, because shared_future uses call_once internally.
[Bug libstdc++/99382] Address sanitizer detects stack-buffer-overflow in stl_construct.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
(In reply to Vittorio Zecca from comment #0)
> int i[3];
> Size n = {4};
> auto j = std::__uninitialized_default_n(i, n); // Fails here
What part of this do you think is a bug?
You've told the library to construct 4 elements in a region of storage that
only has room for 3. Of course it has a buffer overflow.
[Bug libstdc++/99382] Address sanitizer detects stack-buffer-overflow in stl_construct.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|NEW Resolution|INVALID |--- Last reconfirmed||2021-03-04 --- Comment #2 from Jonathan Wakely --- (In reply to Vittorio Zecca from comment #0) > // From test case sizes.cc Ah! this detail was not clear, you're reporting a bug in 20_util/specialized_algorithms/uninitialized_default_n/sizes.cc So the bug is in our code, confirmed then.
[Bug libstdc++/99382] Address sanitizer detects stack-buffer-overflow in stl_construct.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- And fixed, thanks.
[Bug c++/99374] C++17/20 mode fails to recognise pointer-to-member functions of incomplete types in conditional expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99374 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-04 --- Comment #1 from Jonathan Wakely --- Bisection says this started to fail with r241958 which makes no sense.
[Bug c++/99374] C++17/20 mode fails to recognise pointer-to-member functions of incomplete types in conditional expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99374 --- Comment #2 from Jonathan Wakely --- It seems more likely (i.e. very likely) to be caused by r241944 instead.
[Bug c++/99374] C++17/20 mode fails to recognise pointer-to-member functions of incomplete types in conditional expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99374 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jonathan Wakely --- The change (and the reason it works pre-C++17) is noexcept being part of the type. Apparently G++ thinks the implicit conversion from R (C::*)() noexcept to R(C::*)() depends on C being complete. So it has nothing to do with conditional expressions and can be reduced to: struct S; using F1 = int (S::*)(); using F2 = int (S::*)() noexcept; F1 f1 = F2();
[Bug c++/99386] std::variant overhead much larger compared to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99386 --- Comment #5 from Jonathan Wakely --- See PR 78113 and PR 86912
[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 Jonathan Wakely changed: What|Removed |Added CC|jwakely.gcc at gmail dot com | --- Comment #5 from Jonathan Wakely --- Stop CCing me on every bug you file, or I will ban your account, permanently this time. I read the gcc-bugs mailing list, so I will see the bug anyway. Stop CCing me. I won't ask again, I'll just ban you. Also, don't just post a godbolt link with no other comments, that's not a valid but report.
[Bug c++/99403] New: Add header fix-it hints for std::this_thread::* and std::jthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99403
Bug ID: 99403
Summary: Add header fix-it hints for std::this_thread::* and
std::jthread
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main()
{
std::this_thread::sleep_for(std::chrono::seconds(1));
std::this_thread::sleep_until(std::chrono::system_clock::now());
std::this_thread::get_id();
std::this_thread::yield();
}
This fails with:
ns.C: In function 'int main()':
ns.C:5:21: error: 'sleep_for' is not a member of 'std::this_thread'
5 | std::this_thread::sleep_for(std::chrono::seconds(1));
| ^
ns.C:6:21: error: 'sleep_until' is not a member of 'std::this_thread'
6 | std::this_thread::sleep_until(std::chrono::system_clock::now());
| ^~~
We have a fix-it hint for std::thread, but not the other entities in :
ns.C:2:1: note: 'std::thread' is defined in header ''; did you forget
to '#include '?
1 | #include
+++ |+#include
2 | int main()
That should be added for std::jthread (since C++20 only), and namespace
std::this_thread and the four functions in the example above (all for C++11 and
later). There is no error for get_id and yield because they happen to be
transitively included via , but that's an implementation detail that
could change in future (no pun intended).
If isn't included we get errors for std::this_thread itself, so that
nested namespace deserves a fix-it hint of its own:
#include
int main()
{
std::this_thread::sleep_for(std::chrono::seconds(1));
}
ns.C: In function 'int main()':
ns.C:4:8: error: 'std::this_thread' has not been declared
4 | std::this_thread::sleep_for(std::chrono::seconds(1));
|^~~
[Bug c++/99404] New: Diagnostics for undeclared members of a namespace don't say "namespace"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99404
Bug ID: 99404
Summary: Diagnostics for undeclared members of a namespace
don't say "namespace"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main()
{
std::this_thread::sleep_until(std::chrono::system_clock::now());
}
This invalid program gives:
ns.C: In function 'int main()':
ns.C:5:21: error: 'sleep_until' is not a member of 'std::this_thread'
5 | std::this_thread::sleep_until(std::chrono::system_clock::now());
| ^~~
It might be helpful to casual C++ programmers if it was clear that
'std::this_thread' is a namespace, and not a class type or global variable e.g.
ns.C:5:21: error: 'sleep_until' is not a member of namespace 'std::this_thread'
Minimal example:
namespace N { }
void f() {
using N::a;
N::b();
}
ns2.C: In function ‘void f()’:
ns2.C:3:12: error: ‘a’ has not been declared in ‘N’
3 | using N::a;
|^
ns2.C:4:6: error: ‘b’ is not a member of ‘N’
4 | N::b();
| ^
Also, is there a reason these two diagnostics are worded differently?
Clang says:
ns2.C:3:12: error: no member named 'a' in namespace 'N'
using N::a;
~~~^
ns2.C:4:6: error: no member named 'b' in namespace 'N'
N::b();
~~~^
2 errors generated.
And EDG says:
"ns2.C", line 3: error: namespace "N" has no member "a"
using N::a;
^
"ns2.C", line 4: error: namespace "N" has no member "b"
N::b();
^
2 errors detected in the compilation of "ns2.C".
[Bug c++/48396] std::type_info is implicitly declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48396 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56468 Summary|Undeclared library types|std::type_info is |accepted in namespace std |implicitly declared Last reconfirmed|2012-04-12 00:00:00 |2021-3-5 --- Comment #1 from Jonathan Wakely --- Adjusting the summary because this is specific to std::type_info, it doesn't happen for other types. I think there's some historical reason that G++ pre-defines std::type_info, but maybe we could make that only valid in system headers. It still causes bugs even then, because libstdc++ can accidentally rely on the G++ behaviour, which doesn't work with other compilers (e.g PR 56468).
[Bug tree-optimization/99396] std::rotl and std::rotr Does not convert into ROTATE on the gimple level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99396 --- Comment #10 from Jonathan Wakely --- As you noted on IRC, these functions are undefined for anything except unsigned integral types. Adding that here for observers wondering about comments 7 and 8.
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Known to work||9.3.0 Target Milestone|--- |10.3 Summary|std::copy creates |[10/11 Regression] |_GLIBCXX_DEBUG false|std::copy creates |positive for attempt to |_GLIBCXX_DEBUG false |subscript a dereferenceable |positive for attempt to |(start-of-sequence) |subscript a dereferenceable |iterator|(start-of-sequence) ||iterator CC||fdumont at gcc dot gnu.org Known to fail||10.1.0, 10.2.0, 11.0 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-05 --- Comment #1 from Jonathan Wakely --- Probably caused by r276600
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 --- Comment #2 from Jonathan Wakely --- (In reply to Kip Warner from comment #0) > // This results in memory corruption, or an abort with STL debugging I don't see any memory corruption, I think it's just a bug in the Debug Mode checks, which aborts when it shouldn't do. Without those bad checks it doesn't abort, and works correctly.
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #3 from Jonathan Wakely ---
François, this can't be right:
return std::make_pair(-__seq_dist.first,
__seq_dist.second == __dp_exact
? __dp_sign_max_size : __seq_dist.second);
This uses __seq_dist.second, but __seq_dist comes from _SeqTraits::_S_size
which is:
template
struct _Sequence_traits
{
typedef _Distance_traits _DistTraits;
static typename _DistTraits::__type
_S_size(const _Sequence& __seq)
{ return std::make_pair(__seq.size(), __dp_exact); }
};
i.e. __seq_dist.second is always __dp_exact, so this function always returns
__dp_sign_max_size.
You should be using __base_dist.second, no?
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #4 from Jonathan Wakely ---
This causes __valid_range to return {11, __dp_sign_max_size} and then we check
__result._M_can_advance(11) which fails.
We don't want to advance the result by the size of the other sequence, only by
distance(__first, __last). We don't care if there are elements in the sequence
past __last because we're not trying to copy them.
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> You should be using __base_dist.second, no?
No, it's not that simple. I don't understand how this code is meant to work,
but this can't be right:
if (this->_M_is_begin())
{
if (__rhs._M_is_before_begin())
return std::make_pair(-1, __dp_exact);
if (__rhs._M_is_end())
return __seq_dist;
return std::make_pair(__seq_dist.first,
__seq_dist.second == __dp_exact
? __dp_sign_max_size : __seq_dist.second);
}
We can't use __seq_dist.first as the distance, because we have already
established that __rhs is not the end iterator, so it must be before the end.
And so the distance we're trying to find must be less than __seq_dist.first.
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #6 from Jonathan Wakely ---
Reduced:
#include
#include
#include
using namespace std;
int main()
{
// any container with non-random access iterators:
const set source = { 0, 1 };
vector dest(1);
copy(source.begin(), ++source.begin(), dest.begin());
}
[Bug libstdc++/99413] internal library headers are not header-unit ready
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99413 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-05 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- There are *many* such problems e.g. /home/jwakely/gcc/11/include/c++/11.0.1/bits/stl_set.h:92:52: error: 'less' in namespace 'std' does not name a template type 92 | template, |^~~~ But in most cases the header is only included from exactly one place (in this case, from ). Will they not be selected to be header units by your selection criteria, and so can be ignored (at least for now)? None of the bits/foo.tcc files are ever intended to be included from anywhere except at the end of the corresponding bits/foo.h header. Do those ones need to be fixed? Again, they are included in exactly one place (explicitly by design here, rather than just how the library is arranged).
[Bug libstdc++/70508] libstdc++.*-gdb.py': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508 Jonathan Wakely changed: What|Removed |Added Component|other |libstdc++ Keywords||build --- Comment #1 from Jonathan Wakely --- (In reply to Fiodar from comment #0) > Making install in python > make[3]: Entering directory > `/d/mbuild/src/build-gcc/arm-none-symbianelf/libstdc++-v3/python' > make[4]: Entering directory > `/d/mbuild/src/build-gcc/arm-none-symbianelf/libstdc++-v3/python' > make[4]: Nothing to be done for `install-exec-am'. > /bin/install -c -m 644 gdb.py > /usr/local/gcc-5.3.0/arm-none-symbianelf/lib/libstdc++.*-gdb.py > /bin/install: cannot create regular file > `/usr/local/gcc-5.3.0/arm-none-symbianelf/lib/libstdc++.*-gdb.py': No such > file or directory This means libstdc++.* didn't match any files, which means the shared lib hasn't been built yet. That shouldn't happen. Do you still see this with current releases?
[Bug libstdc++/70508] libstdc++.*-gdb.py': No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-03-07 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug libstdc++/99453] New: libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Bug ID: 99453 Summary: libstdc++*-gdb.py installation depends on library naming Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- libstdc++-v3/python/Makefile.am does: install-data-local: gdb.py @$(mkdir_p) $(DESTDIR)$(toolexeclibdir) ## We want to install gdb.py as SOMETHING-gdb.py. SOMETHING is the ## full name of the final library. We want to ignore symlinks, the ## .la file, and any previous -gdb.py file. This is inherently ## fragile, but there does not seem to be a better option, because ## libtool hides the real names from us. @here=`pwd`; cd $(DESTDIR)$(toolexeclibdir); \ for file in libstdc++.*; do \ case $$file in \ *-gdb.py) ;; \ *.la) ;; \ *) if test -h $$file; then \ continue; \ fi; \ libname=$$file;; \ esac; \ done; \ cd $$here; \ echo " $(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py"; \ $(INSTALL_DATA) gdb.py $(DESTDIR)$(toolexeclibdir)/$$libname-gdb.py This will use the last matching file for the libstdc++* glob. That works fine for ELF targets where the matching names are: libstdc++.a libstdc++.so libstdc++.so.6 libstdc++.so.6.0.29 But not for MacOS with: libstdc++.6.dylib libstdc++.a Or mingw with: libstdc++-6.dll libstdc++.dll.a We need a better way to find the dynamic library, whether that's the so.6.0.29 or the .dylib or the .dll, that doesn't depend on the shell's alphabetic sort for the pattern. As the comment says, libtool doesn't give us that info, but we can still do better.
[Bug c++/99429] [10/11 Regression] ICE for bool return from <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429 --- Comment #4 from Jonathan Wakely --- Dup of PR 94162 ?
[Bug libstdc++/99439] use_facet> (l); get() API with kMonthDayYearFormat = L"%m/%d/%Y" should allow missing leading zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99439 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Nothing to do with wchar_t, and it's already known. As it says in PR 45896 this changed between C++03 and C++11. *** This bug has been marked as a duplicate of bug 45896 ***
[Bug libstdc++/45896] [C++0x] Facet time_get not reading dates according to the IEEE 1003 standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896 Jonathan Wakely changed: What|Removed |Added CC||lewis at sophists dot com --- Comment #11 from Jonathan Wakely --- *** Bug 99439 has been marked as a duplicate of this bug. ***
[Bug libstdc++/99430] std::filesystem::path: UNC device paths with \\?\… not supported properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99430 --- Comment #1 from Jonathan Wakely --- They're simply not supported at all.
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #2 from Jonathan Wakely --- Yup
[Bug c++/96464] GCC accepts 'auto' in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-08
[Bug c++/86826] deduction fails on auto-returning function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86826 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |11.0 --- Comment #2 from Jonathan Wakely --- Fixed by Patrick's r11-2420 patch for PR64194 and it looks like another dup of it. *** This bug has been marked as a duplicate of bug 64194 ***
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 Jonathan Wakely changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #18 from Jonathan Wakely --- *** Bug 86826 has been marked as a duplicate of this bug. ***
[Bug c++/91798] Compiler rejects code due to template specialization of auto parameter value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91798 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86933 Last reconfirmed|2020-01-29 00:00:00 |2021-3-8 --- Comment #2 from Jonathan Wakely --- Possibly a dup of PR 86933
[Bug libstdc++/78710] suggest better exception text for stoi, stol, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78710 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-08 Status|UNCONFIRMED |NEW Component|c++ |libstdc++
[Bug c++/99460] [C++20] Template with complex non-type argument re-uses different specialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99460 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-08 Keywords||wrong-code
[Bug libstdc++/78710] suggest better exception text for stoi, stol, ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78710
--- Comment #2 from Jonathan Wakely ---
(In reply to Nicolai Josuttis from comment #0)
> stoi("hello") currently throws an exception where what() only outputs "stoi"
> (nothing else).
The type of the exception is significant too. It can either throw
std::invalid_argument("stoi") or std::out_of_range("stoi").
> Some component (either __stoa() or __throw_invalid_argument())
> should extend the message at least a bit.
> E.g. __stoa() might call
>std::__throw_invalid_argument("invalid argument for " + __name)
This makes it (very slightly) more likely to throw std::bad_alloc than to throw
what we actually want to throw. It's probably a reasonable trade-off to get a
better what() message though.
[Bug libstdc++/93628] ranges::equal_to doesn't work for types convertible to function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93628 --- Comment #1 from Jonathan Wakely --- LWG 3530 should mean we don't have to support such silly types. https://wg21.link/lwg3530 However, we are still required to impose a total order on function pointers, which means ranges::less/greater/less_equal/greater_equal are still (potentially) broken, as for object pointers in PR 78420. We might get away with it if the compiler doesn't do similar optimizations for function pointers, but we used to say that about object pointers too, and it stopped being true. As noted above, we don't have a way to detect that a relational comparison would call a built-in operator on function pointers. Maybe what we want is a __builtin_less_than(t, u) which is t < u but with a total order.
[Bug target/99499] build failure for android bionic toolchains. error: '_U' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499 Jonathan Wakely changed: What|Removed |Added Keywords||build Component|libstdc++ |target CC||mkuvyrkov at gcc dot gnu.org Host|x86_64-msys2-mingw-w64, |x86_64-msys2-mingw-w64 |windows 10 | --- Comment #2 from Jonathan Wakely --- Obviously _U worked at some point when that file was added. CCing Maxim to figure out what changed and whether we want to support the old ctype constants as well as whatever Android defines now.
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-03-11
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
(In reply to Steffen Schuemann from comment #0)
> On POSIX filesystem backend type systems the
> std::filesystem::recursive_directory_iterator throws a filesystem_error
> exception with "operation not permitted" when the opendir/readdir call
> returns EPERM instead of EACCES even if
> std::filesystem::directory_options::skip_permission_denied is set.
POSIX is clear that opendir sets EACCES not EPERM.
> Given the following code:
>
> #include
> #include
N.B. This is missing a "namespace fs = std::filesystem;"
> This fails for example on macOS when called on the user home directory with:
>
> Error: filesystem error: cannot increment recursive directory iterator:
> Operation not permitted
>
> This is due to System Integrity Protection (since macOS 10.14) on the
> "/Users//Library/Application Support/MobileSync" folder leading to
> EPERM.
That seems to be a MacOS bug.
> On Linux, called with / it stops when hitting for example a
> "/proc/1/task/1/cwd", resulting in EPERM too.
But that happens in your code, not in the library. The error is:
Error: filesystem error: status: Permission denied [/proc/1/task/1/cwd]
And it comes from this line:
if(de.is_regular_file()) {
I think the code is working correctly on linux.
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > > On Linux, called with / it stops when hitting for example a > > "/proc/1/task/1/cwd", resulting in EPERM too. > > But that happens in your code, not in the library. The error is: > > Error: filesystem error: status: Permission denied [/proc/1/task/1/cwd] And that's an EACCES error anyway (as POSIX requires for stat(3) permission errors). The text would be "Operation not permitted" for EPERM.
[Bug libstdc++/99413] internal library headers are not header-unit ready
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99413 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for gcc-11.
[Bug c++/99535] g++ rejects valid code in constexpr copy ctor and volatile submember
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99535 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- Yes, I think the special member functions are ill-formed (no diagnostic required) as per http://eel.is/c++draft/dcl.constexpr#6.sentence-1
[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536
--- Comment #1 from Jonathan Wakely ---
GCC 5 is old and no longer supported.
This is probably a jump threading bug. The _M_saved member is only ever used if
_M_saved_available says it can be used, and that is only the case after it's
been initialized.
We could probably just initialize it on construction to avoid the false
positive warning:
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -2024,12 +2024,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
explicit
normal_distribution(result_type __mean,
result_type __stddev = result_type(1))
- : _M_param(__mean, __stddev), _M_saved_available(false)
+ : _M_param(__mean, __stddev)
{ }
explicit
normal_distribution(const param_type& __p)
- : _M_param(__p), _M_saved_available(false)
+ : _M_param(__p)
{ }
/**
@@ -2166,8 +2166,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const param_type& __p);
param_type _M_param;
- result_type _M_saved;
- bool_M_saved_available;
+ result_type _M_saved = 0;
+ bool_M_saved_available = false;
};
/**
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #12 from Jonathan Wakely --- Comment on attachment 50360 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50360 Proposed patch to fix issue The patch looks good but please CC the libstdc++ list for libstdc++ patches, thanks.
[Bug libstdc++/99537] Wrong memory_order used in stop_token ref-counting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99537 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-03-11 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/99546] Weird return value of C++20 requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|wrong-code |accepts-invalid Ever confirmed|0 |1 Last reconfirmed||2021-03-11 --- Comment #2 from Jonathan Wakely --- I think the requires expression should be rejected as ill-formed.
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533
--- Comment #3 from Jonathan Wakely ---
The standard says that skip_permission_denied means to ignore "an error
indicating that permission to access p is denied" and it's pretty clearly
intended to correspond to std::errc::permission_denied errors, not
std::errc::operation_not_permitted.
But this should solve the issue for MacOS:
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -207,7 +207,7 @@ recursive_directory_iterator(const path& p,
directory_options options,
else
{
const int err = errno;
- if (err == EACCES
+ if (fs::is_permission_denied_error(err)
&& is_set(options, fs::directory_options::skip_permission_denied))
{
if (ecptr)
diff --git a/libstdc++-v3/src/filesystem/dir-common.h
b/libstdc++-v3/src/filesystem/dir-common.h
index 56e279230f4..a49b8304a29 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -141,6 +141,18 @@ struct _Dir_base
posix::DIR* dirp;
};
+inline bool
+is_permission_denied_error(int e)
+{
+ if (e == EACCES)
+return true;
+#ifdef __APPLE__
+ if (e == EPERM) // See PR 99533
+return true;
+#endif
+ return false;
+}
+
} // namespace filesystem
// BEGIN/END macros must be defined before including this file.
diff --git a/libstdc++-v3/src/filesystem/dir.cc
b/libstdc++-v3/src/filesystem/dir.cc
index acc62986c68..215a9533f1b 100644
--- a/libstdc++-v3/src/filesystem/dir.cc
+++ b/libstdc++-v3/src/filesystem/dir.cc
@@ -202,7 +202,7 @@ recursive_directory_iterator(const path& p,
directory_options options,
else
{
const int err = errno;
- if (err == EACCES
+ if (std::filesystem::is_permission_denied_error(err)
&& is_set(options, fs::directory_options::skip_permission_denied))
{
[Bug libstdc++/99552] FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99552 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-03-11 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99306 --- Comment #1 from Jonathan Wakely --- (In reply to John David Anglin from comment #0) > FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors) > Excess errors: > /test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool. > cc:64: warning: alignment (64) for _ZZNSt8__detail9__waiters6_S_forEPKvE3__w > exceeds maximum alignment for global common data. Using 32 See also PR 99306 > Usually, I add "-fno-common" to avoid these warnings on hppa*-*-hpux*. Isn't that redundant for C++, and on by default for C in GCC 11 anyway?
[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-03-11 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/99546] Weird return value of C++20 requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546 Jonathan Wakely changed: What|Removed |Added Keywords|accepts-invalid |wrong-code --- Comment #3 from Jonathan Wakely --- My mistake, the requires-expression is valid, so it is just a wrong-code big as you originally said.
[Bug libstdc++/99552] FAIL: 29_atomics/atomic/wait_notify/bool.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99552 --- Comment #4 from Jonathan Wakely --- That's useful to know, thanks. The current header-based implementation is experimental and those aligned objects will be moved into the library at some point, where we can probably control their placement and alignment more precisely. In the meantime, I think we want a macro in config/os/*/os_defines.h that says whether we should try to over-align them. If we don't do it, performance will suffer because of false sharing, but it won't affect correctness.
[Bug libstdc++/99556] time_get::date_order() returns no_order on en_US - it should return mdy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99556 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- (In reply to lewis pringle from comment #0) > note - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 appears to be a > similar report, but is almost 20 years old. But it's still the same bug. *** This bug has been marked as a duplicate of bug 9635 ***
[Bug libstdc++/9635] time_get<>::date_order unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635 Jonathan Wakely changed: What|Removed |Added CC||lewis at sophists dot com --- Comment #10 from Jonathan Wakely --- *** Bug 99556 has been marked as a duplicate of this bug. ***
[Bug c++/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 --- Comment #3 from Jonathan Wakely --- Worked around in libstdc++ on master only for now.
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533 --- Comment #4 from Jonathan Wakely --- Fixed for gcc-11 only for now. This got added to the wrong bug because I used the wrong PR number in the changelog ... The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8cfb387388a90730ab36ac24d9049677db633a11 commit r11-7628-g8cfb387388a90730ab36ac24d9049677db633a11 Author: Jonathan Wakely Date: Thu Mar 11 16:43:51 2021 + libstdc++: Handle EPERM for filesystem access errors on MacOS [PR n] Contrary to what POSIX says, some directory operations on MacOS can fail with EPERM instead of EACCES, so we need to handle both. libstdc++-v3/ChangeLog: PR libstdc++/n * src/c++17/fs_dir.cc (recursive_directory_iterator): Use new helper function to check for permission denied errors. * src/filesystem/dir.cc (recursive_directory_iterator): Likewise. * src/filesystem/dir-common.h (is_permission_denied_error): New helper function.
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/99558] wrong argument types reported for "no matching function" error message if ctor argument is a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99558 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- (In reply to J. Hart from comment #0) > $ g++ -c -o utl2.o utl2.cc > utl2.cc: In function "int main()": > utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int&, int)" > > correct argument type: constant used as argument, first argument is > correctly shown as "int" GCC is correct. When you use a variable you are passing an lvalue of type int, which is what int& means. When you pass a constant it is an rvalue, i.e. int. > > $ g++ -D DBG1 -c -o utl2.o utl2.cc > utl2.cc: In function "int main()": > utl2.cc:13:5: error: no matching function for call to "cls4::cls4(int, int)" Because you're passing two rvalues.
[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 Jonathan Wakely changed: What|Removed |Added Known to fail||11.0 CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Rejected since r11-2774 c++: Check satisfaction before non-dep convs. [CWG2369] It's very hard to use concepts to protect a template from hard errors due to unwanted instantiation if constraints aren't checked until after doing all substitution and checking of non-dependent conversions. It was pretty straightforward to insert the satisfaction check into the logic, but I needed to make the 3-parameter version of satisfy_declaration_constraints call push_tinst_level like the 2-parameter version already does. For simplicity, I also made it add any needed outer template arguments from the TEMPLATE_DECL to the args. The testsuite changes are mostly because this change causes unsatisfaction to cause deduction to fail rather than reject the candidate later in overload resolution.
[Bug analyzer/99614] diagnostic-manager.cc:85: possible missing copy constructor ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99614 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-16 --- Comment #2 from Jonathan Wakely --- It has a reference member, so its assignment operator is already deleted, so cppcheck is wrong to warn about that. It should have a user-declared (possibly deleted) copy constructor though.
[Bug libstdc++/99612] Remove "#pragma GCC system_header" from atomic file to warn on incorrect memory order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612 --- Comment #1 from Jonathan Wakely --- I'd prefer if the compiler just got it right. This seems like a warning that should fire even in system headers. Or it should track that the value is a function parameter and came from a non-system header and so the diagnostic location should not consider the point of use.
[Bug c++/76262] list-initialization prefers initializer_list over copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262 --- Comment #6 from Jonathan Wakely --- This behaviour is what the standard (still) requires.
[Bug c++/99629] Misleading diagnostic when looking up rewritten candidate and failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99629 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-03-17 Keywords||diagnostic
[Bug c++/76262] list-initialization prefers initializer_list over copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85577 --- Comment #7 from Jonathan Wakely --- See Bug 85577 and it's duplicates too.
[Bug c++/99637] bit_cast doesn't work with padding bits and it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637 --- Comment #4 from Jonathan Wakely --- I think the relevant sentence is "Each bit of the value representation of the result is equal to the corresponding bit in the object representation of from." For one of the bits in the result, there is no corresponding bit in the object representation of from. So the result cannot be created.
[Bug c++/99637] bit_cast doesn't work with padding bits and it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > So the result cannot be created. Not during constant evaluation, anyway.
[Bug c++/99637] bit_cast doesn't work with padding bits and it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99637 --- Comment #7 from Jonathan Wakely --- Yes. If the result type is a class type and the padding bits in the input correspond to unsigned char or std::byte subobjects in the result, that's OK (because the only parts with indeterminate values are byte-like types, the rest of the result is properly initialized). I think GCC is correct here.
[Bug c++/99644] New: Add fix-it hint for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99644
Bug ID: 99644
Summary: Add fix-it hint for
Product: gcc
Version: 11.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
Target Milestone: ---
Given:
template struct S { };
template requires (sizeof(T) == 1) struct S { };
This fails to compile with -std=gnu++20 as expected:
con.C:2:55: error: redeclaration 'template struct S' with different
constraints
2 | template requires (sizeof(T) == 1) struct S { };
| ^
con.C:1:29: note: original declaration appeared here
1 | template struct S { };
| ^
The user probably meant to declare the constrained template as a partial
specialization, not a redeclaration of the primary template (I do this all the
time). So a fix-it hint suggesting to add a template argument list would be
helpful:
note: did you mean to declare a partial specialization?
2 | template requires (sizeof(T) == 1) struct S { };
|^
|
This could be suggested whenever a redeclaration of a template has exactly the
same template-parameter-list as the original declaration but different
constraints. The fix-it hint should suggest adding a template argument list
containing each of the template parameters.
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-18 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- I'm not sure "rejects-valid" is appropriate, as it only fails to compile because of the static assert (i.e. you've asked for it). But wrong-code isn't really right either, because this is before any codegen happens. Every bug in metaprogramming results can be turned into accepts-invalid or rejects-valid or wrong-code, but none of those keywords is really specific to the actual form of the bug. Maybe we need a new keyword (and no, meta-bug is it either ;-).
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compiled, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-03-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- Confirmed. Not a regression.
[Bug c++/61961] Add new warning when initializer-list constructor chosen for uniform init that doesn't intend to use initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61961
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> The semantics I suggest are to warn when:
>
> * an initializer-list constructor is selected by overload resolution
> * the elements of the braced-init-list are not all the same type
> * another (non-initializer-list) constructor is viable
This would also be useful to warn for the CWG 2137 / PR 76262 / PR 85577 cases
where an initializer-list constructor is chosen for a braced-init-list with a
single element of the same type as the class being constructed. Users almost
always want A{a} to use a copy constructor, and are surprised when GCC chooses
an initializer-list constructor (which other compilers don't do).
So revised suggestion for the semantics:
* an initializer-list constructor is selected by overload resolution
* another (non-initializer-list) constructor is viable
* either the braced-init-list has more than one element and they are not all
the same type, or it has exactly one element and its type is the same as the
class being constructed.
I think this should be included in -Wall. If the initializer-list constructor
is really intended then the warning can be suppressed by explicitly converting
the initializers to the intended type, which more clearly expresses the
intended meaning of the code anyway.
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #4 from Jonathan Wakely --- (In reply to Sergey Kaniskin from comment #3) > I was unsure whether to file it under compiler or stdlibc++ as it’s accepted > by another compilers using stdlibc++. There's no such component, it's libstdc++. But if the same libstdc++ code works with other compilers then it's probably not a libstdc++ bug. The __rvalue_ostream_type constraints are going away soon: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566863.html
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #5 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > But by definition at this point operator << does not exist and is not > considered as it is not found via ADL because both std::basic_ostream > and std::vector are in the std namespace and the global namespace is > not considered. Which seems correct to me. Users should not be overloading operator<< for types defined by the standard library anyway. You don't own vector so you don't get to say how it should be output to std::ostream.
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #7 from Jonathan Wakely --- I mean that the test used in the library code is doing the right thing. I haven't investigated whether the compiler is not handling the lookup correctly, but I don't think there's a libstdc++ bug here.
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99701 --- Comment #9 from Jonathan Wakely --- (In reply to CVS Commits from comment #7) > 3) The overload descriptions for built-in operators were adjusted, >because objects of type std::nullptr_t cannot be used with relational >operators any more. This apparently wasn't completely done, see PR 99701.
[Bug c++/99701] std::nullptr_t can be compared with relational ops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99701 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed||2021-03-21
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 --- Comment #7 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #4) > The demangler does the right, although confusing thing. Because the Itanium > ABI says that g is __float128: >::= f # float >::= d # double >::= e # long double, __float80 >::= g # __float128 So if we had a time machine we could mangle double-double as 'u8__ibm128' and then 'g' could be used for __float128 aka __ieee128, and the demangled names would not be wildly confusing. But there's no way to do that now. You just have to know that when compiler errors talk about __float128 they mean __ieee128 and when linker errors talk about __float128 they mean __ibm128.
[Bug libstdc++/98389] [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98389 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > So if we had a time machine we could mangle double-double as 'u8__ibm128' Or even 'u2dd' for "double double" :-)
[Bug c++/51066] [C++0x] warning about binding an rvalue-reference to an implicit conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51066
--- Comment #3 from Jonathan Wakely ---
This warning would also help with this horror:
https://twitter.com/zygoloid/status/1367301323838812160
#include
void f(float&&) { puts("float"); }
void f(int&&) { puts("int"); }
template void g(T x) { f(x); }
int main() {
g(1.0f);
g(2);
}
Prints "int\nfloat\n" because f(x) cannot bind directly to an rvalue reference
so there is an implicit conversion.
[Bug c++/51066] [C++0x] warning about binding an rvalue-reference to an implicit conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51066
--- Comment #4 from Jonathan Wakely ---
And this one https://twitter.com/wakomeup/status/1274778577087627267
struct B { };
struct D : B { };
B b;
D&& d(b); // binds to implicit conversion result
D&& dd(std::move(b)); // binds to implicit conversion result
[Bug c++/99728] code pessimization when using wrapper classes around SIMD types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728 --- Comment #8 from Jonathan Wakely --- It's landed r11-6935 aka g:2bcceb6fc59fcdaf51006d4fcfc71c2d26761396
[Bug c++/99730] gcc cannot choose the best overload resolution with constrained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99730 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Constraints are only used as a tie-breaker for equivalent overloads. These overloads are not the same.
[Bug c++/99730] gcc cannot choose the best overload resolution with constrained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99730 --- Comment #2 from Jonathan Wakely --- See https://wg21.link/p2113 which was implemented in r11-1571
[Bug target/99733] darwin: missing ':' in error message about munmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-23 Keywords||diagnostic Status|UNCONFIRMED |NEW
[Bug c++/99732] gcc accepts overload a member function without ref-qualifier with a member function with a ref-qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99732 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-23
[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from Jonathan Wakely --- Reopening as I'm still seeing this (or it's returned).
[Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #9 from Jonathan Wakely ---
[test@ibm-p8-cluster-02 ~]$ cat 97653.c
int printf(const char*, ...);
const unsigned long k = 256;
int main()
{
long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
for (int i = 0; i < 4; ++i)
{
unsigned long j = k * r[i];
printf("%lu * %Lf = %lu\n", k, r[i], j);
}
}
[test@ibm-p8-cluster-02 ~]$ ~/gcc/ieee/bin/gcc 97653.c -mno-gnu-attribute
-mabi=ibmlongdouble -Wall -static-libgcc -v && ./a.out
Using built-in specs.
COLLECT_GCC=/home/test/gcc/ieee/bin/gcc
COLLECT_LTO_WRAPPER=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee
--disable-multilib --disable-bootstrap --enable-languages=c++ --disable-pch
--disable-nls --without-isl --with-long-double-format=ieee : (reconfigured)
/home/test/src/gcc/configure --prefix=/home/test/gcc/ieee --disable-multilib
--disable-bootstrap --enable-languages=c++ --disable-pch --disable-nls
--without-isl --with-long-double-format=ieee
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210323 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a-'
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/cc1
-quiet -v 97653.c -quiet -dumpdir a- -dumpbase 97653.c -dumpbase-ext .c
-mno-gnu-attribute -mabi=ibmlongdouble -Wall -version -o /tmp/ccNHNZzj.s
GNU C17 (GCC) version 11.0.1 20210323 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 11.0.0 20210225 (Red Hat 11.0.0-0), GMP
version 6.2.0, MPFR version 4.1.0-p9, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../powerpc64le-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/include
/usr/local/include
/home/test/gcc/ieee/include
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/include-fixed
/usr/include
End of search list.
GNU C17 (GCC) version 11.0.1 20210323 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 11.0.0 20210225 (Red Hat 11.0.0-0), GMP
version 6.2.0, MPFR version 4.1.0-p9, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ab29af0a0f73449cd280c2751cbad267
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a-'
as -v -a64 -mpower8 -mlittle -o /tmp/cc4MmQYf.o /tmp/ccNHNZzj.s
GNU assembler version 2.35.1 (ppc64le-redhat-linux) using BFD version version
2.35.1-41.fc34
COMPILER_PATH=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/
LIBRARY_PATH=/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a.'
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/collect2
-plugin
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/liblto_plugin.so
-plugin-opt=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccwamb6Q.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
--eh-frame-hdr -V -m elf64lppc -dynamic-linker /lib64/ld64.so.2
/lib/../lib64/crt1.o /lib/../lib64/crti.o
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/crtbegin.o
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../..
/tmp/cc4MmQYf.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/crtend.o
/lib/../lib64/crtn.o
GNU ld version 2.35.1-41.fc34
Supported emulations:
elf64lppc
elf32lppc
elf32lppclinux
elf32lppcsim
elf64ppc
elf32ppc
elf32ppclinux
elf32ppcsim
elf32_spu
i386pep
i386pe
elf64bpf
COLLECT_GCC_OPTIONS
