[Bug c++/87844] New: ICE in tsubst_copy using non-constant expression as a non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87844
Bug ID: 87844
Summary: ICE in tsubst_copy using non-constant expression as a
non-type template argument
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curlypaul924 at gmail dot com
Target Milestone: ---
The following code causes ICE in every version I tried from 4.9.0 through 8.2,
as well as trunk:
struct C {
static constexpr bool call(bool) { return true; }
};
template
struct B {};
auto foo(bool b) {
auto f = [](auto c) -> B { };
f(C());
}
int main() {
foo(true);
}
Compile with either -std=c++14 or -std=c++17.
Clang (I believe correctly) rejects this code with "non-type template argument
is not a constant expression".
[Bug c++/87765] New: Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765
Bug ID: 87765
Summary: Internal compiler error: coerce_template_parms (8.2)
or cxx_eval_constant_expression (trunk)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curlypaul924 at gmail dot com
Target Milestone: ---
The following syntactically valid program produces an ICE in
coerce_template_parms on gcc 8.2:
template
using foo = int;
struct A {
constexpr int bar() const { return 42; }
};
void baz(A a) {
[=](auto c) { return foo { }; };
}
creduce produced a syntactically invalid program which also causes ICE:
template
using foo = int;
struct A {
int bar();
};
void baz(A a) {
[](auto foo
}
x86-64 gcc trunk on godbolt.org also ICEs, but in cxx_eval_constant_expression.
Clang accepts the first snippet, but gcc 7.3 rejects it with "error:
'__closure' is not a constant expression".
Possibly related to (or duplicate of) Bug 86960.
[Bug middle-end/87296] New: -Wstringop-overflow false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
Bug ID: 87296
Summary: -Wstringop-overflow false positive
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: curlypaul924 at gmail dot com
Target Milestone: ---
Tested on gcc 8.1 and 8.2 on Ubuntu 16.04, and also on gcc (trunk) on
gcc.godbolt.org.
The following code:
extern "C" char *strncpy(char *, const char *, unsigned long);
void fill(char const * begin, char const * end, char c);
struct q {
char ids[4];
char username[6];
};
q & get();
int main() {
auto & c = get();
fill(c.ids, c.ids + sizeof(c.ids), '\0');
strncpy(c.username, "root", sizeof(c.username));
}
when compiled with g++ -O1 on x86-64, produces:
v.cpp: In function ‘int main()’:
v.cpp:16:10: warning: ‘char* strncpy(char*, const char*, long unsigned int)’
writing 6 bytes into a region of size 4 overflows the destination
[-Wstringop-overflow=]
strncpy(c.username, "root", sizeof(c.username));
~~~^~~~
It seems that the compiler is confusing ids and username, somehow related to
passing c.ids + 4 to fill().
If I reduce the size of username to 5 bytes, the compiler generates MOV BYTE
instead of MOV DWORD for the null-padding, and there is no warning.
[Bug c++/86763] [7/8 Regression] Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86763 --- Comment #12 from Paul Brannan --- (In reply to Richard Biener from comment #9) > The following seems to work, will test. > > Index: gcc/cp/class.c > === > --- gcc/cp/class.c (revision 263209) > +++ gcc/cp/class.c (working copy) > @@ -6243,6 +6243,7 @@ layout_class_type (tree t, tree *virtual > bitsize_int (BITS_PER_UNIT))); >SET_TYPE_ALIGN (base_t, rli->record_align); >TYPE_USER_ALIGN (base_t) = TYPE_USER_ALIGN (t); > + TYPE_TYPELESS_STORAGE (base_t) = TYPE_TYPELESS_STORAGE (t); > >/* Copy the non-static data members of T. This will include its > direct non-virtual bases & vtable. */ This patch fixes the failure in my original (non-reduced test case).
[Bug c++/86763] New: Wrong code comparing member of copy of a 237 byte object with nontrivial default constructor on x86-64 arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86763
Bug ID: 86763
Summary: Wrong code comparing member of copy of a 237 byte
object with nontrivial default constructor on x86-64
arch
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curlypaul924 at gmail dot com
Target Milestone: ---
Created attachment 44475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44475=edit
.ii file generated from t4.cpp
The following program produces an incorrect result on GCC 8.1 and 8.2. It
succeeds on 7.2.
AFAICT, the problem is that the comparison happens before the object has been
copied. The compiler could compare using the temporary stored in rdx, but it
instead compares using the value at [rsp+8], which isn't yet written to.
This happens when using -march=x86-64, but does not happen on -march=core2 or
newer. In these cases, memcpy is used to do the copy, and the comparison
happens after the call to memcpy.
Moreover, GCC misses an opportunity to optimize away the copy altogether.
Clang 6.0.0 does optimize away the copy.
The misplaced comparison happens at -O2 or higher; at -O1, the comparison is
done after the copy.
#include
#include
#include
struct ID {
uint64_t value;
};
uint64_t value(ID id) { return id.value; }
uint64_t gen { 1000 };
struct Msg {
uint64_t time;
ID id;
};
struct V {
V() { }
V(Msg const & msg) : msg(msg) { }
Msg & get() { return msg; }
Msg msg;
char pad[237 - sizeof(Msg)];
};
struct T : V { using V::V; };
Msg init_msg() {
Msg msg;
timespec t;
clock_gettime(CLOCK_REALTIME, );
msg.time = t.tv_sec + t.tv_nsec;
msg.id.value = ++gen;
return msg;
}
int main() {
T t;
t = init_msg();
assert(value(t.get().id) == 1001);
}
$ g++-8.1 -std=c++14 -O2 -Wall -Werror -march=x86-64 -save-temps -v t4.cpp
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-8.1
COLLECT_LTO_WRAPPER=/opt/gcc/8.1/libexec/gcc/x86_64-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /home/pbrannan/git/theme_infra/packaging/gcc-8.1.0/configure
--prefix=/opt/gcc/8.1 --enable-languages=c,c++ --with-pkgversion='Thesys GCC
8.1.0 for Ubuntu 16.04' --enable-shared --enable-gnu-unique-object
--enable-threads=posix --enable-checking=release --disable-vtable-verify
--enable-lto --with-ab
i=m64 --enable-multiarch --disable-multilib --with-build-config=bootstrap-lto
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.1.0 (Thesys GCC 8.1.0 for Ubuntu 16.04)
COLLECT_GCC_OPTIONS='-std=c++14' '-O2' '-Wall' '-Werror' '-march=x86-64'
'-save-temps' '-v' '-shared-libgcc'
/opt/gcc/8.1/libexec/gcc/x86_64-linux-gnu/8.1.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE t4.cpp -march=x86-64 -std=c++14
-Wall -Werror -O2 -fpch-preprocess -o t4.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0
/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/x86_64-linux-gnu
/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/backward
/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/include
/usr/local/include
/opt/gcc/8.1/include
/opt/gcc/8.1/lib/gcc/x86_64-linux-gnu/8.1.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++14' '-O2' '-Wall' '-Werror' '-march=x86-64'
'-save-temps' '-v' '-shared-libgcc'
/opt/gcc/8.1/libexec/gcc/x86_64-linux-gnu/8.1.0/cc1plus -fpreprocessed t4.ii
-quiet -dumpbase t4.cpp -march=x86-64 -auxbase t4 -O2 -Wall -Werror -std=c++14
-version -o t4.s
GNU C++14 (Thesys GCC 8.1.0 for Ubuntu 16.04) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Thesys GCC 8.1.0 for Ubuntu 16.04) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6724e7d270573c4346dc08c31ad9ce9
[Bug target/57112] -march=x86-64 not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57112 Paul Brannan changed: What|Removed |Added CC||curlypaul924 at gmail dot com --- Comment #3 from Paul Brannan --- -march=x86-64 is in the man page for gcc 8.2 (it was not in the man page for 5.4; I'm not sure which version it first appears).
[Bug c++/80194] New: ICE with local constant referenced by a lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80194
Bug ID: 80194
Summary: ICE with local constant referenced by a lambda
expression
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curlypaul924 at gmail dot com
Target Milestone: ---
The following causes an ICE on g++ 5.4.0 and on the latest gcc-5-branch. It
does not ICE on 6.0 or later.
int fn1();
template void fn2(Fn &) {
fn(42);
}
void fn2() {
auto const x = fn1();
fn2([&](auto) { x; });
}
Building with -std=c++14, the output is:
test.cpp: In instantiation of ‘fn2()::<lambda(auto:1)> [with auto:1 = int]’:
test.cpp:4:5: required from ‘void fn2(Fn&&) [with Fn =
fn2()::<lambda(auto:1)>]’
test.cpp:9:23: required from here
test.cpp:9:19: internal compiler error: Segmentation fault
fn2([&](auto) { x; });
^
0xaab7ff crash_signal
../.././gcc/toplev.c:383
0x70ac4c maybe_constant_init(tree_node*, tree_node*)
../.././gcc/cp/constexpr.c:4097
0x6320bf tsubst_copy
../.././gcc/cp/pt.c:13180
0x622c68 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:15797
0x62b392 tsubst_expr
../.././gcc/cp/pt.c:14606
0x62a4f6 tsubst_expr
../.././gcc/cp/pt.c:14017
0x62b2dc tsubst_expr
../.././gcc/cp/pt.c:14189
0x62b2dc tsubst_expr
../.././gcc/cp/pt.c:14189
0x62a09d instantiate_decl(tree_node*, int, bool)
../.././gcc/cp/pt.c:20675
0x6597d2 mark_used(tree_node*, int)
../.././gcc/cp/decl2.c:5122
0x5f889b build_over_call
../.././gcc/cp/call.c:7545
0x5fafd1 build_op_call_1
../.././gcc/cp/call.c:4347
0x5fafd1 build_op_call(tree_node*, vec<tree_node*, va_gc, vl_embed>**, int)
../.././gcc/cp/call.c:4370
0x6c3118 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
../.././gcc/cp/semantics.c:2426
0x624d46 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:15434
0x62b392 tsubst_expr
../.././gcc/cp/pt.c:14606
0x62a4f6 tsubst_expr
../.././gcc/cp/pt.c:14017
0x62b2dc tsubst_expr
../.././gcc/cp/pt.c:14189
0x62a09d instantiate_decl(tree_node*, int, bool)
../.././gcc/cp/pt.c:20675
0x63edeb instantiate_pending_templates(int)
../.././gcc/cp/pt.c:20792
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Output of g++ -v:
Using built-in specs.
COLLECT_GCC=/home/pbrannan/opt/gcc-5-branch/bin/g++
COLLECT_LTO_WRAPPER=/home/pbrannan/opt/gcc-5-branch/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --disable-multilib
--prefix=/home/pbrannan/opt/gcc-5-branch : (reconfigured) ./configure
--disable-multilib --prefix=/home/pbrannan/opt/gcc-5-branch
--enable-languages=c,c++,fortran,java,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 5.4.1 20170326 (GCC)
[Bug other/78252] C++ demangler crashes with infinite recursion with lambda (auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252 Paul Brannan changed: What|Removed |Added CC||curlypaul924 at gmail dot com --- Comment #4 from Paul Brannan --- I can confirm Nathan's patch fixes the crash I was seeing with _ZSt7forwardIRZN3Foo3BarEvEUlRT_iE_EOS1_RNSt16remove_referenceIS1_E4typeE
[Bug c++/68159] Demangler crash (GDB PR 19190)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68159 Paul Brannan changed: What|Removed |Added CC||curlypaul924 at gmail dot com --- Comment #8 from Paul Brannan --- I am able to reproduce this segfault with the above instructions on gdb 7.11.
[Bug c++/57498] rethrow_exception causes segfault when another exception is active and catch present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57498 Paul Brannan changed: What|Removed |Added CC||curlypaul924 at gmail dot com --- Comment #1 from Paul Brannan --- Found this via a google search because I was trying to track down unexplained behavior I'm seeing in std::rethrow_exception. I tried the attached test case on 5.3.0 and std::terminate does get called. Perhaps this was fixed with #60612?
