[Bug c++/79415] New: -fcheck-pointer-bounds results in internal compiler error weakref attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79415
Bug ID: 79415
Summary: -fcheck-pointer-bounds results in internal compiler
error weakref attributes
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
GCC 7.0.1 (git hash 7458afd6b35c4851d146f058435ba3dd6215db44) results in
internal compiler error on following input with -fcheck-pointer-bounds and
-mmpx options on x86_64 architecture:
void fn1();
static __typeof fn1 fn2 __attribute__((__weakref__("")));
void fn3() { void *a = (void *)fn2; }
When I compile that code, I get following output:
$ gcc-bin/bin/g++ --std=c++11 -c -fcheck-pointer-bounds -mmpx
gcc-error-verify-cgraph-node-failed.cc
gcc-error-verify-cgraph-node-failed.cc:3:37: error: node is weakref but not an
transparent_alias
void fn3() { void *a = (void *)fn2; }
^
_ZL3fn2v.chkp/5 (void fn2.chkp()) @0x7fb2e16b7450
Type: function alias weakref target:
Visibility: weak
Address is taken.
References:
Referring: _Z3fn3v.chkp/2 (addr)
Availability: not_available
First run: 0
Function flags:
Called by:
Calls:
Is instrumented version.
gcc-error-verify-cgraph-node-failed.cc:3:37: internal compiler error:
verify_cgraph_node failed
0x92460b cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3490
0x91937c symtab_node::verify()
../../gcc/gcc/symtab.c:1183
0x91944f symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1203
0xb626a5 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:616
0xb626a5 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.c:698
0xc53fce execute_todo
../../gcc/gcc/passes.c:2030
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.
gcc -v returns following information on Ubuntu 14.04 based x86_64 system:
Using built-in specs.
COLLECT_GCC=/home/ejusjud/local/gcc-bin/bin/g++
COLLECT_LTO_WRAPPER=/local/ejusjud/gcc-bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin
Thread model: posix
gcc version 7.0.1 20170207 (experimental) (GCC)
[Bug c++/79414] New: internal compiler error after "error: expected unqualified-id at end of input"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79414
Bug ID: 79414
Summary: internal compiler error after "error: expected
unqualified-id at end of input"
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
GCC 7.0.1 (git commit 7458afd6b35c4851d146f058435ba3dd6215db44) segmentation
faults on following code after "error: expected unqualified-id at end of
input". I encountered this while applying C-Reduce to another type of crash:
class x0;
template x2() {
x0 x3 = x3.
If I try to compile this with "gcc-bin/bin/g++ tst.cc" command, it will result
in following output:
tst.cc:2:11: error: ‘x1’ has not been declared
template x2() {
^~
tst.cc:2:18: error: ISO C++ forbids declaration of ‘x2’ with no type
[-fpermissive]
template x2() {
^
tst.cc: In function ‘int x2()’:
tst.cc:3:4: warning: ‘x3’ has incomplete type
x0 x3 = x3.
^~
tst.cc:1:7: note: forward declaration of ‘class x0’
class x0;
^~
tst.cc:3:11: error: expected unqualified-id at end of input
x0 x3 = x3.
^
tst.cc:3:11: internal compiler error: Segmentation fault
0xd27c4f crash_signal
../../gcc/gcc/toplev.c:333
0x60a355 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6877
0x708c2c cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19398
0x70947c cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12792
0x70a235 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12617
0x70ace9 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12227
0x6e59c3 cp_parser_statement
../../gcc/gcc/cp/parser.c:10714
0x6e6a5d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11046
0x6e6b2f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11000
0x6fad43 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21450
0x6fad43 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21488
0x7037a1 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26255
0x708fa0 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26167
0x708fa0 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19177
0x6e2a0a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:26713
0x702ddc cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26317
0x702a6c cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26552
0x702a6c cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:26571
0x6e2ed9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12464
0x71369b cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12391
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.
gcc -v gives following output on x86_64 Ubuntu 14.04 based system:
Using built-in specs.
COLLECT_GCC=/home/ejusjud/local/gcc-bin/bin/g++
COLLECT_LTO_WRAPPER=/local/ejusjud/gcc-bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin
Thread model: posix
gcc version 7.0.1 20170207 (experimental) (GCC)
[Bug preprocessor/78287] New: #line directive with value more than 2147483640 prints out the value twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78287 Bug ID: 78287 Summary: #line directive with value more than 2147483640 prints out the value twice Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jussi.judin at ericsson dot com Target Milestone: --- If I give a number with value more than 2147483640 (basically 7 maximum values, 2147483641-2147483647, that are allowed for #line directive), the resulting output from cpp results in the line number and file name printed twice. Following example demonstrates the issue: #line 2147483639 a #line 2147483640 b #line 2147483641 c #line 2147483642 d #line 2147483643 e #line 2147483644 f #line 2147483645 g #line 2147483646 h #line 2147483647 i When running this through cpp (GCC 4.8 and the latest git master as of today) it results in following output where line numbers over 2147483640 are printed twice: # 1 "line.c" # 1 "" # 1 "" # 31 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "" 2 # 1 "line.c" # 2147483639 "line.c" a # 2147483640 "line.c" b # 2147483641 "line.c" # 2147483641 "line.c" c # 2147483642 "line.c" # 2147483642 "line.c" d # 2147483643 "line.c" # 2147483643 "line.c" e # 2147483644 "line.c" # 2147483644 "line.c" f # 2147483645 "line.c" # 2147483645 "line.c" g # 2147483646 "line.c" # 2147483646 "line.c" h # 2147483647 "line.c" # 2147483647 "line.c" i
[Bug c/68337] New: [MPX] memcpy() for arrays with function pointers results in huge resource usage and binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68337
Bug ID: 68337
Summary: [MPX] memcpy() for arrays with function pointers
results in huge resource usage and binaries
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
Created attachment 36703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36703=edit
Preprocessed source file including string.h
If I compile following program with GCC 5.2.0 with following options, it takes
around 7.6 seconds to compile and uses over 500 megabytes of memory (Maximum
resident set size):
$ gcc -save-temps -fcheck-pointer-bounds -mmpx -o mpx-funcptr-explosion -c
mpx-funcptr-explosion.c
#include
#define ARRAY_SIZE 8192
typedef int (* funcptr_t) (void);
typedef struct {
int data;
funcptr_t callback1;
funcptr_t callback2;
funcptr_t callback3;
funcptr_t callback4;
} funcptr_struct_t;
funcptr_struct_t source[ARRAY_SIZE];
void memcpy_user(void) {
funcptr_struct_t target[ARRAY_SIZE];
memcpy(target, source, sizeof(source));
}
The resulting binary takes 4197096 bytes and assembly file 8117029 bytes. Every
funcptr_t instance I add to the structure adds around 2.6 seconds to execution
time of the compilation. This basically makes it impossible to use static
memory with callback functions with MPX support, as it explodes the compilation
resources and the resulting binary.
GCC has following specifications:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/local/ejusjud/intel-mpx/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --enable-libmpx
--with-as=/home/ejusjud/local/intel-mpx/bin/as
--with-ld=/home/ejusjud/local/intel-mpx/bin/ld
--prefix=/home/ejusjud/local/intel-mpx
Thread model: posix
gcc version 5.2.0 (GCC)
[Bug other/68270] New: Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
Bug ID: 68270
Summary: Common pattern for variable sized data clashes with
MPX bound checks
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
A very common pattern due to pedantic C89, C90, and C++ compatibility is to
declare an array of size 1 when having a structure with a variable sized member
at the end. GCC's memory protection extensions, however, work in a way that
only zero/variable sized members are treated in such way that their bounds are
not explicitly checked
(https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#line-142).
This makes it impossible to use existing code with MPX checks without changes
that go through large amount of header files that use this pattern of arrays
size 1.
To demonstrate this issue, here are 3 different ways to indicate structures
with a variable sized array at the end of the structure:
typedef struct struktura1 {
long len;
char data[];
} struktura1;
typedef struct struktura2 {
long len;
char data[0];
} struktura2;
typedef struct struktura3 {
long len;
char data[1] __attribute__((bnd_variable_size));
} struktura3;
If we compile them with different standards and warning levels, we'll get these
kind of results:
$ gcc-5.2.0 --std=c89 -pedantic tst.c
tst.c:3:10: warning: ISO C90 does not support flexible array members
[-Wpedantic]
char data[];
^
tst.c:8:10: warning: ISO C forbids zero-size array ‘data’ [-Wpedantic]
char data[0];
$ gcc-5.2.0 -xc++ --std=c++14 -pedantic tst.c
tst.c:3:15: warning: ISO C++ forbids zero-size array ‘data’ [-Wpedantic]
char data[];
^
tst.c:8:16: warning: ISO C++ forbids zero-size array ‘data’ [-Wpedantic]
char data[0];
$ gcc-4.8 --std=c11 -pedantic tst.c
tst.c:8:10: warning: ISO C forbids zero-size array ‘data’ [-Wpedantic]
char data[0];
^
tst.c:13:5: warning: ‘bnd_variable_size’ attribute directive ignored
[-Wattributes]
char data[1] __attribute__((bnd_variable_size));
^
Not to mention that a lot of code is compiled with other compilers than GCC
that don't know about "bnd_variable_size" attribute, so making the code shown
above to be compatible with different compilers and also having MPX checks in
place requires some macro magic depending on which compiler is in use and which
standard the compilation is done against.
GCC should ignore or have an option to ignore bound checks for arrays of size 1
at the end of the structure so that just trying out MPX support wouldn't need
large scale changes to existing code bases.
[Bug other/67520] New: libmpx should abort() instead of exit(255) on bound violation detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67520
Bug ID: 67520
Summary: libmpx should abort() instead of exit(255) on bound
violation detection
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
libmpx should do an action that can be easily caught in a debugger or runtime
testing program (like core dump) instead of doing exit(255) whenever bound
violation error is detected. Currently libmpx apparently does following in
libmpx/mpxrt/mpxrt.c if environment variable CHKP_RT_MODE=stop:
if (__mpxrt_mode () == MPX_RT_STOP)
exit (255);
To catch this I need to change the program under test to include a exit handler
that looks for exit code 255 with the assumption that nothing else triggers
exit code 255:
#include
#include
static void exit_abort(int code, void* wanted_code)
{
if (code == (intptr_t)wanted_code)
{
abort();
}
}
int main()
{
static int foo[50];
int* bar = foo;
on_exit(exit_abort, (void*)(intptr_t)255);
return bar[50];
}
Compiling this with "-g3 -fno-omit-frame-pointer -fcheck-pointer-bounds -mmpx"
and linking mpx-runtime64 from Intel achieves the wanted result of being able
to immediately examine the program when such abort happens. But in this case
you need to modify the original program and know that the program will exit
with code 255 when it hits this failing bound violation check. It would be much
more easy to have the program to abort and result in a core dump or SIGABRT
signal capture in a debugger.
So what about changing CHKP_RT_MODE environmental variable to also include
"abort" value or changing the default "stop" behavior to abort instead of
exit(255)?
[Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Bug ID: 67442
Summary: GCC 5.2.0 on x86_64 creates invalid address on
specific array index calculation through pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
GCC 5.2.0 and the current git version
(ae436f3bdc66153005b7a260e0239521679f3965) create invalid address to access
array index calculated in specific way on x86_64 platform:
short foo[100];
int main()
{
short* bar = [50];
short i = 1;
short j = 1;
short value = bar[8 - i * 2 * j];
return value;
}
$ ~/local/gcc-bin/bin/gcc -v -save-temps -Wall -Wextra -g3 -ggdb tst.c
$ ./a.out
Segmentation fault (core dumped)
$ gdb a.out core
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x004004d5 in main () at tst.c:8
8 short value = bar[8 - i * 2 * j];
(gdb) disassemble /m 0x004004d5
8 short value = bar[8 - i * 2 * j];
0x004004ae <+24>:movswq -0xa(%rbp),%rdx
0x004004b3 <+29>:movswq -0xc(%rbp),%rax
0x004004b8 <+34>:imul %rax,%rdx
0x004004bc <+38>:mov%rdx,%rax
0x004004bf <+41>:shl$0x1e,%rax
0x004004c3 <+45>:sub%rdx,%rax
0x004004c6 <+48>:shl$0x2,%rax
0x004004ca <+52>:lea0x10(%rax),%rdx
0x004004ce <+56>:mov-0x8(%rbp),%rax
0x004004d2 <+60>:add%rdx,%rax
=> 0x004004d5 <+63>:movzwl (%rax),%eax
0x004004d8 <+66>:mov%ax,-0xe(%rbp)
(gdb) p [8 - i * 2 * j]
$3 = (short *) 0x600970 <foo+112>
(gdb) p/x $rax
$2 = 0x100600970
So there is 0x1 added somewhere to the address that is used for the
actual array access. I have seen value 0x5 added in the production code
I encountered this issue. It seems to need following parts to trigger:
reference to an array ([50], foo could also be on stack, but it creates
more nasty addresses), array index access through pointer by [const1 - var1 *
const2 * var2], where const1 > 0 and const2 > 1. I just used values 8 and 2 to
demonstrate that we don't access negative indexes, whereas the actual signal
processing code I encountered this does.
If I assign this array index to a variable and use it to access the array
through pointer, then GCC creates correct binary. Also if I use -m32 to compile
for x86, this does not result in segmentation fault. So it looks like it's
x86_64 specific issue.
The system I used to compile this GCC is x86_64 Ubuntu 14.04 based one. GCC
returns following information about itself:
$ ~/local/gcc-bin/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/ejusjud/local/gcc-bin/bin/gcc
COLLECT_LTO_WRAPPER=/local/ejusjud/gcc-bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ejusjud/local/gcc-bin
Thread model: posix
gcc version 6.0.0 20150902 (experimental) (GCC)
And about the tools and other libraries during the compilation:
GNU C11 (GCC) version 6.0.0 20150902 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20150902 (experimental), GMP version
5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 6.0.0 20150902 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20150902 (experimental), GMP version
5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2b4ce747c000701038232915f15d53af
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-g3' '-ggdb'
'-mtune=generic' '-march=x86-64'
as -v --64 -o tst.o tst.s
GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24
[Bug c++/57552] New: Internal compiler error with vector::emplace_back() for templated class constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552
Bug ID: 57552
Summary: Internal compiler error with vector::emplace_back()
for templated class constructor
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Created attachment 30271
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30271action=edit
Intermediate precompiled file resulting from this compilation
I'm getting an internal compiler error when trying to compile following code
with GCC 4.7.3 and with the 20130601 snapshot of 4.7 compiler series:
#include vector
templatetypename T
class TemplateKlass
{
};
void funktion()
{
std::vectorTemplateKlassint result;
char segment;
result.emplace_back(segment);
}
Here there is no constructor defined in TemplateKlass, but I get the same crash
if I define proper constructors. GCC 4.7.3 results in following compiler output
with given arguments:
$ /tmp/c-4.7-3/bin/g++ -save-temps --verbose --std=c++11 -o out.o -c code.cc
Using built-in specs.
COLLECT_GCC=/tmp/c-4.7-3/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/tmp/c-4.7-3
Thread model: posix
gcc version 4.7.3 (GCC)
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-std=c++11' '-o' 'out.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/tmp/c-4.7-3/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -E -quiet -v
-imultilib . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE code.cc -mtune=generic
-march=x86-64 -std=c++11 -fpch-preprocess -o code.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/ejusjud/compiles/include
.
/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3
/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/x86_64-unknown-linux-gnu/.
/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/../../../../include/c++/4.7.3/backward
/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include
/usr/local/include
/tmp/c-4.7-3/include
/tmp/c-4.7-3/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-std=c++11' '-o' 'out.o' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/tmp/c-4.7-3/libexec/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1plus -fpreprocessed
code.ii -quiet -dumpbase code.cc -mtune=generic -march=x86-64 -auxbase-strip
out.o -std=c++11 -version -o code.s
GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.1.2, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.1.2, MPFR version
3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ebd72fbdf2a173314a31a8680934f115
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The 20130601 snapshot will result in similar output. Also attached the
intermediate .ii precompiled file.
[Bug c++/57552] Internal compiler error with vector::emplace_back() for templated class constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552 --- Comment #1 from Jussi Judin jussi.judin at ericsson dot com --- Created attachment 30272 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30272action=edit GCC 4.7-20130601 snapshot output
[Bug c++/57552] Internal compiler error with vector::emplace_back() for templated class constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57552 --- Comment #2 from Jussi Judin jussi.judin at ericsson dot com --- Created attachment 30273 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30273action=edit GCC 4.7-20130601 snapshot intermediate precompiled file.
