[Bug c++/98150] Segfault from statement expression in lambda noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150 --- Comment #2 from Nick Krempel --- Realised it doesn't need C++20 and was able to repro back in gcc 6.1 too.
[Bug c++/98150] Segfault from statement expression in lambda noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
--- Comment #1 from Nick Krempel ---
The following slightly simpler code also repros the issue:
int main() {
[]()noexcept(({constexpr int&=1;}));
}
[Bug c++/98150] New: Segfault from statement expression in lambda noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98150
Bug ID: 98150
Summary: Segfault from statement expression in lambda noexcept
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
The following code produces a segfault in gcc versions 8.1 up to 10.2 and trunk
(using -std=c++2a or -std=c++20):
int main() {
[]()noexcept(noexcept(({constexpr int&=1;})));
}
Here's the stack trace from trunk (https://gcc.godbolt.org/z/nqoojv):
: In function 'int main()':
:2:44: internal compiler error: Segmentation fault
2 | []()noexcept(noexcept(({constexpr int&=1;})));
|^
0x1c354c9 internal_error(char const*, ...)
???:0
0x80119c mangle_ref_init_variable(tree_node*)
???:0
0x6b4419 make_temporary_var_for_ref_to_temp(tree_node*, tree_node*)
???:0
0x9892ae store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0x7974d0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x87f79c c_parse_file()
???:0
0x9f9512 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
ASM generation compiler returned: 1
: In function 'int main()':
:2:44: internal compiler error: Segmentation fault
2 | []()noexcept(noexcept(({constexpr int&=1;})));
|^
0x1c354c9 internal_error(char const*, ...)
???:0
0x80119c mangle_ref_init_variable(tree_node*)
???:0
0x6b4419 make_temporary_var_for_ref_to_temp(tree_node*, tree_node*)
???:0
0x9892ae store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0x7974d0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x87f79c c_parse_file()
???:0
0x9f9512 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Execution build compiler returned: 1
[Bug c++/94264] New: Array-to-pointer conversion not performed on array prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264
Bug ID: 94264
Summary: Array-to-pointer conversion not performed on array
prvalues
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
I think the most clearcut example is:
int main() {
using T = int[];
T{1, 2} == nullptr;
}
This compiles fine with clang, and is supported by the standard: the ==
operator explicitly performs array-to-pointer conversion
(https://eel.is/c++draft/expr#eq-1), and array-to-pointer conversion is
explicitly defined for rvalue arrays (https://eel.is/c++draft/expr#conv.array).
Other examples (which again all compile with clang) are:
+T{1, 2};
Here the standard wording seems to have a minor bug, as unary "+" does not
explicitly perform the array-to-pointer conversion, and the general rubric for
applying it (https://eel.is/c++draft/expr#basic.lval-6) only applies to
glvalues as written.
T{1, 2} + 1;
Ditto.
*(T{1, 2} + 1);
Interesting as T{1, 2}[1] should be equivalent to this (modulo the value
category of the result, https://eel.is/c++draft/expr#sub), yet the former is
rejected by gcc and the latter accepted.
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 --- Comment #4 from Nick Krempel --- Thanks, accepted.
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 --- Comment #2 from Nick Krempel --- I believe the same issue afflicts libc++, but not MSVC's implementation.
[Bug libstdc++/90934] std::vector self-move-insert yields incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934 --- Comment #1 from Nick Krempel --- (The same buggy behavior is seen with "emplace" instead of "insert".)
[Bug libstdc++/90934] New: std::vector self-move-insert bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90934
Bug ID: 90934
Summary: std::vector self-move-insert bug
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
Inserting into a vector with an rvalue reference to an item already in the
vector produces incorrect results (specifically when inserting prior to the
existing location and when a resize is *not* required):
#include
#include
#include
int main() {
std::vector v{1, 2};
v.reserve(3);
v.insert(v.begin(), std::move(v.back()));
for (auto x : v) {
std::cout << x << std::endl;
}
}
This outputs "1 1 2" instead of "2 1 2". Removing either the "reserve" or the
"std::move" gives the correct result.
(https://wandbox.org/permlink/qeBMggNmvISHlPIx)
[Bug c++/90546] [9/10 Regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546
--- Comment #4 from Nick Krempel ---
Here's one way to turn it into a test case which fails to compile:
struct Foo {};
void test(const Foo&) {}
Foo f;
struct Bar {
template operator T&&() = delete;
};
template<> Bar::operator const Foo&&() {
return static_cast(f);
}
int main() {
test(Bar{});
}
[Bug c++/61663] [DR 976] Deduction for const T& conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61663 Nick Krempel changed: What|Removed |Added CC||ndkrempel at gmail dot com --- Comment #2 from Nick Krempel --- Clang accepts the code since at least as far back as 3.0.0.
[Bug c++/90546] [9.1 regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #2 from Nick Krempel --- However it's also worth noting that if you take the original snippet and change the declaration of "test" to accept a const rvalue reference instead: "void test(const Foo&&);", then gcc 9.1 (and all other gcc and clang versions tested) agree that T = const Foo in that case. So even if the standard is ambiguous, gcc is still somewhat inconsistent.
[Bug c++/90546] [9.1 regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546 --- Comment #1 from Nick Krempel --- My interpretation of the standard didn't take into account the reference to http://eel.is/c++draft/over.match.ref when determining the type A. It says that A will be "lvalue reference to cv2 T2 ... where cv1 T is reference-compatible with cv2 T2". Here "cv1 T" is "const Foo". This seems to allows cv2 T2 to be either "Foo" or "const Foo", hence A can be either "Foo&" or "const Foo&". It's not clear which is supposed to be picked for use in the template argument deduction in that case! It seems it was expected for there to be a unique type from the wording: "... with the type that is required as the result of the conversion (call it A; ..." (note "*the* type", "call *it* A").
[Bug c++/90546] New: [9.1 regression] Incorrect template argument deduction for conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90546
Bug ID: 90546
Summary: [9.1 regression] Incorrect template argument deduction
for conversion functions
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
The following code deduces T = Foo using gcc 9.1, whereas gcc 8.3 (and clang 7
up) deduced T = const Foo. My reading of the standard (see below) is that T =
const Foo is correct.
struct Foo {};
void test(const Foo&);
struct Bar {
template operator T&&();
};
int main() {
test(Bar{});
}
(compiled with -std=c++2a, but same behaviour with all language versions)
Relevant standards text: http://eel.is/c++draft/temp.deduct.conv
My reading of this applied to the above program is:
P is T&&, A is const Foo&
P is a reference type -> just treat as T from here on
A is not cv-qualified
A is a reference type -> use const Foo for type deduction
Now attempting to match T with const Foo succeeds with T = const Foo, so we
don't even need to consider the four bulleted exceptional cases ("These
alternatives are considered only if type deduction would otherwise fail.")
[Bug c++/89548] New: reinterpret_cast treats xvalue as prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548
Bug ID: 89548
Summary: reinterpret_cast treats xvalue as prvalue
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
The following program fails to compile (with -std= any of c++11, c++14, c++17,
c++2a):
int main() {
reinterpret_cast(static_cast(0));
}
The error reported is:
gcc-xvalue-bug.cc: In function ‘int main()’:
gcc-xvalue-bug.cc:8:48: error: invalid cast of an rvalue expression of type
‘int’ to type ‘int&&’
reinterpret_cast(static_cast(0));
I.e. reinterpret_cast is treating its argument as a prvalue of type "int"
rather than an xvalue of type "int&&". Testing indicates that the return value
from the static_cast is of the correct type and value category, so the problem
lies with the reinterpret_cast.
The static_cast expression could also be replaced with a function returning
"int&&" and the same problem occurs.
The same problem also occurs when less trivial conversions are requested, for
example "reinterpret_cast(static_cast(0))".
For comparison, clang does not give an error, and that is consistent with my
reading of the standards.
[Bug c++/70570] New: Assembler error "symbol already defined" from nested lambdas and function-static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70570 Bug ID: 70570 Summary: Assembler error "symbol already defined" from nested lambdas and function-static variable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ndkrempel at gmail dot com Target Milestone: --- Created attachment 38209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38209=edit Minimal test case, compile with g++ -std=c++14 Referring to a function-static variable from within both of two nested lambda functions (the outer one being generic/polymorphic) causes an assembler error (symbol already defined). Minimal test case attached, tested on g++ 5.3.0.
[Bug c++/55120] New: Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
Bug #: 55120
Summary: Inaccessible virtual base constructor does not prevent
generation of default constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ndkrem...@gmail.com
The following code should fail to compile but does not:
struct V {};
struct B : private virtual V {};
struct D : B {};
int main() {
D d;
}
According to N3376 section 12.1 paragraph 5, the defaulted default constructor
for D should be defined as deleted, as the default constructor for the virtual
base V is inaccessible from D.
[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120
--- Comment #1 from Nick Krempel ndkrempel at gmail dot com 2012-10-29
16:08:49 UTC ---
Not so clear this is a bug, as the default constructor for D could be generated
in the following form:
struct D : B {
D() : B(), ::V() {}
}
Note the reference to V via the global scope, which is essential for it to
compile.
[Bug c++/55120] Inaccessible virtual base constructor does not prevent generation of default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55120 --- Comment #4 from Nick Krempel ndkrempel at gmail dot com 2012-10-29 22:41:48 UTC --- I think the standard is unclear on this. That defect report has been queried by experts. It comes down to something subtle about how the generated default constructor attempts to refer to the virtual base - whether there is some kind of name lookup of the virtual base itself going on, or whether it just 'knows' what the right class is so that the only lookup is for the default constructor *within* the virtual base class. See Johannes Schaub's answer at http://stackoverflow.com/a/2371368/1395057 for more along these lines, arguing that the current GCC behavior is in fact correct. For what it's worth, I tend to agree with GCC's current behavior (and it seems more useful too.)
