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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99335
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959
Jonathan Wakely changed:
What|Removed |Added
CC||aatsnps at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82959
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99338
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
Jonathan Wakely changed:
What|Removed |Added
CC||tilman.vogel at web dot de
--- Comment
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.
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
# defin
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
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
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.0
Known to work|
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
defaul
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99382
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99374
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99374
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99386
--- Comment #5 from Jonathan Wakely ---
See PR 78113 and PR 86912
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 W
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
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: diagnost
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/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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Known to work|
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, whic
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 : __se
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
distan
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 (
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(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99413
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508
Jonathan Wakely changed:
What|Removed |Added
Component|other |libstdc++
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70508
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-03-07
Status|UNCONFIR
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
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99429
--- Comment #4 from Jonathan Wakely ---
Dup of PR 94162 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99439
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45896
Jonathan Wakely changed:
What|Removed |Added
CC||lewis at sophists dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99430
--- Comment #1 from Jonathan Wakely ---
They're simply not supported at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453
--- Comment #2 from Jonathan Wakely ---
Yup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86826
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
Jonathan Wakely changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91798
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78710
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99460
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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 t
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_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99499
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Component|libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99413
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99535
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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 initi
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99537
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-03-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|wrong-code
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 error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99552
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-03-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-03-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546
Jonathan Wakely changed:
What|Removed |Added
Keywords|accepts-invalid |wrong-code
--- Comment #3 from Jonatha
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99556
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635
Jonathan Wakely changed:
What|Removed |Added
CC||lewis at sophists dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536
--- Comment #3 from Jonathan Wakely ---
Worked around in libstdc++ on master only for now.
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:8cfb38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99558
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
Jonathan Wakely changed:
What|Removed |Added
Known to fail||11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99614
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
--- Comment #6 from Jonathan Wakely ---
This behaviour is what the standard (still) requires.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99629
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76262
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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
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.
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 b
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-03-19
Ever confirmed|0
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 a
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+
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99701
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
>:
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" :-)
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
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 im
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
--- Comment #8 from Jonathan Wakely ---
It's landed r11-6935 aka g:2bcceb6fc59fcdaf51006d4fcfc71c2d26761396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99730
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99732
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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)
{
unsign
1 - 100 of 7813 matches
Mail list logo
