* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
@ 2020-11-30 8:13 ` rguenth at gcc dot gnu.org
2020-12-02 13:55 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-30 8:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
Keywords| |build
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
2020-11-30 8:13 ` [Bug plugins/98059] " rguenth at gcc dot gnu.org
@ 2020-12-02 13:55 ` jakub at gcc dot gnu.org
2020-12-02 14:44 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-12-02 13:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed, C++20 rejects this since
r11-532-g4b38d56dbac6742b038551a36ec80200313123a1
DR2237 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237
change.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
2020-11-30 8:13 ` [Bug plugins/98059] " rguenth at gcc dot gnu.org
2020-12-02 13:55 ` jakub at gcc dot gnu.org
@ 2020-12-02 14:44 ` cvs-commit at gcc dot gnu.org
2020-12-02 16:20 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-12-02 14:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:bad800c03d00a57fc21718c160459d9a1e8d747a
commit r11-5660-gbad800c03d00a57fc21718c160459d9a1e8d747a
Author: Scott Snyder <sss@li-snyder.org>
Date: Wed Dec 2 15:42:56 2020 +0100
vec.h: Fix GCC build with -std=gnu++20 [PR98059]
Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
DR2237 r11-532 change.
template <typename T>
class auto_delete_vec
{
private:
auto_vec_delete<T> (const auto_delete_vec<T> &) = delete;
};
which vec.h uses is invalid C++20, one needs to use
auto_vec_delete (const auto_delete_vec &) = delete;
instead which is valid all the way back to C++11 (and without = delete
to C++98).
2020-12-02 Scott Snyder <sss@li-snyder.org>
PR plugins/98059
* vec.h (auto_delete_vec): Use
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) instead of
DISABLE_COPY_AND_ASSIGN(auto_delete_vec<T>) to make it valid C++20
after DR2237.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
` (2 preceding siblings ...)
2020-12-02 14:44 ` cvs-commit at gcc dot gnu.org
@ 2020-12-02 16:20 ` redi at gcc dot gnu.org
2020-12-02 16:22 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-12-02 16:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This change is incorrect, r11-532-g4b38d56dbac6742b038551a36ec80200313123a1 is
wrong to reject that assignment operator. The declarator-id is "operator=" and
so doesn't contain a template-id at all.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
` (3 preceding siblings ...)
2020-12-02 16:20 ` redi at gcc dot gnu.org
@ 2020-12-02 16:22 ` redi at gcc dot gnu.org
2020-12-02 16:27 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-12-02 16:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Well, strictly speaking the change isn't wrong, and arguably it's an
improvement. But it's incorrect for GCC to require it in C++20 mode.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
` (4 preceding siblings ...)
2020-12-02 16:22 ` redi at gcc dot gnu.org
@ 2020-12-02 16:27 ` jakub at gcc dot gnu.org
2020-12-02 16:29 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-12-02 16:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We were using:
template <typename T>
struct S {
private:
S<T> (const S<T> &) = delete;
S<T> operator = (const S<T> &) = delete;
};
With the change we are using:
template <typename T>
struct S {
private:
S (const S &) = delete;
S operator = (const S &) = delete;
};
We could be using also:
template <typename T>
struct S {
private:
S (const S<T> &) = delete;
S<T> operator = (const S<T> &) = delete;
};
and it would be still valid C++20 (and is accepted), just the first form is
not, because after DR2237 one can't use S<T> () for the constructor.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
` (5 preceding siblings ...)
2020-12-02 16:27 ` jakub at gcc dot gnu.org
@ 2020-12-02 16:29 ` redi at gcc dot gnu.org
2020-12-02 16:31 ` jakub at gcc dot gnu.org
2021-01-06 9:39 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-12-02 16:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #2)
> Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
> DR2237 r11-532 change.
> template <typename T>
> class auto_delete_vec
> {
> private:
> auto_vec_delete<T> (const auto_delete_vec<T> &) = delete;
Ugh, I misread this as an assignment operator despite there being no operator=
there at all.
It's a copy ctor, and yes, it's invalid. Sorry.
> };
> which vec.h uses is invalid C++20, one needs to use
> auto_vec_delete (const auto_delete_vec &) = delete;
The <T> is allowed on the parameter, it's only disallowed on the first one, so
this would be OK too:
auto_vec_delete (const auto_delete_vec<T> &) = delete;
But the macro can't generate that, and there's no reason to prefer it.
Sorry for the noise :-(
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
` (6 preceding siblings ...)
2020-12-02 16:29 ` redi at gcc dot gnu.org
@ 2020-12-02 16:31 ` jakub at gcc dot gnu.org
2021-01-06 9:39 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-12-02 16:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Anyway, fixed now.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug plugins/98059] [11 regression] Plugins don't compile with c++20
2020-11-29 23:05 [Bug plugins/98059] New: [11 regression] Plugins don't compile with c++20 sss@li-snyder.org
` (7 preceding siblings ...)
2020-12-02 16:31 ` jakub at gcc dot gnu.org
@ 2021-01-06 9:39 ` cvs-commit at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-06 9:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98059
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:45a5aa80240d2033fb490f974756b947f8d0db40
commit r10-9213-g45a5aa80240d2033fb490f974756b947f8d0db40
Author: Scott Snyder <sss@li-snyder.org>
Date: Wed Dec 2 15:42:56 2020 +0100
vec.h: Fix GCC build with -std=gnu++20 [PR98059]
Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
DR2237 r11-532 change.
template <typename T>
class auto_delete_vec
{
private:
auto_vec_delete<T> (const auto_delete_vec<T> &) = delete;
};
which vec.h uses is invalid C++20, one needs to use
auto_vec_delete (const auto_delete_vec &) = delete;
instead which is valid all the way back to C++11 (and without = delete
to C++98).
2020-12-02 Scott Snyder <sss@li-snyder.org>
PR plugins/98059
* vec.h (auto_delete_vec): Use
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) instead of
DISABLE_COPY_AND_ASSIGN(auto_delete_vec<T>) to make it valid C++20
after DR2237.
(cherry picked from commit bad800c03d00a57fc21718c160459d9a1e8d747a)
^ permalink raw reply [flat|nested] 10+ messages in thread