[Bug c++/96355] New: [concepts] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96355
Bug ID: 96355
Summary: [concepts] internal compiler error: in
tsubst_pack_expansion, at cp/pt.c:12928
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
The following code (https://godbolt.org/z/edTK48) causes an internal compiler
error:
template
requires requires
{
requires sizeof...(Args) > 1;
}
auto add(const Args&... args)
{
return (... + args);
}
int main()
{
return add(2, 3, 4);
}
The error is:
: In instantiation of 'auto add(const Args& ...) [with Args = {int,
int, int}]':
:13:22: required from here
:4:13: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12922
4 |requires sizeof...(Args) > 1;
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
With g++ 10.1 on godbolt there is no internal compiler error, but the compiler
concludes
:4:29: note: nested requirement '(sizeof... (Args) > 1)' is not
satisfied
which is also wrong. However, the behavior seems to have changed with 10.2.0
and exists in trunk (20200727). The code compiles, if I move the requirement
directly into the requires-clause:
template
requires(sizeof...(Args) > 1)
auto add(const Args&... args)
{
return (... + args);
}
This version even produces the correct result. I suspect the error is in the
path of the nested requirement.
The failing code compiles with clang 10.0.0 and MSVC 19.24.
Cheers,
Andreas
[Bug c++/96439] New: [concepts] nested requirement allows calling a method of a local parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96439
Bug ID: 96439
Summary: [concepts] nested requirement allows calling a method
of a local parameter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
the following code is accepted by GCC 10.2.0 and trunk (as of 20200802):
template
struct array {
constexpr auto size() const { return N; }
};
template
concept C2 = requires(T a) {
requires a.size() > 2; // "a" is a local parameter and should be allowed
only a an unevaluated operand
};
static_assert(C2< array<5> >);
My reading of [expr.prim.req.nested] p2 is, that is should be ill-formed, "a"
is a local parameter. The following code is (correctly in my opinion) rejected
by GCC:
template
constexpr bool Fun(T& t)
{
return true;
}
template
concept C1 = requires(T a) {
requires true == Func(a);
};
static_assert(C1);
It looks to me, that in the case of calling a member function on a local
parameter the check is missing. Clang rejects both examples. MSVC 19.24 shows
the same behavior as GCC, so I might be misreading something.
Here is a godbolt link: https://godbolt.org/z/TeTdoK
Cheers,
Andreas
[Bug c++/96745] New: [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745
Bug ID: 96745
Summary: [concepts] internal compiler error: in
type_memfn_rqual, at cp/typeck.c:10389
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
the following code gives an internal compiler error.
template
struct Test {
~Test() requires true {}
~Test() requires true && true {}
};
Test t;
Error:
: In instantiation of 'struct Test':
:7:11: required from here
:2:8: internal compiler error: in type_memfn_rqual, at
cp/typeck.c:10389
2 | struct Test {
|^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
The code is ill-formed, the compiler cannot identify which of the two
destructors is the most constrained. However, I think a more helpful error
message would assist me in a large code-base much more.
Live: https://godbolt.org/z/6dP8PG
Andreas
[Bug c++/92477] New: [[nodiscard]] method in a decltype expression causes "warning: ignoring return value of"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92477
Bug ID: 92477
Summary: [[nodiscard]] method in a decltype expression causes
"warning: ignoring return value of"
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
consider this code:
class Test
{
public:
[[nodiscard]] int Get() const { return 42; }
};
template
auto UsedForSFINAE(const T& t) -> decltype(t.Get(), void())
{
}
template
auto UsedAsReturnValue(const T& t) -> decltype(t.Get())
{
return t.Get();
}
int main()
{
Test t{};
UsedForSFINAE(t);
UsedAsReturnValue(t);
}
It tries to SFINAE out the UsedForSFINAE based on whether the type passed has a
method Get. The decltype expression in
UsedForSFINAE causes a warning in GCC with -Wall passed:
warning: ignoring return value of 'int Test::Get() const', declared with
attribute nodiscard [-Wunused-result]
8 | auto UsedForSFINAE(const T& t) -> decltype(t.Get(), void())
:4:23: note: declared here
4 | [[nodiscard]] int Get() const { return 42; }
| ^~~
Clang on the other hand is fine with it (see https://godbolt.org/z/9U4ceB). The
warning goes away when t.Get() is casted to void. There is no warning, if the
decltype's resulting type is used as the return type (as for
UsedAsReturnValue).
I talked to Richard Smith about this last week at WG21 Belfast and he told me
that Clang is correct. Unfortunately, I don't recall his exact rational. I
think it was that in [dcl.type.decltype] is says "The operand of the decltype
specifier is an unevaluated operand (7.2)."
Bug 57857 looks a bit similar.
Cheers,
Andreas
[Bug c++/98052] New: Allocation with new and deallocation with std::allocator should result in an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98052
Bug ID: 98052
Summary: Allocation with new and deallocation with
std::allocator should result in an error
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
the following code compiles without an error (https://godbolt.org/z/oPG8Ea) in
GCC:
#include
constexpr auto fun()
{
int* i = new int{4};
std::allocator a{};
a.deallocate(i, 1);
return 0;
}
int main()
{
constexpr auto f = fun();
}
In the constexpr function fun, an int is allocated with new and free'd with
std::allocator's deallocate. According to N4868 [allocator.members] p6, a
precondition for deallocate is that the memory was previously allocated with
allocate. Clang does reject the code with:
note: 'std::allocator<...>::deallocate' used to delete pointer to object
allocated with 'new'
The behavior of Clang seems to be consistent with the wording. GCC incorrectly
allows this code to compile.
Best,
Andreas
[Bug c++/114242] New: Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
Bug ID: 114242
Summary: Coroutine with lambda-coroutine and operator new does
not compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
the following code is accepted by Clang but rejected by g++ and MSVC:
https://compiler-explorer.com/z/7P548dGG3
Once the lambda inside the coroutine isn't used, the code compiles with all
three compilers.
My reading of http://eel.is/c++draft/dcl.fct.def.coroutine#9.1 is that the
custom operator new should be picked in all cases.
G++'s error:
```
: In lambda function:
:54:15: error: 'operator new' is provided by
'std::__n4861::__coroutine_traits_impl::promise_type' {aka
'Generator::promise_type'} but is not usable with the function signature
'coro(std::span)::)>'
54 | auto lamb = [](std::span) -> Generator {
| ^
```
suggests that the compiler tries to look up an operator new with only size as
an argument.
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 --- Comment #4 from Andreas Fertig --- Thanks for looking into the issue! While CWG 2585 tweaks the wording, my reading is that the code should be valid even with C++20. Regardless of that, without the lambda, the code compiles and uses a custom allocator. After playing with the test case, I could reduce it to having only a coroutine-lambda with a promise_type that has a custom operator new: https://compiler-explorer.com/z/W53nKsfxG Sorry for not having that done initially! I suspect this case wasn't implemented (because it isn't obvious?).
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 --- Comment #5 from Andreas Fertig --- My latest conclusion is that my code is indeed invalid. In the case of the lambda, I have a class type. http://eel.is/c++draft/dcl.fct.def.coroutine#4 says that in such a case, p1 is an lvalue of *this. If I modify my original example, g++ and MSVC accept the code, but Clang now rejects it: https://compiler-explorer.com/z/1hhxfYW1v I will open an issue there and let them confirm. But I think we can close this issue for g++.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 114242, which changed state. Bug 114242 Summary: Coroutine with lambda-coroutine and operator new does not compile https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 Andreas Fertig changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andreas Fertig --- The behavior of g++ is correct.
