[Bug c++/70462] Unnecessary "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70462 --- Comment #7 from Fabio Alemagna --- (In reply to Pádraig Brady from comment #6) > This does introduce an ABI incompatibility. > > I'm seeing this with kuduraft-1.8 compiled with GCC 10, giving linker errors > from clang 9.0.20190721 like: > > error: undefined symbol: kudu::consensus::OpId::OpId() > > Reverting this patch fixes the issue here. I second that. A library built with gcc10 is not linking with a program built with clang. Why would clang not call the complete class constructor, though?
[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513 Fabio Alemagna changed: What|Removed |Added CC||falemagn at gmail dot com --- Comment #6 from Fabio Alemagna --- (In reply to Jonathan Wakely from comment #3) > (In reply to petschy from comment #0) > > For c++11 and later code, why is NULL defined as __null, rather than > > nullptr? > > Because defining NULL as nullptr would violate the requirements of the > standard, which very intentionally says that NULL is an integral constant > expression, not nullptr. I don't know how autoritative is it, but cppreference.com says that since C++11, NULL is an integer literal with value zero, or a prvalue of type std::nullptr_t See: http://en.cppreference.com/w/cpp/types/NULL
[Bug driver/85153] New: _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
Bug ID: 85153
Summary: _Pragma to disable -Wswitch-unreachable diagnostic not
properly working when used within preprocessor macro
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
Created attachment 43809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43809&action=edit
The preprocessed source, which works as expected
The preprocessed output (attached) behaves as expected, so I assume this
problem has to do with the driver and/or a strange interaction between driver,
preprocessor and compiler. For lack of better knowledge, I've filed this bug
under the "driver" component.
The whole code is on godbolt: https://godbolt.org/g/rTc3AU
Given the following code, g++ properly emits a warning.
int x;
int test1(int val) {
switch (val) {
if (!x) {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test1(int)’:
pragmatest.cpp:5:25: warning: statement will never be executed
[-Wswitch-unreachable]
if (!x) {
^~
If I then try to silence this warning with the proper _Pragma directive, in
clear, like in the following code, it works as expected as in the compiler
doesn't complain any longer:
int test2(int val) {
switch (val) {
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wswitch-unreachable\"")
if (!x) {
_Pragma("GCC diagnostic pop")
case 1: return 10;
}
}
return 0;
}
If I then try to to hide the pragmas within 2 macros, like in the following
code, it still works:
#define B _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored
\"-Wswitch-unreachable\"")
#define E _Pragma("GCC diagnostic pop")
int test3(int val) {
switch (val) {
B if (!x) E {
case 1: return 10;
}
}
return 0;
}
However, if now I want to turn the whole "B if (!x) E" statement into a define
of its own, like in the following code, it doesn't work any longer.
#define X() B if (!x) E
int test4(int val) {
switch (val) {
X() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test4(int)’:
pragmatest.cpp:39:23: warning: statement will never be executed
[-Wswitch-unreachable]
#define X() B if (!x) E
^~
pragmatest.cpp:43:21: note: in expansion of macro ‘X’
X() {
^
This looked quite odd, and at first thought I couldn't figure out what was
going on, but then I thought of using a layer of indirection around the pragma
macros, thinking it might have something to do with secondary expansion, so I
tried the following code, but still no luck.
#define Y(x) x
#define X2() Y(B) if (!x) Y(E)
int test5(int val) {
switch (val) {
X2() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test5(int)’:
pragmatest.cpp:52:27: warning: statement will never be executed
[-Wswitch-unreachable]
#define X2() Y(B) if (!x) Y(E)
^~
pragmatest.cpp:55:21: note: in expansion of macro ‘X2’
X2() {
^~
So I tried something which in my mind wouldn't make sense at all - notice that
I wrapped the x **variable** in the Y() macro - but what did I have to lose
anyway? But the following code still (unsurprinsigly?) didn't work:
#define X3() Y(B) if (!Y(x)) Y(E)
int test6(int val) {
switch (val) {
X3() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test6(int)’:
pragmatest.cpp:63:27: warning: statement will never be executed
[-Wswitch-unreachable]
#define X3() Y(B) if (!Y(x)) Y(E)
^
pragmatest.cpp:66:21: note: in expansion of macro ‘X3’
X3() {
^~
However this time around the warning message gave me a hint! Why would the
compiler complain only about the exclamation mark not being reachable? So I
tried the following... and it worked!
#define X4() Y(B) if (Y(!)x) Y(E)
int test7(int val) {
switch (val) {
X4() {
cas
[Bug driver/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153 Fabio Alemagna changed: What|Removed |Added Attachment #43809|0 |1 is obsolete|| --- Comment #1 from Fabio Alemagna --- Created attachment 43810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43810&action=edit The preprocessed source, which works as expected The real one. The previous one was from another test.
[Bug driver/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
--- Comment #2 from Fabio Alemagna ---
And removing the exclamation mark from the if condition actually makes it work
again, but only if the B and E macro are wrapped within the Y() macro,
otherwise it still complains, now indicating the parenthesis as the problem:
#define X6() B if (x) E
int test9(int val) {
switch (val) {
X6() {
case 1: return 10;
}
}
return 0;
}
pragmatest.cpp: In function ‘int test9(int)’:
pragmatest.cpp:96:25: warning: statement will never be executed
[-Wswitch-unreachable]
#define X6() B if (x) E
^
pragmatest.cpp:99:21: note: in expansion of macro ‘X6’
X6() {
^~
[Bug c++/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153 --- Comment #4 from Fabio Alemagna --- @(In reply to Richard Biener from comment #3) > Confirmed. Not sure what the exact limit is but some of the warnings can > only be disabled at function granularity and placing the pragmas in macros > might interfere with this. But the preprocessed output shows the #pragma's all at the expected place and compiling the preprocessed output works as expected. I only ever delved into gcc's innards in one of its old releases and don't know if anything has changed meanwhile about this, but afaik the compiler always works on the preprocessed output, and if this still holds true, how can it be explained that invoking g++ on the un-preprocessed output produces a different result than invoking it on the preprocessed output?
[Bug c++/79362] New: internal compiler error: Segmentation fault - mmap: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79362
Bug ID: 79362
Summary: internal compiler error: Segmentation fault - mmap:
Cannot allocate memory
Product: gcc
Version: 7.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 cannot reproduce the bug locally, so I cannot provide more details, but it
does happen on godbolt where I was experimenting with the adherence to the
standard of various compilers.
This is the code that fails:
struct Base {
};
struct Derived: Base {
using Base::Base;
Derived(int value):
m_value(value)
{}
int m_value;
};
Derived t;
The error given reads like this:
:14:9: internal compiler error: Segmentation fault
Derived t;
^
mmap: Cannot allocate memory
Locally, I've traced the compiler with the massif valgrind's tool, but the
maximum amount of memory allocated was at around 1MiB.
You can check gcc7 output on godbolt at this link: https://godbolt.org/g/FnyE9N
[Bug c++/79362] internal compiler error: Segmentation fault - mmap: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79362 --- Comment #2 from Fabio Alemagna --- I had looked for possible duplicates but found none, sorry about that and glad to know it's already been fixed. Thanks for your time!
[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
[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&action=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 &ext_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++/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 &ext_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++/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++/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 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 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 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 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] "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 #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++/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++/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&action=edit Generated with -freport-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 #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] [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 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.
