https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96079
--- Comment #1 from Jonathan Wakely ---
It seems like all these bugs with atomics in libgccjit could be a single bug
report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96077
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
||patch
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549453.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96068
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #4 from Jonathan Wakely ---
What I meant was that I was tempted to disable them completely *even with*
-Wsystem-headers. All warnings are already disabled by default in libstdc++
headers. If your build is adding -Wsystem-headers then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Component|libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #8 from Jonathan Wakely ---
Created attachment 48838
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48838&action=edit
Fix orphaned notes.
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
$ clang++ -include bits/extc++.h -x c++ - :1:
In file included from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96036
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #10 from Jonathan Wakely ---
What's wrong with checking the return value of warning_at as in the patch in
comment 8?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-07
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96106
Jonathan Wakely changed:
What|Removed |Added
Summary|A friend abbreviated|[10/11 Regression] A friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #1 from Jonathan Wakely ---
What is that even supposed to mean?
Rejecting it seems right to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #2 from Jonathan Wakely ---
This isn't specific to catch handlers, other compilers accept that nonsense
function declaration in various contexts, and GCC rejects them all:
using F = auto () -> auto;
template struct X { };
X auto> x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #3 from Jonathan Wakely ---
And this puts Clang into a coma even without debuginfo:
template struct X { T* p; };
X auto> x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96110
--- Comment #6 from Jonathan Wakely ---
I've reported https://bugs.llvm.org/show_bug.cgi?id=46637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #12 from Jonathan Wakely ---
(In reply to Antal Buss from comment #1)
> Created attachment 48811 [details]
> Preprocessed file
For convenience, that is:
#include
int main() {
auto t = std::jthread([](){});
t.request_stop();
||2020-07-08
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Jonathan Wakely ---
(In reply to ensadc from comment #0)
> It seems that in this case, `iter_difference_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
Jonathan Wakely changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96118
--- Comment #1 from Jonathan Wakely ---
This is a duplicate of an existing bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96119
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-08
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96115
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19538
Jonathan Wakely changed:
What|Removed |Added
Keywords|accepts-invalid, diagnostic |rejects-valid
Status|SUSPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46206
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81836
Jonathan Wakely changed:
What|Removed |Added
Keywords|diagnostic |
Last reconfirmed|2017-08-21 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86709
Jonathan Wakely changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96118
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79815
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96121
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #1 from Jonathan Wakely ---
(In reply to Haoxin Tu from comment #0)
> GCC might emit the ambiguity diagnostic message on it.
What does that mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #2 from Jonathan Wakely ---
GCC's diagnostic seems fine to me. Using 'void' as the type of a parameter is
invalid. There's a special case for (void) but that isn't relevant to your
declaration, which has two parameters.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96120
--- Comment #4 from Jonathan Wakely ---
(In reply to Haoxin Tu from comment #3)
> Apologize for my expression. I mean the meaning of the error message
> "invalid use of type ‘void’ in parameter declaration" is opposite with the
> valid grammar(it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
--- Comment #2 from Jonathan Wakely ---
(In reply to François Dumont from comment #1)
> I'll check if we can be smarter here. A nice improvement would be to change
> std::hash operator signature to:
>
> size_t
> operator()(const stri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.2|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #14 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #13)
> I'm testing this:
>
> diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
> index 965247602ac..0af84a781e5 100644
> --- a/libgcc/gthr-posix.h
> +++ b/li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89962
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
--- Comment #4 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #3)
> > Adding hash::operator()(string_view) is an interesting idea for the
> > standard though.
>
> Indeed. If we want to, I think it is possible to add some overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
--- Comment #7 from Jonathan Wakely ---
The fix is actually not right, it fails to discard the delimiter if it occurs
after ignoring more than numeric_limits::max() characters.
I have a fix for that though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80272
Jonathan Wakely changed:
What|Removed |Added
CC||zoid at riseup dot net
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93892
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96145
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main()
{
std::istringstream s("++");
s.ignore(2, '-');
std::cout << "EOF? " << s.eof() << std::endl;
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=94749
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |redi at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59135
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #2 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #0)
> In case helgrind is correct, it seems that there are some issues behind
> std::scoped_lock, since it was explicitly designed for solving issues with
> lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96179
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063
--- Comment #16 from Jonathan Wakely ---
One or both of r11-1853 and r11-1899 should be backported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70493
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #29 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96181
--- Comment #3 from Jonathan Wakely ---
(In reply to Arturo Laurenzi from comment #0)
> Now, I understand the code snipped is probably broken. However, this change
> breaks old code that would work just fine by ignoring the undefined return
> val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96161
--- Comment #2 from Jonathan Wakely ---
Fixed on trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85714
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> The enumeration type can take any value from (Foo)INT_MIN to (Foo)INT_MAX,
> and likewise for Bar. Your switches are not exhaustive.
>
> I think we need a FA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83280
--- Comment #2 from Jonathan Wakely ---
There is now info about this on the wiki:
https://gcc.gnu.org/wiki/VerboseDiagnostics#enum_switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96182
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96193
--- Comment #2 from Jonathan Wakely ---
(In reply to Johel Ernesto Guerrero Peña from comment #1)
> That actually compiles if I add -std=c++20.
That is correct, isn't it?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0846r0.html is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #3 from Jonathan Wakely ---
(In reply to Will Wray from comment #2)
> Would an early-delivered future feature require an opt-in switch?
The relevant -std switch would be the opt-in.
> Can P1061 be default enabled under earlier std f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #4 from Jonathan Wakely ---
(In reply to Will Wray from comment #0)
> (Submitting simultaneous requests for each of GCC, Clang and MSVC.
> Coordination between vendors will be beneficial for portability.)
This seems like the wrong a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
--- Comment #8 from Jonathan Wakely ---
But __builtin_bit_cast is the compiler magic to support std::bit_cast, it's not
just a non-standard extension. PR 93121 is a request for std::bit_cast in GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #4 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #3)
> My guess, without having looked at the implementation of std::lock, is that
> the algorithm uses try_lock to eventually lock/unlock the mutexes and see if
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #3 from Jonathan Wakely ---
Reduced:
template using void_t = void;
template T&& declval();
template
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #4 from Jonathan Wakely ---
The reduced example above doesn't need -std=c++17, it should compile in C++11
or later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #7 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #6)
> For what is worth, I imagined the implementation for parameters of different
> type and more or less than two to be similar to
>
>
> template
> auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96222
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86742
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-16
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96266
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #1 from Jonathan Wakely ---
Your operator== should be const-qualified.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96279
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
--- Comment #3 from Jonathan Wakely ---
(In reply to Eyal Rozenberg from comment #2)
> Ok, still - the linker knows which virtual methods it needs, and it knows
> which are provided by each compiled translation unit. Isn't that enough?
The linke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
--- Comment #4 from Jonathan Wakely ---
(In reply to Eyal Rozenberg from comment #0)
> While this is true, it is a bit confusing. But even supposing I looked up
> what this error means and realized what was going on, I would still need to
> go ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #12 from Jonathan Wakely ---
(In reply to Zhihao Yuan from comment #11)
> 1. Adjust the error message to say, "The first non-inline, non-pure function
> may not have a definition in ."
That error comes from the linker. The linker is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #13 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> The linker error alone doesn't make the root cause obvious, but it's a
> fairly well known and well documented problem:
> http://www.parashift.com/c++-faq-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
Jonathan Wakely changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
--- Comment #5 from Jonathan Wakely ---
Another one that G++ rejects:
void f(char*);
int &f(...);
int &r = f("foo");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
Jonathan Wakely changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86498
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Last reconfirmed|2018-07-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #2 from Jonathan Wakely ---
But they're not enabled by default, meaning that the unsafe, ill-formed code is
still accepted by default.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
struct S
{
static_assert( sizeof(T) < 4, "smol" );
char* p = new char[3 - sizeof(T)];
};
S s;
GCC gives two erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68929
--- Comment #4 from Jonathan Wakely ---
Probably related to PR c++/96286, because if we stopped trying to compile a
class after a failed static_assert then we wouldn't keep recursing in Eric's
example here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96287
--- Comment #1 from Jonathan Wakely ---
Ignoring it could lead to equally undesirable behaviour though.
for file in *.cc ; do gcc "$fil" ; done
Don't those languages support something like the Bourne shell's "$@" which does
the right thing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92285
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.3|10.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.3|---
--- Comment #17 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
--- Comment #23 from Jonathan Wakely ---
Dave, should we unset the milestone? Any further changes will only happen on
trunk not the gcc-10 branch, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.3|---
--- Comment #5 from Jonathan Wakel
gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2020-07-23
Status|UNCONFIRMED |ASSIGNED
Known to work||9.3.0
Known to fail||10.2.0, 11.0
Summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96324
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-27
Ever confirmed|0
601 - 700 of 18414 matches
Mail list logo
