[Bug c++/97363] New: Missing diagnostics when trying to initialize rvalue reference variable with lvalue expression when using decltype(auto) type deduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97363
Bug ID: 97363
Summary: Missing diagnostics when trying to initialize rvalue
reference variable with lvalue expression when using
decltype(auto) type deduction.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
int main()
{
int &&x = 0;
decltype(auto) y = x; // Should behave like int &&y = x; and thus give a
// compilation error since x is an lvalue.
}
When compiling it with -std=c++20 -pedantic-errors it compiles without
errors.
I expect it instead to give a compilation error for the reason given in the
comment in the program.
Note that clang correctly gives the expected compilation error.
Compiler explorer link (clang to the left and gcc to the right):
https://godbolt.org/z/xzfjMP
[Bug c++/97375] New: Unexpected top-level const retainment when declaring non-type template paramter with decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97375
Bug ID: 97375
Summary: Unexpected top-level const retainment when declaring
non-type template paramter with decltype(auto)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
#include
#include
template
void f1()
{
std::cout << std::is_const_v << std::endl;
}
template
void f2()
{
std::cout << std::is_const_v << std::endl;
}
int main()
{
const int i = 0;
f1();
f2();
}
When compiling it with -std=c++17 -pedantic-errors it gives the following
output:
0
1
I expect it to give the following output instead:
0
0
So that the ignoral of top-level const is done in both cases.
Note that clang gives the correct output. Compiler explorer link showing the
difference between clang and gcc behaviour:
https://godbolt.org/z/aefYKd
I tried to report this bug first to clang (with a different example program),
but it turned out from the discussion (comment #3) that the bug was actually in
gcc:
https://bugs.llvm.org/show_bug.cgi?id=47792#c3
[Bug c++/97376] New: Function type to function pointer type adjustment for non-type template paramter does not work when using decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97376
Bug ID: 97376
Summary: Function type to function pointer type adjustment for
non-type template paramter does not work when using
decltype(auto)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
#include
#include
template
void f1()
{
}
template
void f2()
{
}
void ff()
{
}
int main()
{
f1();
f2();
}
When compiling it with -std=c++17 -pedantic-errors it gives a compilation
error complaining that the non-type parameter X of the template f1 has type
void () and that this is not a valid type for a non-type template paramter.
The expected behaviour is that the type of X in f1 should instead be
ajusted to void (*)() . This is what happens in template f2 .
Note that clang gives the expected behaviour (no compilation errors). Compiler
explorer link comparing clang and gcc:
https://godbolt.org/z/PGbrYE
[Bug c++/97375] Unexpected top-level const retainment when declaring non-type template paramter with decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97375
--- Comment #1 from Anders Granlund ---
Here is another example of the same problem without using decltype(auto), so
the problem seems to be more general:
#include
#include
template
void f1()
{
std::cout << std::is_const_v << std::endl;
}
template
void f2()
{
std::cout << std::is_const_v << std::endl;
}
int main()
{
f1<0>(); // Outputs: 0 Ok
f2(); // Outputs: 1 Not ok. Should output 0 also.
}
Compiler explorer link for this example: https://godbolt.org/z/8ah1ax
[Bug c++/97475] New: An unnamed class with a typedef name for linkage purposes having a method.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
Bug ID: 97475
Summary: An unnamed class with a typedef name for linkage
purposes having a method.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following c++ program:
typedef struct {
void f();
} X;
int main()
{
}
It is not rejected by the compiler when compiling with "-std=c++20
-pedantic-errors".
The expected behaviour is that it should be rejected by section 9.2.3 paragraph
10 in the c++ 20 standard:
"
10 An unnamed class with a typedef name for linkage purposes shall not
(10.1) — declare any members other than non-static data members, member
enumerations, or member classes,
(10.2) — have any base classes or default member initializers, or
(10.3) — contain a lambda-expression,
and all member classes shall also satisfy these requirements (recursively).
"
Note that clang correctly does reject the program:
https://godbolt.org/z/rTerza
[Bug c++/97479] New: Auto as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97479
Bug ID: 97479
Summary: Auto as template argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
template
class A
{
};
int main()
{
A a = A();
}
It is accepted when compiling it with "-std=c++20 -pedantic-errors".
The expected behaviour is that the compiler should reject the program.
Note that clang correctly rejects it:
https://godbolt.org/z/nnh5c7
[Bug c++/97569] New: Declaring a struct in a field declaration of another struct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
Bug ID: 97569
Summary: Declaring a struct in a field declaration of another
struct.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following c++ program:
int main()
{
struct A
{
struct B *b;
};
using U = B;
}
Compile it with "-std=c++20 -pedantic-errors".
The gcc compiler accepts it.
Clang however rejects it with the following error
message: "unknown type name 'B': using U = B;".
The interesting thing is that if we replace struct S with struct S {} both
compilers agree on rejecting the program.
I'm not sure if this is a bug in gcc or clang, but I think this is a gcc bug.
[Bug c++/97569] Declaring a struct in a field declaration of another struct. gcc and clang difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The interesting thing is that if we replace struct S with struct S {}
> > both compilers agree on rejecting the program.
>
> I don't see any struct S in the example program.
struct B it should be.
[Bug c++/97569] Declaring a struct in a field declaration of another struct. gcc and clang difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97569 Anders Granlund changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Anders Granlund --- Thanks for the explanation. I will close this bug report and report to bug to clang instead.
[Bug c++/97475] An unnamed class with a typedef name for linkage purposes having a method.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475 --- Comment #4 from Anders Granlund --- Sounds good to me! On Thu, 5 Aug 2021, 13:35 redi at gcc dot gnu.org, wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475 > > --- Comment #3 from Jonathan Wakely --- > Maybe we should make this ill-formed for C++20, and a pedwarn otherwise, so > existing code continues to compile using previous standards. > > -- > You are receiving this mail because: > You reported the bug.
