[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861 since r6-6830-g20a0c6f9bdbd78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 --- Comment #9 from Fabio Alemagna --- (In reply to Patrick Palka from comment #8) > The issue was probably latent before r6-6830. The testcase is kind of > strange, It's the "friend injection" technique. In this case, it's used to create a compile-time counter. The specific test case uses templates in such a way as to try and circumvent a diagnostic-related bug (bug #112267), which however triggered this other bug.
[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 --- Comment #7 from Fabio Alemagna --- (In reply to Marek Polacek from comment #6) > (In reply to Andrew Pinski from comment #5) > > (In reply to Fabio Alemagna from comment #4) > > > (In reply to Marek Polacek from comment #2) > > > > Confirmed. Started with r6-6830-g20a0c6f9bdbd78: > > > > > > > > commit 20a0c6f9bdbd781ed5d413a10a06764a174dc394 > > > > Author: Patrick Palka > > > > Date: Mon Feb 8 23:02:50 2016 + > > > > > > > > Fix PR c++/69283 (auto deduction fails when ADL is required) > > > > > > > > but reverting that fix doesn't make the ICE go away. > > > > > > That seems wy to old to be the cause of the issue. > > > > > > As said, it works with v13.2.1 > > > > Note the trunk has extra checkings enabled compared to a release if not > > configured with `--enable-checking=release` so you might be seeing that > > effect here. > > That's right. Trunk configured with --enable-checking=release doesn't ICE, > either. Oh! Didn't know that, my bad.
[Bug c++/112288] [11/12/13/14 Regression] ICE - internal compiler error: in instantiate_decl, at cp/pt.cc:26861
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 --- Comment #4 from Fabio Alemagna --- (In reply to Marek Polacek from comment #2) > Confirmed. Started with r6-6830-g20a0c6f9bdbd78: > > commit 20a0c6f9bdbd781ed5d413a10a06764a174dc394 > Author: Patrick Palka > Date: Mon Feb 8 23:02:50 2016 + > > Fix PR c++/69283 (auto deduction fails when ADL is required) > > but reverting that fix doesn't make the ICE go away. That seems wy to old to be the cause of the issue. As said, it works with v13.2.1
[Bug c++/112288] internal compiler error: in instantiate_decl, at cp/pt.cc:26861
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 Fabio Alemagna changed: What|Removed |Added Attachment #56472|0 |1 is obsolete|| CC||falemagn at gmail dot com --- Comment #1 from Fabio Alemagna --- Created attachment 56474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56474=edit Generated with -freport-bug
[Bug c++/112288] New: internal compiler error: in instantiate_decl, at cp/pt.cc:26861
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288 Bug ID: 112288 Summary: internal compiler error: in instantiate_decl, at cp/pt.cc:26861 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: falemagn at gmail dot com Target Milestone: --- It's a regression, it compiles fine with v13.2.1.
[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112267 --- Comment #4 from Fabio Alemagna --- With a tweak(In reply to Andrew Pinski from comment #3) > (In reply to Fabio Alemagna from comment #1) > > Changing the return type of the function func() from int to auto makes the > > warning disappear. > > > > Incidentally it causes an error on clang, though, which prompts the > > question: is this a clang bug, for erroring out, or a gcc bug, for not > > erroring out? > > I tested MSVC also. It errors out with /std:c++20 but not with /std:c++17 so > maybe there was a change for C++20 that clang decided it applies for > previous C++ too (and GCC did not implement that rule yet). Making the function a template, while keeping the return type as 'auto', and making its template parameter depend on the template parameter of the caller, solves the error and silences the warning on gcc. Making the return value 'bool', even if the function is a template, still makes the warning appear. On Compiler Explorer: https://godbolt.org/z/E5qMT55MW
[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112267 --- Comment #2 from Fabio Alemagna --- Sorry, "from int to auto" should have been "from bool to auto". You get the point.
[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112267 --- Comment #1 from Fabio Alemagna --- Changing the return type of the function func() from int to auto makes the warning disappear. Incidentally it causes an error on clang, though, which prompts the question: is this a clang bug, for erroring out, or a gcc bug, for not erroring out? See it on Compiler Explorer: https://godbolt.org/z/4ETs4ca3d
[Bug c++/112267] New: "inline function constexpr used but never defined" warning in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112267
Bug ID: 112267
Summary: "inline function constexpr used but never defined"
warning in SFINAE context
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
I am expecting no warnings from the following code snippets, especially because
SFINAE is being correctly triggered, and indeed clang doesn't provide one for
the specific case at hand, alas g++ does.
I am left wondering whether this is a bug or a "overreaction". The warning
itself cannot be turned off with a pragma.
#if defined(__clang__)
_Pragma("GCC diagnostic ignored \"-Wundefined-inline\"");
#endif
#define DEFINE_FUNC 0
constexpr bool func()
#if DEFINE_FUNC
{
return true;
}
#else
;
#endif
template
constexpr bool is_defined(int) {
return true;
}
template
constexpr bool is_defined(double) {
return false;
}
int a = is_defined(0);
See it working on Compiler Explorer: https://godbolt.org/z/dvTKdGfbv
[Bug objc++/109728] lambda capture with initializer doesn't compile when compiling ObjC++ code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109728 --- Comment #2 from Fabio Alemagna --- Yes, clang handles this case correctly.
[Bug objc++/109728] New: lambda capture with initializer doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109728
Bug ID: 109728
Summary: lambda capture with initializer doesn't compile
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
This simple snippet
int a;
auto b = [c = a]{};
Produces the following error:
error: 'c' was not declared in this scope
[Bug c++/108089] False positive for -Wfree-nonheap-object when using std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108089 Fabio Alemagna changed: What|Removed |Added Known to work||11.3.0 Known to fail||12.1.0 --- Comment #1 from Fabio Alemagna --- To be noted that the issue doesn't happen on gcc v11.3.
[Bug c++/108089] New: False positive for -Wfree-nonheap-object when using std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108089
Bug ID: 108089
Summary: False positive for -Wfree-nonheap-object when using
std::variant
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
The following is the most reduced example I could come up with.
#include
#include
#include
using variant = std::variant<
std::string,
std::vector
>;
extern std::size_t _index;
void func() {
ext_index = variant(std::string()).index();
}
"ext_index" being a reference is all it takes to trigger the issue. If it'd be
an object, the issue would not triggered. The issue would be triggered also if
ext_index were a pointer.
As far as I could tell, ff "std::string" is substituted with a type whose
destructor doesn't involve any deallocation, then the issue is not triggered.
The issue is also not triggered if std::string is substituted with another
std::vector specialization.
You can see it all on godbolt: https://godbolt.org/z/aaxY1jW1q
This is the error (unecessary lines removed):
In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*,
size_type) [with _Tp = char]',
inlined from 'static void
std::allocator_traits >::deallocate(allocator_type&,
pointer, size_type) [with _Tp = char]' at /opt/compiler-explorer/gcc-12.1.0/
[...]
inlined from 'std::variant<_Types>::~variant() [with _Types =
{std::__cxx11::basic_string, std::allocator
>, std::vector >}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/variant:1407:28,
inlined from 'void func()' at :14:17:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/new_allocator.h:158:33:
error: 'void operator delete(void*, std::size_t)' called on unallocated object
'' [-Werror=free-nonheap-object]
158 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p,
__n));
| ^
: In function 'void func()':
:14:38: note: declared here
14 | ext_index = variant(std::string()).index();
| ^
[Bug c++/108088] New: False positive for -Wfree-nonheap-object when using std::variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108088
Bug ID: 108088
Summary: False positive for -Wfree-nonheap-object when using
std::variant
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
Created attachment 54083
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54083=edit
Preprocessed file
The following is the most reduced example I could come up with.
#include
#include
#include
using variant = std::variant<
std::string,
std::vector
>;
extern std::size_t _index;
void func() {
ext_index = variant(std::string()).index();
}
"ext_index" being a reference is all it takes to trigger the issue. If it'd be
an object, the issue would not triggered. The issue would be triggered also if
ext_index were a pointer.
As far as I could tell, ff "std::string" is substituted with a type whose
destructor doesn't involve any deallocation, then the issue is not triggered.
The issue is also not triggered if std::string is substituted with another
std::vector specialization.
You can see it all on godbolt: https://godbolt.org/z/aaxY1jW1q
This is the error (unecessary lines removed):
In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*,
size_type) [with _Tp = char]',
inlined from 'static void
std::allocator_traits >::deallocate(allocator_type&,
pointer, size_type) [with _Tp = char]' at /opt/compiler-explorer/gcc-12.1.0/
[...]
inlined from 'std::variant<_Types>::~variant() [with _Types =
{std::__cxx11::basic_string, std::allocator
>, std::vector >}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/variant:1407:28,
inlined from 'void func()' at :14:17:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/new_allocator.h:158:33:
error: 'void operator delete(void*, std::size_t)' called on unallocated object
'' [-Werror=free-nonheap-object]
158 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p,
__n));
| ^
: In function 'void func()':
:14:38: note: declared here
14 | ext_index = variant(std::string()).index();
| ^
[Bug c++/105908] New: out-of-class definition of templated method with decltype in trailing return type fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105908
Bug ID: 105908
Summary: out-of-class definition of templated method with
decltype in trailing return type fails to compile
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
This code fails to compile with g++12.
struct test
{
template
int templated_func();
int normal_func();
template
auto call_with_scope_templated_func() ->
decltype(test::templated_func());
template
auto call_templated_func() -> decltype(templated_func());
template
auto call_normal_func() -> decltype(normal_func());
};
template
auto test::call_with_scope_templated_func() ->
decltype(test::templated_func())
{
return templated_func();
}
template
auto test::call_templated_func() -> decltype(templated_func())
{
return templated_func();
}
template
auto test::call_normal_func() -> decltype(normal_func())
{
return normal_func();
}
gcc complaines like this:
:25:6: error: no declaration matches 'decltype
(((test*)this)->templated_func()) test::call_templated_func()'
25 | auto test::call_templated_func() -> decltype(templated_func())
| ^~~~
:12:10: note: candidate is: 'template decltype
(((test*)this)->templated_func()) test::call_templated_func()'
12 | auto call_templated_func() -> decltype(templated_func());
| ^~~
:1:8: note: 'struct test' defined here
1 | struct test
|^~~~
However, as you can see, it works if the class name is prepended to the
template_func() call within the decltype expression, and it also works if
the called function is not templated.
G++11 doesn't show any such issue, nor does clang.
An working example on godbolt: https://godbolt.org/z/xK5aoxfxY
[Bug c++/89565] [C++2a] ICE on template instantiating user defined non-type template from template value member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89565 --- Comment #4 from Fabio Alemagna --- Just encountered this bug myself, with trunk gcc (11.0.1 20210321 (experimental)). See godbolt: https://godbolt.org/z/TxW137Whh
