[Bug c++/58627] [4.9 Regression] crash during compilation of boost testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58627
--- Comment #3 from octoploid at yandex dot com ---
Valgrind shows:
markus@x4 /tmp % valgrind --track-origins=yes --trace-children=yes g++ -O2
-std=c++11 -c test.ii
==6647== Memcheck, a memory error detector
==6647== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6647== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6647== Command: g++ -O2 -std=c++11 -c test.ii
==6647==
==6647== Memcheck, a memory error detector
==6647== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6647== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6647== Command: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/g++ -O2 -std=c++11 -c
test.ii
==6647==
==6655== Memcheck, a memory error detector
==6655== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6655== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6655== Command: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus
-fpreprocessed test.ii -quiet -dumpbase test.ii -mtune=generic -march=x86-64
-auxbase test -O2 -std=c++11 -o /tmp/cctcTn3y.s
==6655==
==6655== Invalid read of size 1
==6655==at 0x5E453A: gt_ggc_mx_lang_tree_node(void*) (c-common.h:1211)
==6655==by 0x5E5AEB: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:510)
==6655==by 0x5E61AF: gt_ggc_mx_tinst_level(void*) (gt-cp-tree.h:124)
==6655==by 0x533E3F: gt_ggc_mx_pending_template(void*) (gt-cp-pt.h:44)
==6655==by 0x78A8E5: ggc_mark_root_tab(ggc_root_tab const*)
(ggc-common.c:133)
==6655==by 0x78AC90: ggc_mark_roots() (ggc-common.c:152)
==6655==by 0x65A9EA: ggc_collect() (ggc-page.c:2077)
==6655==by 0x869A4D: execute_one_pass(opt_pass*) (passes.c:2255)
==6655==by 0x869D65: execute_pass_list(opt_pass*) (passes.c:2267)
==6655==by 0x6AF0EB: analyze_function(cgraph_node*) (cgraphunit.c:650)
==6655==by 0x6B0127: analyze_functions() (cgraphunit.c:1004)
==6655==by 0x6B0F35: finalize_compilation_unit() (cgraphunit.c:2262)
==6655== Address 0x17125d8 is not stack'd, malloc'd or (recently) free'd
==6655==
test.ii: In function ‘void
fastest_itl_total_icl_quantifier_check_monoid_plus_4_bicremental_types_invoker()’:
test.ii:3069:14: internal compiler error: Segmentation fault
static void
fastest_itl_total_icl_quantifier_check_monoid_plus_4_bicremental_types_invoker()
{ ::boost::unit_test::unit_test_log.set_checkpoint(
::boost::unit_test::const_string(
"../libs/icl/test/fastest_total_icl_quantifier_/../fastest_total_icl_quantifier_cases.hpp",
sizeof(
"../libs/icl/test/fastest_total_icl_quantifier_/../fastest_total_icl_quantifier_cases.hpp"
) - 1 ), static_cast( 15
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/58893] New: [4.8, 4.9 Regression] :0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893
Bug ID: 58893
Summary: [4.8, 4.9 Regression] :0:0: internal
compiler error: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
Came across this strange segfault:
~ % c++ -include ./gcc_hidden.h -include xxx.h -w -march=native
-fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x
-I/usr/include/cairo -pthread -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/freetype2
-I/usr/include/freetype2 -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer
minimal.cpp
:0:0: internal compiler error: Segmentation fault
gdb shows:
0x00d36791 in linemap_macro_map_lookup(line_maps*, unsigned int) ()
(gdb) bt
#0 0x00d36791 in linemap_macro_map_lookup(line_maps*, unsigned int) ()
#1 0x00d374f5 in linemap_resolve_location(line_maps*, unsigned int,
location_resolution_kind, line_map const**) ()
#2 0x0074f5b6 in diagnostic_report_current_module(diagnostic_context*,
unsigned int) ()
#3 0x004d6c50 in cp_diagnostic_starter(diagnostic_context*,
diagnostic_info*) ()
#4 0x00dfc97b in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) ()
#5 0x00867319 in c_cpp_error(cpp_reader*, int, int, unsigned int,
unsigned int, char const*, __va_list_tag (*) [1]) ()
#6 0x00753a0f in cpp_diagnostic(cpp_reader*, int, int, char const*,
__va_list_tag (*) [1]) ()
#7 0x00753aa3 in cpp_error(cpp_reader*, int, char const*, ...) ()
#8 0x00e01280 in _cpp_find_file ()
#9 0x00e01d3e in _cpp_stack_include ()
#10 0x0087414f in push_command_line_include() ()
#11 0x00d36306 in _cpp_lex_token ()
#12 0x00d3a655 in cpp_get_token_with_location(cpp_reader*, unsigned
int*) ()
#13 0x008734a1 in c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) ()
#14 0x00d4ea93 in c_parse_file() ()
#15 0x00d67477 in c_common_parse_file() ()
#16 0x00da7003 in compile_file() ()
#17 0x00da7aba in toplev_main(int, char**) ()
#18 0x77772a6e in __libc_start_main () from /lib/libc.so.6
#19 0x00d4117a in _start ()
~ % cat gcc_hidden.h
#pragma GCC visibility push(hidden)
~ % cat minimal.cpp
int main () {}
~ %
And xxx.h doesn't exist.
4.7.3 is fine. 4.8 and 4.9 segfault.
[Bug c++/58893] [4.8, 4.9 Regression] :0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893 --- Comment #1 from octoploid at yandex dot com --- gcc with debug info shows: :0:0: internal compiler error: Segmentation fault 0x90321f crash_signal ../../gcc/gcc/toplev.c:335 0xd54c15 linemap_macro_map_lookup ../../gcc/libcpp/line-map.c:718 0xd54c15 linemap_lookup(line_maps*, unsigned int) ../../gcc/libcpp/line-map.c:643 0xd54ecc linemap_macro_loc_to_def_point ../../gcc/libcpp/line-map.c:1134 0xd54ecc linemap_resolve_location(line_maps*, unsigned int, location_resolution_kind, line_map const**) ../../gcc/libcpp/line-map.c:1263 0xd3e47d diagnostic_report_current_module(diagnostic_context*, unsigned int) ../../gcc/gcc/diagnostic.c:511 0x5728cd cp_diagnostic_starter ../../gcc/gcc/cp/error.c:3024 0xd3f0c1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/gcc/diagnostic.c:791 0x634b14 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char const*, __va_list_tag (*) [1]) ../../gcc/gcc/c-family/c-common.c:9607 0xd49148 cpp_diagnostic ../../gcc/libcpp/errors.c:63 0xd49296 cpp_error(cpp_reader*, int, char const*, ...) ../../gcc/libcpp/errors.c:78 0xd4e652 _cpp_find_file ../../gcc/libcpp/files.c:571 0xd4ebed _cpp_stack_include ../../gcc/libcpp/files.c:993 0x6448b5 push_command_line_include ../../gcc/gcc/c-family/c-opts.c:1361 0xd50e25 _cpp_get_fresh_line ../../gcc/libcpp/lex.c:2121 0xd52e86 _cpp_get_fresh_line ../../gcc/libcpp/lex.c:2091 0xd52e86 _cpp_lex_direct ../../gcc/libcpp/lex.c:2168 0xd53d0b _cpp_lex_token ../../gcc/libcpp/lex.c:2042 0xd582f7 cpp_get_token_1 ../../gcc/libcpp/macro.c:2355 0x64250c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../gcc/gcc/c-family/c-lex.c:300 Please submit a full bug report, Program received signal SIGSEGV, Segmentation fault. [Switching to process 18268] 0x00d54e5f in linemap_resolve_location (set=0x77ff8000, loc=4294959819, lrk=lrk@entry=LRK_MACRO_DEFINITION_LOCATION, map=map@entry=0x7fffd2d8) at ../../gcc/libcpp/line-map.c:1242 1242loc = set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus; (gdb) bt #0 0x00d54e5f in linemap_resolve_location (set=0x77ff8000, loc=4294959819, lrk=lrk@entry=LRK_MACRO_DEFINITION_LOCATION, map=map@entry=0x7fffd2d8) at ../../gcc/libcpp/line-map.c:1242 #1 0x00d3e47e in diagnostic_report_current_module (context=context@entry=0x132bca0 , where=) at ../../gcc/gcc/diagnostic.c:511 #2 0x005728ce in cp_diagnostic_starter (context=0x132bca0 , diagnostic=0x7fffd400) at ../../gcc/gcc/cp/error.c:3024 #3 0x00d3f0c2 in diagnostic_report_diagnostic (context=0x132bca0 , diagnostic=diagnostic@entry=0x7fffd400) at ../../gcc/gcc/diagnostic.c:791 #4 0x00634b15 in c_cpp_error (pfile=pfile@entry=0x13783b0, level=level@entry=6, reason=reason@entry=0, location=, location@entry=4294959819, column_override=column_override@entry=0, msg=, ap=ap@entry=0x7fffd4c8) at ../../gcc/gcc/c-family/c-common.c:9607 #5 0x00d49149 in cpp_diagnostic (pfile=0x13783b0, level=6, reason=reason@entry=0, msgid=msgid@entry=0xd9f9dc "%s: %s", ap=ap@entry=0x7fffd4c8) at ../../gcc/libcpp/errors.c:63 #6 0x00d49297 in cpp_error (pfile=, level=, msgid=msgid@entry=0xd9f9dc "%s: %s") at ../../gcc/libcpp/errors.c:78 #7 0x00d4974c in cpp_errno (pfile=, level=, msgid=) at ../../gcc/libcpp/errors.c:236 #8 0x00d4e653 in _cpp_find_file (pfile=pfile@entry=0x13783b0, fname=fname@entry=0x7fffe2e3 "xxx.h", start_dir=0x1354970, fake=fake@entry=false, angle_brackets=angle_brackets@entry=0, implicit_preinclude=implicit_preinclude@entry=false) at ../../gcc/libcpp/files.c:571 #9 0x00d4ebee in _cpp_stack_include (pfile=0x13783b0, fname=0x7fffe2e3 "xxx.h", angle_brackets=angle_brackets@entry=0, type=type@entry=IT_CMDLINE) at ../../gcc/libcpp/files.c:993 #10 0x00d4f11c in cpp_push_include (pfile=, fname=) at ../../gcc/libcpp/files.c:1432 #11 0x006448b6 in push_command_line_include () at ../../gcc/gcc/c-family/c-opts.c:1361 #12 0x00d50e26 in _cpp_get_fresh_line (pfile=pfile@entry=0x13783b0) at ../../gcc/libcpp/lex.c:2121 #13 0x00d52e87 in _cpp_get_fresh_line (pfile=0x13783b0) at ../../gcc/libcpp/lex.c:2091 #14 _cpp_lex_direct (pfile=pfile@entry=0x13783b0) at ../../gcc/libcpp/lex.c:2168 #15 0x00d53d0c in _cpp_lex_token (pfile=0x13783b0) at ../../gcc/libcpp/lex.c:2042 #16 0x00d582f8 in cpp_get_token_1 (pfile=0x13783b0, location=location@entry=0x7fffd928) at ../../gcc/libcpp/macro.c:2355 #17 0x00d58615 in cpp_get_token_with_location (pfile=, loc=loc@entry=0x7fffd928) at ../../gcc/libcpp/macro.c:2537 #18 0x0064250d in c_lex_with_flags (
[Bug other/58925] New: libtool: install: error: cannot install `libcilkrts.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925 Bug ID: 58925 Summary: libtool: install: error: cannot install `libcilkrts.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/ Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: octoploid at yandex dot com ../gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-initfini-array --with-gold --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-boot-ldflags="-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterations=3" --enable-version-specific-runtime-libs --disable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-bootstrap make sudo make install ... make[2]: Entering directory `/var/tmp/gcc_build_dir/x86_64-pc-linux-gnu/libcilkrts' true "AR_FLAGS=rc" "CC_FOR_BUILD=x86_64-pc-linux-gnu-gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "JC1FLAGS=" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr" "infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/info" "libdir=/usr/lib" "prefix=/usr" "includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include" "AR=/usr/x86_64-pc-linux-gnu/bin/ar" "AS=/var/tmp/gcc_build_dir/./gcc/as" "LD=/var/tmp/gcc_build_dir/./gcc/collect-ld" "LIBCFLAGS=-g -O2" "NM=/var/tmp/gcc_build_dir/./gcc/nm" "PICFLAG=" "RANLIB=/usr/x86_64-pc-linux-gnu/bin/ranlib" "DESTDIR=" DO=all multi-do # make make[3]: Entering directory `/var/tmp/gcc_build_dir/x86_64-pc-linux-gnu/libcilkrts' true "AR_FLAGS=rc" "CC_FOR_BUILD=x86_64-pc-linux-gnu-gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "JC1FLAGS=" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr" "infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/info" "libdir=/usr/lib" "prefix=/usr" "includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include" "AR=/usr/x86_64-pc-linux-gnu/bin/ar" "AS=/var/tmp/gcc_build_dir/./gcc/as" "LD=/var/tmp/gcc_build_dir/./gcc/collect-ld" "LIBCFLAGS=-g -O2" "NM=/var/tmp/gcc_build_dir/./gcc/nm" "PICFLAG=" "RANLIB=/usr/x86_64-pc-linux-gnu/bin/ranlib" "DESTDIR=" DO=install multi-do # make test -z "/usr/lib/gcc/x86_64-pc-linux-gnu/" || /bin/mkdir -p "/usr/lib/gcc/x86_64-pc-linux-gnu/" /bin/sh ./libtool --mode=install /usr/bin/install -c libcilkrts.la '/usr/lib/gcc/x86_64-pc-linux-gnu/' libtool: install: error: cannot install `libcilkrts.la' to a directory not ending in /usr/lib/gcc/x86_64-pc-linux-gnu/
[Bug other/58925] --enable-version-specific-runtime-libs breaks libcilk install
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925 octoploid at yandex dot com changed: What|Removed |Added CC||bviyer at gmail dot com Summary|libtool: install: error:|--enable-version-specific-r |cannot install |untime-libs breaks libcilk |`libcilkrts.la' to a|install |directory not ending in | |/usr/lib/gcc/x86_64-pc-linu | |x-gnu/ | --- Comment #1 from octoploid at yandex dot com --- $ ../gcc/configure --enable-version-specific-runtime-libs --disable-bootstrap --disable-werror --disable-multilib --enable-languages=c,c++ is enough to reproduce the issue.
[Bug c++/58868] [4.9 Regression] ICE: in count_type_elements, at expr.c:5495 with -std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868 octoploid at yandex dot com changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #5 from octoploid at yandex dot com --- This bug is breaking almost every non-trivial C++ project. It should be P1 IMO.
[Bug other/58944] New: [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Bug ID: 58944
Summary: [4.9 Regression] bogus -Wunused-macros warnings when
compiling Libreoffice
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 tmp % cat test.ii
#pragma GCC push_options
#pragma GCC target("xsaveopt")
void fn1(void) {}
#pragma GCC pop_options
markus@x4 tmp % gcc -Wunused-macros -march=native -c test.ii
test.ii:4:9: warning: macro "__code_model_small__" is not used
[-Wunused-macros]
#pragma GCC pop_options
^
test.ii:4:9: warning: macro "__XSAVE__" is not used [-Wunused-macros]
test.ii:4:9: warning: macro "__XSAVEOPT__" is not used [-Wunused-macros]
test.ii:4:24: warning: macro "__amdfam10__" is not used [-Wunused-macros]
#pragma GCC pop_options
^
test.ii:4:24: warning: macro "__amdfam10" is not used [-Wunused-macros]
test.ii:4:24: warning: macro "__code_model_small__" is not used
[-Wunused-macros]
test.ii:4:24: warning: macro "__tune_amdfam10__" is not used [-Wunused-macros]
markus@x4 tmp %
The "__tune_amdfam10__" and "__amdfam10" (and maybe "__code_model_small__")
warnings look bogus.
I've noticed this issue while compiling Libreoffice.
[Bug other/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 octoploid at yandex dot com changed: What|Removed |Added CC||tmsriram at gcc dot gnu.org --- Comment #1 from octoploid at yandex dot com --- Started with r203634.
[Bug tree-optimization/58946] New: [4.9 Regression] internal compiler error: in operator[], at vec.h:722
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946
Bug ID: 58946
Summary: [4.9 Regression] internal compiler error: in
operator[], at vec.h:722
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
Building dev-util/kdevplatform-1.5.2 ICEs.
markus@x4 tmp % cat test.ii
class A {
public:
A(int p1) : m_index(p1) {
if (!p1)
m_index = DummyMask;
}
enum {
DummyMask = 1 << 31
};
unsigned m_fn1() const {
int a;
a = m_index & DummyMask;
if (a)
return 0;
return m_index;
}
unsigned m_index;
};
class B {
public:
int contains___trans_tmp_4;
void m_fn1(int &p1) {
const A &b = p1;
contains___trans_tmp_4 = b.m_fn1();
}
};
void fn1(A p1, B &p2) {
int c;
c = p1.m_fn1();
p2.m_fn1(c);
}
markus@x4 tmp % g++ -c -O2 test.ii
test.ii: In function ‘void fn1(A, B&)’:
test.ii:28:6: internal compiler error: in operator[], at vec.h:722
void fn1(A p1, B &p2) {
^
0xc819a7 vec::operator[](unsigned int)
../../gcc/gcc/vec.h:722
0xc84207 vec::operator[](unsigned int)
../../gcc/gcc/tree.h:2806
0xc84207 vec::operator[](unsigned int)
../../gcc/gcc/vec.h:1152
0xc84207 update_ops
../../gcc/gcc/tree-ssa-reassoc.c:2619
0xc8c1fa maybe_optimize_range_tests
../../gcc/gcc/tree-ssa-reassoc.c:2907
0xc8c1fa reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:4325
0xc8b927 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:4482
0xc8b927 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:4482
0xc8e2db do_reassoc
../../gcc/gcc/tree-ssa-reassoc.c:4515
0xc8e2db execute_reassoc
../../gcc/gcc/tree-ssa-reassoc.c:4597
0xc8e2db execute
../../gcc/gcc/tree-ssa-reassoc.c:4639
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
Looks related to PR58911.
[Bug tree-optimization/58946] [4.9 Regression] internal compiler error: in operator[], at vec.h:722
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946 octoploid at yandex dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #1 from octoploid at yandex dot com --- Started with r204194.
[Bug bootstrap/58925] --enable-version-specific-runtime-libs breaks libcilk install
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925 --- Comment #4 from octoploid at yandex dot com --- The following patch fixes the issue for me: diff --git a/libcilkrts/Makefile.am b/libcilkrts/Makefile.am index f332cfb13de6..40a19787fda7 100644 --- a/libcilkrts/Makefile.am +++ b/libcilkrts/Makefile.am @@ -47,6 +47,8 @@ AM_CFLAGS = $(GENERAL_FLAGS) -std=c99 AM_CPPFLAGS = $(GENERAL_FLAGS) AM_LDFLAGS = -lpthread -ldl +gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) + # Target list. toolexeclib_LTLIBRARIES = libcilkrts.la diff --git a/libcilkrts/Makefile.in b/libcilkrts/Makefile.in index 35e270518211..47ea956ee457 100644 --- a/libcilkrts/Makefile.in +++ b/libcilkrts/Makefile.in @@ -346,6 +346,8 @@ AM_CFLAGS = $(GENERAL_FLAGS) -std=c99 AM_CPPFLAGS = $(GENERAL_FLAGS) AM_LDFLAGS = -lpthread -ldl +gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) + # Target list. toolexeclib_LTLIBRARIES = libcilkrts.la libcilkrts_la_SOURCES = \
[Bug bootstrap/58925] --enable-version-specific-runtime-libs breaks libcilk install
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925 --- Comment #6 from octoploid at yandex dot com --- (In reply to Balaji V. Iyer from comment #5) > Hi, >I just submitted a patch to the gcc-patches mailing list. Can you try > that out? Our mails just crossed and I think your patch is fine. Will try it out tomorrow.
[Bug bootstrap/58925] --enable-version-specific-runtime-libs breaks libcilk install
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58925
octoploid at yandex dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from octoploid at yandex dot com ---
Fixed. Thanks.
BTW fib_serial() in testsuite/c-c++-common/cilk-plus/CK/fib.c is obviously
wrong:
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
b/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
index 6612936a05c0..b4aac491bf86 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
@@ -40,8 +40,8 @@ int fib_serial (int n)
return n;
else
{
- x = fib (n-1);
- y = fib (n-2);
+ x = fib_serial (n-1);
+ y = fib_serial (n-2);
return (x+y);
}
}
I've measured the serial vs. the cilk+ performance and it looks quite sad:
fib_serial:
...
fib (40) = 102334155
./a.out 1.82s user 0.00s system 99% cpu 1.822 total
fib with cilk+:
( % gcc -O3 -g -DHAVE_IO=1 -lcilkrts -ldl -fcilkplus fib.c)
...
fib (40) = 102334155
./a.out 29.14s user 0.06s system 392% cpu 7.432 total
[Bug tree-optimization/58978] New: [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Bug ID: 58978
Summary: [4.9 Regression] ICE: Segmentation fault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 tmp % cat test.ii
class A {
public:
int m_fn1();
};
class B {
public:
static B *m_fn1(int);
enum {
d = 8,
Sub,
Mul,
UDiv,
SDiv,
URem,
SRem,
Shl,
LShr
};
};
class C {
A Lex;
void m_fn1();
};
void C::m_fn1() {
switch (0)
case 0: {
int a = Lex.m_fn1();
switch (a) {
case 1:
case B::Sub:
case B::Mul:
case B::UDiv:
case B::SDiv:
case B::URem:
case B::SRem:
case B::Shl:
case 0:
case B::LShr:
break;
default:
__builtin_unreachable();
}
B::m_fn1(a);
}
}
markus@x4 tmp % g++ -O2 -c test.ii
test.ii: In member function ‘void C::m_fn1()’:
test.ii:24:6: internal compiler error: Segmentation fault
void C::m_fn1() {
^
0xb15d0f crash_signal
../../gcc/gcc/toplev.c:334
0xd2a30f single_imm_use
../../gcc/gcc/ssa-iterators.h:426
0xd2a30f all_imm_uses_in_stmt_or_feed_cond
../../gcc/gcc/tree-vrp.c:6480
0xd2a30f remove_range_assertions
../../gcc/gcc/tree-vrp.c:6622
0xd2a30f execute_vrp
../../gcc/gcc/tree-vrp.c:9759
0xd2a30f execute
../../gcc/gcc/tree-vrp.c:9842
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.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 octoploid at yandex dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from octoploid at yandex dot com --- Started with r204255.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 --- Comment #9 from octoploid at yandex dot com --- With your patch applied I get this new ICE: /home/markus/mozilla-central/js/src/jit/IonBuilder.cpp:6937:1: internal compiler error: Segmentation fault IonBuilder::jsop_getelem_typed(MDefinition *obj, MDefinition *index, ^ 0xb15d0f crash_signal ../../gcc/gcc/toplev.c:334 0xd2a30f single_imm_use ../../gcc/gcc/ssa-iterators.h:426 0xd2a30f all_imm_uses_in_stmt_or_feed_cond ../../gcc/gcc/tree-vrp.c:6480 0xd2a30f remove_range_assertions ../../gcc/gcc/tree-vrp.c:6622 0xd2a30f execute_vrp ../../gcc/gcc/tree-vrp.c:9759 0xd2a30f execute ../../gcc/gcc/tree-vrp.c:9842 Please submit a full bug report I'm currently reducing this testcase.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 --- Comment #10 from octoploid at yandex dot com --- (In reply to octoploid from comment #9) > With your patch applied I get this new ICE: > I've posted the wrong backtrace. Here's the correct one: /var/tmp/gcc_test/usr/local/bin/g++ -w -c -std=gnu++0x -O2 test.ii /home/markus/mozilla-central/js/src/jit/IonBuilder.cpp: In member function ‘bool js::jit::IonBuilder::jsop_getelem_typed(js::jit::MDefinition*, js::jit::MDefinition*, js::Sca larTypeRepresentation::Type)’: /home/markus/mozilla-central/js/src/jit/IonBuilder.cpp:6937:1: internal compiler error: tree check: expected ssa_name, have component_ref in single_imm_use, at ssa-iterators. h:419 IonBuilder::jsop_getelem_typed(MDefinition *obj, MDefinition *index, ^ 0xd21764 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9421 0xd1fc95 tree_check ../../gcc/gcc/tree.h:2902 0xd1fc95 single_imm_use ../../gcc/gcc/ssa-iterators.h:419 0xd1fc95 all_imm_uses_in_stmt_or_feed_cond ../../gcc/gcc/tree-vrp.c:6480 0xd1fc95 remove_range_assertions ../../gcc/gcc/tree-vrp.c:6622 0xd1fc95 execute_vrp ../../gcc/gcc/tree-vrp.c:9759 0xd1fc95 execute ../../gcc/gcc/tree-vrp.c:9842 Please submit a full bug report,
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 --- Comment #12 from octoploid at yandex dot com --- (In reply to Jakub Jelinek from comment #11) > Created attachment 31153 [details] > gcc49-pr58978.patch > > Supposedly this updated patch would fix even that? Yes. Thanks.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 octoploid at yandex dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from octoploid at yandex dot com --- Closing.
[Bug gcov-profile/59003] New: [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003
Bug ID: 59003
Summary: [4.9 Regression] profiledbootstrap miscompiles gcc
during stagefeedback
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
% ../gcc/configure --enable-checking=release --disable-werror
--disable-multilib --enable-languages=c,c++
% make -j4 BOOT_CFLAGS="-march=native -O3 -pipe" STAGE1_CFLAGS="-march=native
-O3 -pipe" CFLAGS_FOR_TARGET="-march=native -O3 -pipe"
CXXFLAGS_FOR_TARGET="-march=native -O3 -pipe" profiledbootstrap
...
/var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-march=native -O3 -pipe -O2
-march=native -O3 -pipe -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid128_noncomp.o -MT
bid128_noncomp.o -MD -MP -MF bid128_noncomp.dep -c
../../../gcc/libgcc/config/libbid/bid128_noncomp.c
/var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-march=native -O3 -pipe -O2
-march=native -O3 -pipe -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid128_fma.o -MT
bid128_fma.o -MD -MP -MF bid128_fma.dep -c
../../../gcc/libgcc/config/libbid/bid128_fma.c
In file included from ../../../gcc/libgcc/config/libbid/bid_internal.h:27:0,
from ../../../gcc/libgcc/config/libbid/bid64_noncomp.c:24:
../../../gcc/libgcc/config/libbid/bid64_noncomp.c: In function ‘__bid64_isInf’:
../../../gcc/libgcc/config/libbid/bid_conf.h:258:21: internal compiler error:
Segmentation fault
#define bid64_isInf __bid64_isInf
^
../../../gcc/libgcc/config/libbid/bid64_noncomp.c:220:1: note: in expansion of
macro ‘bid64_isInf’
bid64_isInf (UINT64 x _EXC_MASKS_PARAM _EXC_INFO_PARAM) {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [bid64_noncomp.o] Error 1
Looks like gcc got miscompiled during stagefeedback.
-march=native is amdfam10 on my machine.
Without --enable-checking=release gcc builds fine.
[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712 --- Comment #7 from octoploid at yandex dot com --- (In reply to Richard Biener from comment #6) > Any issues remaining? Yes. The second one.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #6 from octoploid at yandex dot com --- Program received signal SIGFPE, Arithmetic exception. [Switching to process 21235] 0x0052531d in want_inline_self_recursive_call_p (edge=0x774412d8, outer_node=0x77442260, peeling=, depth=1) at ../../gcc/gcc/ipa-inline.c:702 702 && (edge->frequency * CGRAPH_FREQ_BASE / caller_freq (gdb) bt #0 0x0052531d in want_inline_self_recursive_call_p (edge=0x774412d8, outer_node=0x77442260, peeling=, depth=1) at ../../gcc/gcc/ipa-inline.c:702 #1 0x00fca3bb in inline_small_functions () at ../../gcc/gcc/ipa-inline.c:1761 #2 ipa_inline () at ../../gcc/gcc/ipa-inline.c:2015 #3 (anonymous namespace)::pass_ipa_inline::execute (this=0x774412d8) at ../../gcc/gcc/ipa-inline.c:2385 #4 0x00a6ad8a in execute_one_pass (pass=pass@entry=0x16c5520) at ../../gcc/gcc/passes.c:2215 #5 0x00a6b61b in execute_ipa_pass_list (pass=0x16c5520) at ../../gcc/gcc/passes.c:2579 #6 0x0080e287 in ipa_passes () at ../../gcc/gcc/cgraphunit.c:2028 #7 compile () at ../../gcc/gcc/cgraphunit.c:2118 #8 0x0080ea95 in finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:2272 #9 0x0061175f in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:4403 #10 0x00b152dd in compile_file () at ../../gcc/gcc/toplev.c:559 #11 0x00b17188 in do_compile () at ../../gcc/gcc/toplev.c:1894 #12 toplev_main (argc=13, argv=0x7fffe308) at ../../gcc/gcc/toplev.c:1970 #13 0x775fba6e in __libc_start_main () from /lib/libc.so.6 #14 0x00527081 in _start () (gdb) p caller_freq $1 = 0 (gdb) p outer_node->global.inlined_to $2 = (cgraph_node *) 0x773ff980 (gdb) p outer_node->callers->frequency $3 = 0
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 octoploid at yandex dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #2 from octoploid at yandex dot com --- Hmm, not for me unfortunately: markus@x4 lto % cd /var/tmp/gcc/gcc/testsuite/g++.dg/lto markus@x4 lto % g++ -fPIC -flto -flto-partition=1to1 -r -nostdlib 20090302_0.C 20090302_1.C lto1: internal compiler error: in operator[], at vec.h:722 0x52bd87 vec::operator[](unsigned int) ../../gcc/gcc/vec.h:722 0x52c77c vec::operator[](unsigned int) ../../gcc/gcc/lto/lto-partition.c:235 0x52c77c inline_summary ../../gcc/gcc/ipa-inline.h:242 0x52c77c add_symbol_to_partition_1 ../../gcc/gcc/lto/lto-partition.c:207 0x52c62b add_symbol_to_partition_1 ../../gcc/gcc/lto/lto-partition.c:227 0x52c9cb lto_1_to_1_map() ../../gcc/gcc/lto/lto-partition.c:358 0x528856 do_whole_program_analysis ../../gcc/gcc/lto/lto.c:3120 0x528856 lto_main() ../../gcc/gcc/lto/lto.c:3264 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. lto-wrapper: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status markus@x4 lto % g++ -fPIC -flto -r -nostdlib 20081118_0.C 20081118_1.C lto1: internal compiler error: in operator[], at vec.h:722 0x52bd87 vec::operator[](unsigned int) ../../gcc/gcc/vec.h:722 0x52d7e8 vec::operator[](unsigned int) ../../gcc/gcc/lto/lto-partition.c:570 0x52d7e8 inline_summary ../../gcc/gcc/ipa-inline.h:242 0x52d7e8 lto_balanced_map() ../../gcc/gcc/lto/lto-partition.c:475 0x52884c do_whole_program_analysis ../../gcc/gcc/lto/lto.c:3124 0x52884c lto_main() ../../gcc/gcc/lto/lto.c:3264 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. lto-wrapper: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 octoploid at yandex dot com changed: What|Removed |Added Attachment #30920|0 |1 is obsolete|| --- Comment #7 from octoploid at yandex dot com --- Created attachment 31162 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31162&action=edit reduced testcase Here's a better reduced testcase. The first one was crappy.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #8 from octoploid at yandex dot com ---
The following patch seems to fix the issue:
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index f4cb72a9c2b0..b69d4d96176a 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -698,7 +698,7 @@ want_inline_self_recursive_call_p (struct cgraph_edge
*edge,
reason = "profile of recursive call is too large";
want_inline = false;
}
- if (!max_count
+ if (!max_count && caller_freq
&& (edge->frequency * CGRAPH_FREQ_BASE / caller_freq
>= max_prob))
{
@@ -731,7 +731,7 @@ want_inline_self_recursive_call_p (struct cgraph_edge
*edge,
reason = "profile of recursive call is too small";
want_inline = false;
}
- else if (!max_count
+ else if (!max_count && caller_freq
&& (edge->frequency * 100 / caller_freq
<= PARAM_VALUE (PARAM_MIN_INLINE_RECURSIVE_PROBABILITY)))
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 --- Comment #3 from octoploid at yandex dot com --- The issue only happens when I use the 'gold' linker, ld.bfd is fine. So maybe a binutils bug? Honza?
[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040 octoploid at yandex dot com changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #5 from octoploid at yandex dot com --- (In reply to H.J. Lu from comment #2) > (In reply to Igor Zamyatin from comment #1) > > Dup of 58853 > > There is no PR58853. Looks like a bugzilla bug. (PR58853 links to PR588...) When I search for 58853 on gcc.gnu.org/bugzilla it expands to http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=588%E2%80%8B53&list_id=74236 instead of http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=58853 (Where is that strange %E2%80%8B coming from?)
[Bug target/59040] [4.9 Regression] r203937 caused: FAIL: gcc.dg/torture/memcpy-1.c -O0 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59040 --- Comment #6 from octoploid at yandex dot com --- (In reply to octoploid from comment #5) > (In reply to H.J. Lu from comment #2) > > (In reply to Igor Zamyatin from comment #1) > > > Dup of 58853 > > > > There is no PR58853. > > Looks like a bugzilla bug. (PR58853 links to PR588...) > When I search for 58853 on gcc.gnu.org/bugzilla it expands to > http://gcc.gnu.org/bugzilla/buglist. > cgi?quicksearch=588%E2%80%8B53&list_id=74236 > instead of > http://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=58853 > (Where is that strange %E2%80%8B coming from?) No it's a copy and paste error, because the number from Comment1 is messed up. When I paste it into vim I get: 588<200b>53
[Bug tree-optimization/59050] New: [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
Bug ID: 59050
Summary: [4.9 Regression] ICE: tree check: expected
integer_cst, have nop_expr in tree_int_cst_lt, at
tree.c:7083
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 tsan % cat test.ii
struct {
int trace[6];
} a;
void fn1() {
for (int i; i; i++) {
a.trace[i] = a.trace[-i];
a.trace[-i] = 0;
}
}
markus@x4 tsan % /var/tmp/gcc_build_dir/./gcc/xgcc
-B/var/tmp/gcc_build_dir/./gcc -O3 test.ii
test.ii:3:3: warning: anonymous type with no linkage used to declare variable
‘ a’ with linkage [enabled by default]
} a;
^
test.ii: In function ‘void fn1()’:
test.ii:4:6: internal compiler error: tree check: expected integer_cst, have
nop_expr in tree_int_cst_lt, at tree.c:7083
void fn1() {
^
0xd1c3f4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9477
0xd1e354 tree_check
../../gcc/gcc/tree.h:2914
0xd1e354 tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/gcc/tree.c:7083
0xd1e390 tree_int_cst_compare(tree_node const*, tree_node const*)
../../gcc/gcc/tree.c:7093
0x100228c comp_dr_addr_with_seg_len_pair
../../gcc/gcc/tree-vect-data-refs.c:2672
0x100af25 vec::qsort(int
(*)(void const*, void const*))
../../gcc/gcc/vec.h:941
0x100af25 vec::qsort(int (*)(void
const*, void const*))
../../gcc/gcc/vec.h:1620
0x100af25 vect_prune_runtime_alias_test_list(_loop_vec_info*)
../../gcc/gcc/tree-vect-data-refs.c:2845
0xce76f2 vect_analyze_loop_2
../../gcc/gcc/tree-vect-loop.c:1716
0xce76f2 vect_analyze_loop(loop*)
../../gcc/gcc/tree-vect-loop.c:1807
0xcfdaff vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:360
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.
[Bug tree-optimization/59050] [4.9 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:7083
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050 octoploid at yandex dot com changed: What|Removed |Added CC||congh at google dot com --- Comment #1 from octoploid at yandex dot com --- Started with r204538.
[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712 octoploid at yandex dot com changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #8 from octoploid at yandex dot com --- Too summarize. There are three different issues right now. Issue 2) from above is still unfixed. Plus two new issues. 1) (This is issue 2 from above) ==23547== Use of uninitialised value of size 8 ==23547==at 0x886D95: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==23547==by 0x886E14: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==23547==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==23547==by 0x6BBECF: compile() (cgraphunit.c:1993) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7EE8B0: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:289) ==23547== ==23547== Conditional jump or move depends on uninitialised value(s) ==23547==at 0x886D9C: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==23547==by 0x886E14: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==23547==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==23547==by 0x6BBECF: compile() (cgraphunit.c:1993) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7EE8B0: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:289) ==23547== ==23547== Use of uninitialised value of size 8 ==23547==at 0x886E27: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:150) ==23547==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==23547==by 0x6BBECF: compile() (cgraphunit.c:1993) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7EE8B0: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:289) ==23547== ==23547== Use of uninitialised value of size 8 ==23547==at 0x886D95: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==23547==by 0x886DCD: pointer_set_contains(pointer_set_t const*, void const*) (pointer-set.c:116) ==23547==by 0x7D1356: (anonymous namespace)::pass_ipa_devirt::execute() (ipa-devirt.c:1027) ==23547==by 0x87DD29: execute_one_pass(opt_pass*) (passes.c:2215) ==23547==by 0x87E56A: execute_ipa_pass_list(opt_pass*) (passes.c:2579) ==23547==by 0x6BC003: compile() (cgraphunit.c:2028) ==23547==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==23547==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==23547==by 0x91709C: compile_file() (toplev.c:559) ==23547==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==23547==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==23547== Uninitialised value was created by a stack allocation ==23547==at 0x7D1050: (anonymous namespace)::pass_ipa_devirt::execute() (ipa-devirt.c:1182) ==26207== Use of uninitialised value of size 8 ==26207==at 0x886D95: pointer_set_lookup(pointer_set_t const*, void const*, unsigned long*) (pointer-set.c:90) ==26207==by 0x886E14: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:147) ==26207==by 0x7EEDB4: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:175) ==26207==by 0x6BBD0C: compile() (cgraphunit.c:2152) ==26207==by 0x6BC5B4: finalize_compilation_unit() (cgraphunit.c:2272) ==26207==by 0x57618D: cp_write_global_declarations() (decl2.c:4403) ==26207==by 0x91709C: compile_file() (toplev.c:559) ==26207==by 0x918B97: toplev_main(int, char**) (toplev.c:1891) ==26207==by 0x4ED5A6D: (below main) (in /lib64/libc-2.18.90.so) ==26207== Uninitialised value was created by a stack allocation ==26207==at 0x6BDEA5
[Bug c/59089] sin and/or cos produce bogus results with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59089 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #2 from Markus Trippelsdorf --- That is not a gcc issue, it's a glibc problem. There were a lot of improvements in that area in recent months. So I would recommend that you update your glibc to get better results.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #4 from Markus Trippelsdorf --- (In reply to Jeffrey A. Law from comment #2) > I need a compilable/complete testcase. > > If a program is faulting with -fisolate-erroneous-paths, then that program > is faulty in one way or another. It's dereferencing a null pointer, pass a > null argument in a situation where the argument must be non-null, or > returning a null pointer from a function declared as returning non-null. I'm seeing this also quite often. Xorg fails to start when compiled with current gcc, the Linux kernel doesn't build, because relocs (build during the kernel build) fails with illegal instruction, etc.. So tbe -fisolate-erroneous-paths patch should be reverted IMHO.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #6 from Markus Trippelsdorf --- (In reply to Jeffrey A. Law from comment #5) > I need testcases. "the kernel" or "x.org" isn't sufficient for a variety of > reasons. Every program that uses a custom sig_handler which only handles SIGSEGV will fail.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #7 from Markus Trippelsdorf ---
markus@x4 tmp % cat test.c
#include
#include
#include
#include
#include
static sigjmp_buf jmpbuf;
static void
sig_handler (int signo)
{
siglongjmp (jmpbuf, 1);
}
int
main (void)
{
char *p = NULL;
volatile int ret = 0;
struct sigaction sa;
sa.sa_handler = sig_handler;
sigemptyset (&sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
if (sigaction (SIGSEGV, &sa, 0))
{
perror ("installing SIGSEGV handler\n");
exit (1);
}
puts ("Attempting to sprintf to null ptr");
if (setjmp (jmpbuf))
{
puts ("Exiting main...");
return ret;
}
sprintf (p, "This should segv\n");
return 1;
}
markus@x4 tmp % gcc -O2 test.c && ./a.out
Attempting to sprintf to null ptr
[1]28519 illegal hardware instruction ./a.out
markus@x4 tmp % gcc -fno-isolate-erroneous-paths -O2 test.c && ./a.out
Attempting to sprintf to null ptr
Exiting main...
markus@x4 tmp %
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #9 from Markus Trippelsdorf --- (In reply to Jeffrey A. Law from comment #8) > Should be fixed via recent commits. Specifically, we preserve the *0 for > code that wants to catch the null pointer deref. Well, if you had run the simple glibc testcase that I've posted above, you would have found out that your recent commits don't fix this issue. It's obvious, not only from the amount of churn, that fisolate-erroneous-paths shouldn't be enabled by default at -O2. The very few users you would like SIGSEGV to be transformed to SIGILL by the compiler should set this option explicitly.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #13 from Markus Trippelsdorf --- (In reply to Jeffrey A. Law from comment #11) > Damn it. Tested the wrong compiler. > > The problem with your testcase Markus is you're simply not allowed to pass a > null pointer to sprintf, memcpy and a variety of other functions. Once you > execute code which attempts that, you've walked into the realm of undefined > behaviour. > > Once you cross that boundary the compiler is allowed to do these kinds of > transformations. Your testcode is fundamentally flawed in that it relies > upon undefined behaviour. Understood. But the problem is that "the kernel" and "x.org" still fail. I will try to come up with testcases for those two and see if it's also caused by the same undefined behavior.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #14 from Markus Trippelsdorf ---
The 'kernel' case passes a NULL pointer to qsort:
% < test.i
struct relocs {
int *offset;
};
static struct relocs a;
void qsort(void *, int) __attribute__((__nonnull__));
void die(int *p1, ...) {}
void sort_relocs(struct relocs *p1) { qsort(p1->offset, 0); }
int main() {
sort_relocs(&a);
return 0;
}
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #10 from Markus Trippelsdorf --- (In reply to David Binderman from comment #9) > (In reply to Markus Trippelsdorf from comment #8) > > The following patch seems to fix the issue: > > Looks good to me. > > I think it needs to get into the compiler source code somehow. > > Would posting the patch to gcc-patches be the correct way forward ? Yes, but I'd prefer not to. Because without commit rights you'll have to find someone to commit things for you. And the need to repeatedly ping even for trivial patches soon gets ridiculous.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #18 from Markus Trippelsdorf --- (In reply to Jeffrey A. Law from comment #17) > For the kernel case, note the qsort prototype and the non-null attribute. > That explicitly states that the pointer arguments must not be null. Any > code which then passes null for those arguments has stepped into the realm > of undefined behaviour. Yes, I've already posted a patch to the LKML to fix this issue. Now the question is if one could also find *real* bugs with the help of -fisolate-erroneous-path and if the inconvenience of breaking otherwise "harmless" programs is counterbalanced by this ability?
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #20 from Markus Trippelsdorf --- I've tested this further on my Gentoo box and it turned out the many nontrivial packages that I've compiled failed with "trap invalid opcode". From a QOI perspective this is a nightmare. Not every user of the compiler is a developer, e.g. as a Gentoo user I don't care deeply about most ebuilds, I just want them to compile without fuss. And for this I need a compiler that is as permissive as possible.
[Bug ipa/59201] New: [4.9 Regression] error: stmt (0x7f01c4708130) marked modified after optimization pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59201
Bug ID: 59201
Summary: [4.9 Regression] error: stmt (0x7f01c4708130) marked
modified after optimization pass
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
markus@x4 src % cat test.ii
class A {
public:
virtual void m_fn1();
};
class B final : A {
~B();
virtual void m_fn2() { m_fn1(); }
};
B::~B() {}
markus@x4 src % g++ -c -std=c++11 -O2 test.ii
test.ii: In member function ‘virtual void B::m_fn2()’:
test.ii:7:16: error: stmt (0x7f96e3a9e130) marked modified after optimization
pass:
virtual void m_fn2() { m_fn1(); }
^
# .MEM_6 = VDEF <.MEM_2(D)>
A::m_fn1 (_5);
test.ii:7:16: internal compiler error: verify_ssa failed
0xcc71df verify_ssa(bool)
../../gcc/gcc/tree-ssa.c:1092
0xa7fffc execute_function_todo
../../gcc/gcc/passes.c:1842
0xa80883 execute_todo
../../gcc/gcc/passes.c:1875
0xa826f1 execute_one_ipa_transform_pass
../../gcc/gcc/passes.c:2060
0xa826f1 execute_all_ipa_transforms()
../../gcc/gcc/passes.c:2091
0x822eb0 expand_function
../../gcc/gcc/cgraphunit.c:1753
0x824fe7 expand_all_functions
../../gcc/gcc/cgraphunit.c:1865
0x824fe7 compile()
../../gcc/gcc/cgraphunit.c:2199
0x825504 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2276
0x6217ae cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4408
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.
markus@x4 src %
[Bug ipa/59201] [4.9 Regression] error: stmt (0x7f01c4708130) marked modified after optimization pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59201 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- Started with r205019.
[Bug c++/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
--- Comment #2 from Markus Trippelsdorf ---
reduced test case:
class A {
public:
A();
A(int *);
};
class B {};
class C : B {
public:
virtual void m_fn1();
void operator+=(int) { m_fn1(); }
};
enum DebuggerType {};
C a;
DebuggerType b;
void operator==(A &, const A &);
static A get_dbx_doc(A &p1) { p1 == 0; }
void add_button() {
A c;
switch (b)
case 0:
get_dbx_doc(c);
a += 0;
}
[Bug ipa/59226] New: [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
Bug ID: 59226
Summary: [4.9 Regression] ICE: in record_target_from_binfo, at
ipa-devirt.c:661
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: octoploid at yandex dot com
More outfall from r205019:
markus@x4 tmp % cat test.ii
class A {
virtual void m_fn1();
};
class B;
class C : A {
public:
virtual B *m_fn2();
};
class D : virtual C, A {};
class B {
public:
int m_fn1();
};
class F : virtual public C {};
class G : F, D {
virtual void m_fn6();
};
F *a;
int b = a->m_fn2()->m_fn1();
G c;
markus@x4 tmp % g++ -c -O2 test.ii
test.ii:9:7: warning: direct base ‘A’ inaccessible in ‘D’ due to ambiguity
[enabled by default]
class D : virtual C, A {};
^
test.ii:20:4: internal compiler error: in record_target_from_binfo, at
ipa-devirt.c:661
G c;
^
0x9bad92 record_target_from_binfo
../../gcc/gcc/ipa-devirt.c:661
0x9bab0b record_target_from_binfo
../../gcc/gcc/ipa-devirt.c:681
0x9bab0b record_target_from_binfo
../../gcc/gcc/ipa-devirt.c:681
0x9baf30 possible_polymorphic_call_targets_1
../../gcc/gcc/ipa-devirt.c:705
0x9baf84 possible_polymorphic_call_targets_1
../../gcc/gcc/ipa-devirt.c:711
0x9bd7a2 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**)
../../gcc/gcc/ipa-devirt.c:1292
0x9e2145 possible_polymorphic_call_targets
../../gcc/gcc/ipa-utils.h:114
0x9e2145 walk_polymorphic_call_targets
../../gcc/gcc/ipa.c:175
0x9e2145 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
../../gcc/gcc/ipa.c:398
0xa8a9b7 execute_todo
../../gcc/gcc/passes.c:1884
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.
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 --- Comment #5 from Markus Trippelsdorf --- FYI I'm running the latest binutils trunk: GNU gold (GNU Binutils 2.24.51.20131121) 1.11 (I don't use -fuse-ld=gold normally, because one can easily switch linkers globally, e.g.: ln -f /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld.gold /usr/x86_64-pc-linux-gnu/binutils-bin/git/ld)
[Bug other/58712] [4.9 Regression] issues found by --enable-checking=valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712 --- Comment #10 from Markus Trippelsdorf --- New issue, started with r204926, r204997: ==21374== Conditional jump or move depends on uninitialised value(s) ==21374==at 0x686F3A: set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int, unsigned int, long, unsigned long, unsigned long, unsigned long) (expr.c:2998) ==21374==by 0x691B2D: clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned int, long, unsigned long, unsigned long, unsigned long) (expr.c:2812) ==21374==by 0x5B65EB: expand_builtin_memset_args(tree_node*, tree_node*, tree_node*, rtx_def*, machine_mode, tree_node*) (builtins.c:3760) ==21374==by 0x5C5711: expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) (builtins.c:6161) ==21374==by 0x689CC2: expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) (expr.c:10275) ==21374==by 0x5DB8A6: expand_gimple_stmt(gimple_statement_base*) (cfgexpand.c:2245) ==21374==by 0x5DC36C: expand_gimple_basic_block(basic_block_def*, bool) (cfgexpand.c:5135) ==21374==by 0x5DE4B6: (anonymous namespace)::pass_expand::execute() (cfgexpand.c:5701) ==21374==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==21374==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==21374==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763) ==21374==by 0x5FE477: compile() (cgraphunit.c:1868) ==21374== Uninitialised value was created by a stack allocation ==21374==at 0x5B66B9: expand_builtin_memset(tree_node*, rtx_def*, machine_mode) (builtins.c:3633) ==21374== ==21374== Conditional jump or move depends on uninitialised value(s) ==21374==at 0x6695B8: gen_rtx_CONST_INT(machine_mode, long) (emit-rtl.c:402) ==21374==by 0x686F4A: set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int, unsigned int, long, unsigned long, unsigned long, unsigned long) (optabs.h:485) ==21374==by 0x691B2D: clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned int, long, unsigned long, unsigned long, unsigned long) (expr.c:2812) ==21374==by 0x5B65EB: expand_builtin_memset_args(tree_node*, tree_node*, tree_node*, rtx_def*, machine_mode, tree_node*) (builtins.c:3760) ==21374==by 0x5C5711: expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) (builtins.c:6161) ==21374==by 0x689CC2: expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) (expr.c:10275) ==21374==by 0x5DB8A6: expand_gimple_stmt(gimple_statement_base*) (cfgexpand.c:2245) ==21374==by 0x5DC36C: expand_gimple_basic_block(basic_block_def*, bool) (cfgexpand.c:5135) ==21374==by 0x5DE4B6: (anonymous namespace)::pass_expand::execute() (cfgexpand.c:5701) ==21374==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==21374==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==21374==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763) ==21374== Uninitialised value was created by a stack allocation ==21374==at 0x5B66B9: expand_builtin_memset(tree_node*, rtx_def*, machine_mode) (builtins.c:3633) ==21374== ==21374== Use of uninitialised value of size 8 ==21374==at 0xD37236: htab_find_slot_with_hash (hashtab.c:655) ==21374==by 0x6695E5: gen_rtx_CONST_INT(machine_mode, long) (emit-rtl.c:412) ==21374==by 0x686F4A: set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int, unsigned int, long, unsigned long, unsigned long, unsigned long) (optabs.h:485) ==21374==by 0x691B2D: clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned int, long, unsigned long, unsigned long, unsigned long) (expr.c:2812) ==21374==by 0x5B65EB: expand_builtin_memset_args(tree_node*, tree_node*, tree_node*, rtx_def*, machine_mode, tree_node*) (builtins.c:3760) ==21374==by 0x5C5711: expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) (builtins.c:6161) ==21374==by 0x689CC2: expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) (expr.c:10275) ==21374==by 0x5DB8A6: expand_gimple_stmt(gimple_statement_base*) (cfgexpand.c:2245) ==21374==by 0x5DC36C: expand_gimple_basic_block(basic_block_def*, bool) (cfgexpand.c:5135) ==21374==by 0x5DE4B6: (anonymous namespace)::pass_expand::execute() (cfgexpand.c:5701) ==21374==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==21374==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==21374== Uninitialised value was created by a stack allocation ==21374==at 0x5B66B9: expand_builtin_memset(tree_node*, rtx_def*, machine_mode) (builtins.c:3633) ==21374== ==21374== Conditional jump or move depends on uninitialised value(s) ==21374==at 0xD370B8: htab_find_slot_with_hash (hashtab.c:660) ==21374==by 0x6695E5: gen_rtx_CONST_INT(machine_mode, long) (emit-rtl.c:412) ==21374==by 0x686F4A: set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int, unsigned i
[Bug preprocessor/58893] [4.8/4.9 Regression] :0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893 --- Comment #5 from Markus Trippelsdorf --- ==3700== Conditional jump or move depends on uninitialised value(s) ==3700==at 0xDCB562: diagnostic_report_current_module(diagnostic_context*, unsigned int) (diagnostic.c:506) ==3700==by 0x58DB6D: cp_diagnostic_starter(diagnostic_context*, diagnostic_info*) (error.c:3025) ==3700==by 0xDCC1E8: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:791) ==3700==by 0x6551D4: c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char const*, __va_list_tag (*) [1]) (c-common.c:9665) ==3700==by 0xDD9AB8: cpp_diagnostic(cpp_reader*, int, int, char const*, __va_list_tag (*) [1]) (errors.c:63) ==3700==by 0xDD9C06: cpp_error(cpp_reader*, int, char const*, ...) (errors.c:78) ==3700==by 0xDDF152: _cpp_find_file (files.c:571) ==3700==by 0xDDF71E: _cpp_stack_include (files.c:993) ==3700==by 0x6657D5: push_command_line_include() (c-opts.c:1372) ==3700==by 0xDE18E5: _cpp_get_fresh_line.part.6 (lex.c:2134) ==3700==by 0xDE3A58: _cpp_lex_direct (lex.c:2104) ==3700==by 0xDE490B: _cpp_lex_token (lex.c:2055) ==3700== Uninitialised value was created by a heap allocation ==3700==at 0x40274F0: malloc (vg_replace_malloc.c:291) ==3700==by 0xE0F557: xmalloc (xmalloc.c:147) ==3700==by 0xDE1DDA: _cpp_init_tokenrun (lex.c:1901) ==3700==by 0xDE0653: cpp_create_reader(c_lang, ht*, line_maps*) (init.c:236) ==3700==by 0x665C7C: c_common_init_options(unsigned int, cl_decoded_option*) (c-opts.c:215) ==3700==by 0x93E854: toplev_main(int, char**) (toplev.c:1947) ==3700==by 0x4ED5FD2: (below main) (in /lib64/libc-2.18.90.so) ==3700== ==3700== Conditional jump or move depends on uninitialised value(s) ==3700==at 0xDCF7FE: expand_location_1(unsigned int, bool) (input.c:55) ==3700==by 0xDCFA5A: expand_location_to_spelling_point(unsigned int) (input.c:162) ==3700==by 0xDCBC28: diagnostic_build_prefix(diagnostic_context*, diagnostic_info const*) (diagnostic.c:239) ==3700==by 0x58DC7F: cp_diagnostic_starter(diagnostic_context*, diagnostic_info*) (error.c:3030) ==3700==by 0xDCC1E8: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:791) ==3700==by 0x6551D4: c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char const*, __va_list_tag (*) [1]) (c-common.c:9665) ==3700==by 0xDD9AB8: cpp_diagnostic(cpp_reader*, int, int, char const*, __va_list_tag (*) [1]) (errors.c:63) ==3700==by 0xDD9C06: cpp_error(cpp_reader*, int, char const*, ...) (errors.c:78) ==3700==by 0xDDF152: _cpp_find_file (files.c:571) ==3700==by 0xDDF71E: _cpp_stack_include (files.c:993) ==3700==by 0x6657D5: push_command_line_include() (c-opts.c:1372) ==3700==by 0xDE18E5: _cpp_get_fresh_line.part.6 (lex.c:2134) ==3700== Uninitialised value was created by a heap allocation ==3700==at 0x40274F0: malloc (vg_replace_malloc.c:291) ==3700==by 0xE0F557: xmalloc (xmalloc.c:147) ==3700==by 0xDE1DDA: _cpp_init_tokenrun (lex.c:1901) ==3700==by 0xDE0653: cpp_create_reader(c_lang, ht*, line_maps*) (init.c:236) ==3700==by 0x665C7C: c_common_init_options(unsigned int, cl_decoded_option*) (c-opts.c:215) ==3700==by 0x93E854: toplev_main(int, char**) (toplev.c:1947) ==3700==by 0x4ED5FD2: (below main) (in /lib64/libc-2.18.90.so) ==3700== ==3700== Conditional jump or move depends on uninitialised value(s) ==3700==at 0xDCF841: expand_location_1(unsigned int, bool) (input.c:63) ==3700==by 0xDCFA5A: expand_location_to_spelling_point(unsigned int) (input.c:162) ==3700==by 0xDCBC28: diagnostic_build_prefix(diagnostic_context*, diagnostic_info const*) (diagnostic.c:239) ==3700==by 0x58DC7F: cp_diagnostic_starter(diagnostic_context*, diagnostic_info*) (error.c:3030) ==3700==by 0xDCC1E8: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:791) ==3700==by 0x6551D4: c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char const*, __va_list_tag (*) [1]) (c-common.c:9665) ==3700==by 0xDD9AB8: cpp_diagnostic(cpp_reader*, int, int, char const*, __va_list_tag (*) [1]) (errors.c:63) ==3700==by 0xDD9C06: cpp_error(cpp_reader*, int, char const*, ...) (errors.c:78) ==3700==by 0xDDF152: _cpp_find_file (files.c:571) ==3700==by 0xDDF71E: _cpp_stack_include (files.c:993) ==3700==by 0x6657D5: push_command_line_include() (c-opts.c:1372) ==3700==by 0xDE18E5: _cpp_get_fresh_line.part.6 (lex.c:2134) ==3700== Uninitialised value was created by a heap allocation ==3700==at 0x40274F0: malloc (vg_replace_malloc.c:291) ==3700==by 0xE0F557: xmalloc (xmalloc.c:147) ==3700==by 0xDE1DDA: _cpp_init_tokenrun (lex.c:1901) ==3700==by 0xDE0653: cpp_create_reader(c_lang, ht*, line_maps*) (init.c:236) ==3700==by 0x665C7C: c_common_init_options(unsigned int, cl_decoded_option*) (c-opts.c:215) ==3700==by 0x93E854: tople
[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 --- Comment #8 from Markus Trippelsdorf --- Ping. All supported gcc versions are affected. Can someone please have a look?
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 --- Comment #13 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #12) > Fixed. The testcase is missing.
[Bug c/59362] Abort in fini_object_sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf --- Valgrind shows: ==3073== Invalid write of size 8 ==3073==at 0x8C60BF: collect_object_sizes_for(object_size_info*, tree_node*) (tree-object-size.c:913) ==3073==by 0x8C6CA4: merge_object_sizes(object_size_info*, tree_node*, tree_node*, unsigned long) [clone .isra.26] (tree-object-size.c:745) ==3073==by 0x8C68BA: collect_object_sizes_for(object_size_info*, tree_node*) (tree-object-size.c:956) ==3073==by 0x8C5188: compute_builtin_object_size(tree_node*, int) (tree-object-size.c:539) ==3073==by 0x5BACA7: fold_builtin_2(unsigned int, tree_node*, tree_node*, tree_node*, bool) (builtins.c:12721) ==3073==by 0x5BBBAB: fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool) (builtins.c:8) ==3073==by 0x5C3F54: fold_call_stmt(gimple_statement_base*, bool) (builtins.c:14252) ==3073==by 0x8C43A6: (anonymous namespace)::pass_object_sizes::execute() (tree-object-size.c:1224) ==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269) ==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763) ==3073== Address 0x53a8bc8 is 0 bytes after a block of size 856 alloc'd ==3073==at 0x40274F0: malloc (vg_replace_malloc.c:291) ==3073==by 0xD38CC7: xmalloc (xmalloc.c:147) ==3073==by 0x8C4182: init_object_sizes() [clone .part.28] (tree-object-size.c:1183) ==3073==by 0x8C4B83: (anonymous namespace)::pass_object_sizes::execute() (ssa-iterators.h:498) ==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269) ==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763) ==3073==by 0x5FE477: compile() (cgraphunit.c:1868) ==3073==by 0x5FE7D4: finalize_compilation_unit() (cgraphunit.c:2280) ==3073==by 0x51E92B: c_write_global_declarations() (c-decl.c:10388) ==3073==by 0x866B7C: compile_file() (toplev.c:561) ==3073== ==3073== Invalid read of size 8 ==3073==at 0x8C6535: collect_object_sizes_for(object_size_info*, tree_node*) (tree-object-size.c:799) ==3073==by 0x8C6CA4: merge_object_sizes(object_size_info*, tree_node*, tree_node*, unsigned long) [clone .isra.26] (tree-object-size.c:745) ==3073==by 0x8C68BA: collect_object_sizes_for(object_size_info*, tree_node*) (tree-object-size.c:956) ==3073==by 0x8C5188: compute_builtin_object_size(tree_node*, int) (tree-object-size.c:539) ==3073==by 0x5BACA7: fold_builtin_2(unsigned int, tree_node*, tree_node*, tree_node*, bool) (builtins.c:12721) ==3073==by 0x5BBBAB: fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool) (builtins.c:8) ==3073==by 0x5C3F54: fold_call_stmt(gimple_statement_base*, bool) (builtins.c:14252) ==3073==by 0x8C43A6: (anonymous namespace)::pass_object_sizes::execute() (tree-object-size.c:1224) ==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269) ==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763) ==3073== Address 0x53a8bc8 is 0 bytes after a block of size 856 alloc'd ==3073==at 0x40274F0: malloc (vg_replace_malloc.c:291) ==3073==by 0xD38CC7: xmalloc (xmalloc.c:147) ==3073==by 0x8C4182: init_object_sizes() [clone .part.28] (tree-object-size.c:1183) ==3073==by 0x8C4B83: (anonymous namespace)::pass_object_sizes::execute() (ssa-iterators.h:498) ==3073==by 0x7CC189: execute_one_pass(opt_pass*) (passes.c:2215) ==3073==by 0x7CC3F5: execute_pass_list(opt_pass*) (passes.c:2268) ==3073==by 0x7CC407: execute_pass_list(opt_pass*) (passes.c:2269) ==3073==by 0x5FCB95: expand_function(cgraph_node*) (cgraphunit.c:1763) ==3073==by 0x5FE477: compile() (cgraphunit.c:1868) ==3073==by 0x5FE7D4: finalize_compilation_unit() (cgraphunit.c:2280) ==3073==by 0x51E92B: c_write_global_declarations() (c-decl.c:10388) ==3073==by 0x866B7C: compile_file() (toplev.c:561) ==3073== AddressSanitizer: markus@x4 tmp % /var/tmp/gcc_sani/usr/local/bin/gcc -c -O2 -std=gnu99 bug124.c = ==2994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6180001343d8 at pc 0x133f0e8 bp 0x7fffe70fc990 sp 0x7fffe70fc988 WRITE of size 8 at 0x6180001343d8 thread T0 #0 0x133f0e7 in collect_object_sizes_for(object_size_info*, tree_node*) /var/tmp/gcc_bui
[Bug c/59362] Abort in fini_object_sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59362
--- Comment #2 from Markus Trippelsdorf ---
Reduced:
markus@x4 tmp % cat test.i
char *a;
long int b;
void enc_format() {
b = __builtin_object_size(0, 0);
a = __builtin___stpcpy_chk(0, "", b);
b = __builtin_object_size(a, 0);
}
markus@x4 tmp % gcc -c -O2 test.i
*** Error in `/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1': free(): invalid
next size (fast): 0x029aaab0 ***
=== Backtrace: =
...
[Bug target/59363] New: [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 Bug ID: 59363 Summary: [4.9 Regression] r203886 miscompiles git Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: octoploid at yandex dot com Starting with r203886 git gets miscompiled on my machine. For example: % git blame gcc/tree-object-size.c Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0051240d in xdl_emit_hunk_hdr (s1=s1@entry=1291, c1=, s2=s2@entry=1291, c2=c2@entry=1, func=func@entry=0x7fffd2d8 "", funclen=0, ecb=ecb@entry=0x7fffd580) at xdiff/xutils.c:460 #2 0x00512af7 in xdl_emit_diff (xe=0x7fffd390, xscr=, ecb=0x7fffd580, xecfg=0x7fffd590) at xdiff/xemit.c:237 #3 0x00510a5d in xdl_diff (mf1=mf1@entry=0x7fffd510, mf2=mf2@entry=0x7fffd520, xpp=xpp@entry=0x7fffd570, xecfg=xecfg@entry=0x7fffd590, ecb=ecb@entry=0x7fffd580) at xdiff/xdiffi.c:601 #4 0x0050b005 in xdi_diff (mf1=, mf2=, xpp=xpp@entry=0x7fffd570, xecfg=xecfg@entry=0x7fffd590, xecb=xecb@entry=0x7fffd580) at xdiff-interface.c:136 #5 0x004104df in diff_hunks (file_a=, file_b=, ctxlen=ctxlen@entry=0, hunk_func=hunk_func@entry=0x411320 , cb_data=cb_data@entry=0x7fffd830) at builtin/blame.c:105 #6 0x00412b54 in pass_blame_to_parent (parent=0x144a7b0, target=0x125dcb0, sb=0x7fffd6e0) at builtin/blame.c:815 #7 pass_blame (opt=0, origin=0x125dcb0, sb=0x7fffd6e0) at builtin/blame.c:1281 #8 assign_blame (opt=, sb=0x7fffd6e0) at builtin/blame.c:1559 #9 cmd_blame (argc=, argv=, prefix=) at builtin/blame.c:2523 #10 0x004060b5 in run_builtin (argv=0x7fffe528, argc=2, p=0x578bd8 ) at git.c:314 #11 handle_internal_command (argc=2, argv=0x7fffe528) at git.c:478 #12 0x00405772 in main (argc=2, av=) at git.c:575 This only happens when I compile git with -march=native (=amdfam10 on this machine). I will try to come up with a testcase tomorrow.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #1 from Markus Trippelsdorf --- Created attachment 31346 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31346&action=edit preprocessed file Testcase.
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #2 from Markus Trippelsdorf ---
22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
22211 {
22212 xpparam_t xpp = {0};
22213 xdemitconf_t xecfg = {0};
22214 xdemitcb_t ecb = {((void *)0)};
22215
22216 xpp.flags = xdl_opts;
22217 xecfg.ctxlen = ctxlen;
22218 xecfg.hunk_func = hunk_func;
22219 ecb.priv = cb_data;
0 return xdi_diff(file_a, file_b, &xpp, &xecfg, &ecb);
1 }
2
"xdemitconf_t xecfg = {0};" is the problematic line.
If I leave the variable uninitialized the issue goes away.
The difference of:
cc -S -c -O2 -march=native blame.i
cc -S -c -O2 blame.i
@@ -256,38 +256,36 @@
.LCOLDB5:
.text
.LHOTB5:
- .p2align 5,,31
+ .p2align 4,,15
.type diff_hunks, @function
diff_hunks:
.LFB104:
.cfi_startproc
- subq$88, %rsp
- .cfi_def_cfa_offset 96
+ pushq %rbx
+ .cfi_def_cfa_offset 16
+ .cfi_offset 3, -16
+ movq%rdi, %r11
+ movq%rcx, %rbx
xorl%eax, %eax
-.L31:
- movl%eax, %r9d
- addl$32, %eax
- cmpl$32, %eax
- movq$0, 32(%rsp,%r9)
- movq$0, 40(%rsp,%r9)
- movq$0, 48(%rsp,%r9)
- movq$0, 56(%rsp,%r9)
- jb .L31
- leaq32(%rsp), %r10
- movq%rdx, 32(%rsp)
- movq%rcx, 72(%rsp)
- addq%r10, %rax
+ movl$6, %ecx
+ subq$80, %rsp
+ .cfi_def_cfa_offset 96
+ leaq32(%rsp), %rdi
movq%r8, 16(%rsp)
- movq%rsp, %rdx
- movq$0, (%rax)
- movq$0, 8(%rax)
leaq16(%rsp), %r8
- movslq xdl_opts(%rip), %rax
- movq%r10, %rcx
movq$0, 24(%rsp)
+ rep stosq
+ movslq xdl_opts(%rip), %rax
+ leaq32(%rsp), %rcx
+ movq%rdx, 32(%rsp)
+ movq%r11, %rdi
+ movq%rsp, %rdx
+ movq%rbx, 72(%rsp)
movq%rax, (%rsp)
callxdi_diff
- addq$88, %rsp
+ addq$80, %rsp
+ .cfi_def_cfa_offset 16
+ popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #4 from Markus Trippelsdorf --- git % cc -v -S -c -O2 -march=native blame.i Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/gcc Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-initfini-array --with-gold --enable-secureplt --disable-multilib --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-boot-ldflags=-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterations=3 --enable-version-specific-runtime-libs --disable-libstdcxx-pch --enable-libstdcxx-time=yes --with-build-config=bootstrap-lto Thread model: posix gcc version 4.9.0 20131129 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-S' '-c' '-O2' '-march=native' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1 -fpreprocessed blame.i -march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -msse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet -dumpbase blame.i -auxbase blame -O2 -version -o blame.s GNU C (GCC) version 4.9.0 20131129 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 4.9.0 20131129 (experimental), GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.0 20131129 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 4.9.0 20131129 (experimental), GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3b47e15390e8cb82192637cabb8398ab COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-S' '-c' '-O2' '-march=native'
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #2)
> 22209 static int diff_hunks(mmfile_t *file_a, mmfile_t *file_b, long ctxlen,
> 22210 xdl_emit_hunk_consume_func_t hunk_func, void *cb_data)
> 22211 {
> 22212 xpparam_t xpp = {0};
> 22213 xdemitconf_t xecfg = {0};
> 22214 xdemitcb_t ecb = {((void *)0)};
> 22215
> 22216 xpp.flags = xdl_opts;
> 22217 xecfg.ctxlen = ctxlen;
> 22218 xecfg.hunk_func = hunk_func;
> 22219 ecb.priv = cb_data;
> 0 return xdi_diff(file_a, file_b, &xpp, &xecfg, &ecb);
> 1 }
> 2
The problem seems to be that xecfg.hunk_func is empty even though
hunk_func is not.
So the assignment might get overwritten by the initialization.
...
(gdb) up
#5 0x004104df in diff_hunks (file_a=, file_b=, ctxlen=ctxlen@entry=0, hunk_func=hunk_func@entry=0x411320
,
cb_data=cb_data@entry=0x7fffd830) at builtin/blame.c:105
105 return xdi_diff(file_a, file_b, &xpp, &xecfg, &ecb);
(gdb) l
100
101 xpp.flags = xdl_opts;
102 xecfg.ctxlen = ctxlen;
103 xecfg.hunk_func = hunk_func;
104 ecb.priv = cb_data;
105 return xdi_diff(file_a, file_b, &xpp, &xecfg, &ecb);
106 }
107
108 /*
109 * Prepare diff_filespec and convert it using diff textconv API
(gdb) p hunk_func
$1 = (xdl_emit_hunk_consume_func_t) 0x411320
(gdb) p xecfg.hunk_func
$2 = (xdl_emit_hunk_consume_func_t) 0x0
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #7 from Markus Trippelsdorf --- Antoine Pelisse explained the control flow: http://thread.gmane.org/gmane.comp.version-control.git/238629/focus=238631
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #8 from Markus Trippelsdorf --- To reproduce the issue: % git clone https://github.com/git/git % cd git % vim Makefile (add "-march=amdfam10" to CFLAGS and point CC to gcc trunk) % make % ./git-blame Makefile (crash)
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363
--- Comment #14 from Markus Trippelsdorf ---
Further reduced:
markus@x4 tmp % cat test.i
typedef struct {
int ctxlen;
long interhunkctxlen;
int flags;
long find_func;
void *find_func_priv;
int hunk_func;
} xdemitconf_t;
__attribute__((noinline))
int xdi_diff(xdemitconf_t *xecfg) {
if (xecfg->hunk_func == 0)
__builtin_abort();
return 0;
}
int main() {
xdemitconf_t xecfg = {0};
xecfg.hunk_func = 1;
return xdi_diff(&xecfg);
}
markus@x4 tmp % gcc -O2 -mtune=amdfam10 test.i && ./a.out
[1]2079 abort ./a.out
markus@x4 tmp % gcc -O2 test.i && ./a.out
markus@x4 tmp %
[Bug target/59363] [4.9 Regression] r203886 miscompiles git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #17 from Markus Trippelsdorf --- (In reply to H.J. Lu from comment #15) > It may be a latent bug in amdfam10 scheduler. Before z.i.234r.sched2. > there are BTW -mtune=opteron is also affected.
[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Markus Trippelsdorf --- Fixed. Thanks.
[Bug gcov-profile/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 Markus Trippelsdorf changed: What|Removed |Added Summary|[4.9 Regression]|[4.9 Regression] |profiledbootstrap |profiledbootstrap |miscompiles gcc during |miscompiles gcc during |stagefeedback |stagefeedback ||--with-tune=amdfam10 --- Comment #1 from Markus Trippelsdorf --- The following is enough to reproduce the issue: % ../gcc/configure --with-tune=amdfam10 --enable-checking=release --disable-werror --disable-multilib --enable-languages=c,c++ --with-build-config="bootstrap-lto bootstrap-O3" % make profiledbootstrap Maybe it is another target problem?
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 Markus Trippelsdorf changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-* CC||hubicka at ucw dot cz Component|gcov-profile|target --- Comment #2 from Markus Trippelsdorf --- Started with r203937.
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #3 from Markus Trippelsdorf --- Switching off misaligned_move_string_pro_epilogues for AMD "fixes" the issue: diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def index 4c13c3a0ec69..af58b3e1f77e 100644 --- a/gcc/config/i386/x86-tune.def +++ b/gcc/config/i386/x86-tune.def @@ -264,7 +264,7 @@ DEF_TUNE (X86_TUNE_SINGLE_STRINGOP, "single_stringop", m_386 | m_P4_NOCONA) FIXME: This may actualy be a win on more targets than listed here. */ DEF_TUNE (X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES, "misaligned_move_string_pro_epilogues", - m_386 | m_486 | m_CORE_ALL | m_AMD_MULTIPLE | m_GENERIC) + m_386 | m_486 | m_CORE_ALL | m_GENERIC) /* X86_TUNE_USE_SAHF: Controls use of SAHF. */ DEF_TUNE (X86_TUNE_USE_SAHF, "use_sa
[Bug target/59379] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf --- Maybe a dup of Bug59003?
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #5 from Markus Trippelsdorf --- Looks like gcc/tree-ssa-pre.c gets miscompiled: Program received signal SIGSEGV, Segmentation fault. [Switching to process 8327] 0x00d156d3 in get_or_alloc_expr_for_name(tree_node*) [clone .lto_priv.4065] () (gdb) bt #0 0x00d156d3 in get_or_alloc_expr_for_name(tree_node*) [clone .lto_priv.4065] () #1 0x00f47468 in compute_avail() () #2 0x011068cf in (anonymous namespace)::pass_pre::execute() [clone .lto_priv.5361] () #3 0x00c8f3a2 in execute_one_pass(opt_pass*) () #4 0x00c9065b in execute_pass_list(opt_pass*) () #5 0x00e405f5 in expand_function(cgraph_node*) [clone .lto_priv.5292] () #6 0x010ed32b in compile() () #7 0x010ed8da in finalize_compilation_unit() () #8 0x00ffe208 in c_write_global_declarations() () #9 0x010b0c5f in compile_file() () #10 0x010b2d14 in toplev_main(int, char**) () #11 0x77756f90 in __libc_start_main () from /lib/libc.so.6 #12 0x0104d236 in _start () Is it possible to somehow disassemble slim object files?
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #6 from Markus Trippelsdorf --- Created attachment 31377 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31377&action=edit disassemled get_or_alloc_expr_for_name(tree_node*) good
[Bug target/59003] [4.9 Regression] profiledbootstrap miscompiles gcc during stagefeedback --with-tune=amdfam10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59003 --- Comment #7 from Markus Trippelsdorf --- Created attachment 31378 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31378&action=edit disassemled get_or_alloc_expr_for_name(tree_node*) bad I've attached the disassembly of get_or_alloc_expr_for_name() Good: misaligned_move_string_pro_epilogues off Bad: misaligned_move_string_pro_epilogues on
[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 --- Comment #8 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #7) > So, with r205392 now in, can this still be reproduced? Unfortunately, yes.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #12 from Markus Trippelsdorf ---
(In reply to Jakub Jelinek from comment #11)
> Can't reproduce this, with various snapshots from around the date of
> comments, or current trunk, neither on the larger nor shorter testcase.
Strange.
Just double checked and it still ICEs for me:
% ../gcc/configure --disable-bootstrap --disable-libvtv --disable-libitm
--disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror
--disable-multilib --enable-languages=c,c++
% make -j4 && make DESTDIR=/var/tmp/gcc_test install
% /var/tmp/gcc_test/usr/local/bin/g++ -O3 -c test.ii
test.ii:113:35: internal compiler error: Floating point exception
void addServer() { I(new P); }
^
0xb44e9f crash_signal
../../gcc/gcc/toplev.c:336
0x53c863 want_inline_self_recursive_call_p
../../gcc/gcc/ipa-inline.c:708
0x1023819 inline_small_functions
../../gcc/gcc/ipa-inline.c:1767
0x1023819 ipa_inline
../../gcc/gcc/ipa-inline.c:2020
0x1023819 execute
../../gcc/gcc/ipa-inline.c:2390
Please submit a full bug report,
with preprocessed source if appro
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #2 from Markus Trippelsdorf --- (In reply to David Kredba from comment #1) > I can reproduce this with Gentoo gcc-4.8.2 and new KDE's kig package 4.11.4. > > How to debug this please? http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #4 from Markus Trippelsdorf --- I've tested this on my Gentoo box and cannot reproduce the issue on trunk or gcc-4.8 branch. So it is most likely already fixed.
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 --- Comment #5 from Markus Trippelsdorf --- (In reply to Alexander Ivchenko from comment #4) > This broke Android image build with trunk compiler (in addition to pr58585).. Yes. Many C++ projects that use multiple inheritance don't compile ATM: Chromium, KDE, etc.
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #9 from Markus Trippelsdorf --- Jason, can you address Honza's questions from comment 8 please? This issue breaks many C++ projects and makes testing impossible.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #10 from Markus Trippelsdorf --- (In reply to David Kredba from comment #8) > Going to attach ii file gzipped. > > What can I do next please? You can now further reduce the single testfile by following the "Simple ICE reduction" section in the document I've linked to above. First try to minimize the gcc command line options that you use. Then write a simple test script, e.g.: $ cat chech.sh /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -ggdb -flto -r -nostdlib -Wfatal-errors test.ii -o /dev/null 2>&1 | grep 'internal compiler error: in splice_child_die' if ! test $? = 0; then exit 1 fi and run delta, multidelta or Creduce with it.
[Bug tree-optimization/59417] ICE in determine_value_range, at tree-ssa-loop-niter.c:176
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417 Markus Trippelsdorf changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf --- Git blame points to r204516.
[Bug ipa/59201] [4.9 Regression] error: stmt (0x7f01c4708130) marked modified after optimization pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59201 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Markus Trippelsdorf --- Seems to be fixed.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #13 from Markus Trippelsdorf --- Created attachment 31401 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31401&action=edit Further reduced Further reduced.
[Bug lto/58251] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #14 from Markus Trippelsdorf --- (In reply to David Kredba from comment #11) > Delta died after more than 20 iterations. Started new delta. A little > more reduced ii file uploaded. Boost testcases are always fun ;-) For testcase this huge I recommend Creduce, because it runs in parallel by default.
[Bug lto/58251] [4.7/4.8 Regression] -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 --- Comment #16 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #15) > Confirmed with 4.7.3 and 4.8.2. Seems to work on the trunk, worked with > 4.6.4. > > Now it would be interesting to bisect what fixed this on the trunk ... It was fixed by r200151.
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
--- Comment #9 from Markus Trippelsdorf ---
This issue also happens when building LLVM.
Reduced:
markus@x4 llvm_build % cat test.ii
template struct A;
template struct A<_Tp *> {
typedef _Tp value_type;
typedef int difference_type;
};
template struct B {};
template struct C {
_Compare _M_comp;
template
int operator()(_Value &p1, _Iterator p2) {
return _M_comp(p1, *p2);
}
};
template C<_Compare> __val_comp_iter(B<_Compare>);
template
void __unguarded_linear_insert(_RandomAccessIterator p1, _Compare p2) {
typename A<_RandomAccessIterator>::value_type a;
_RandomAccessIterator b = p1;
--b;
while (p2(a, b)) {
*p1 = 0;
p1 = b;
--b;
}
}
template
void __insertion_sort(_RandomAccessIterator, _Compare p2) {
for (_RandomAccessIterator c;; ++c)
__unguarded_linear_insert(c, __val_comp_iter(p2));
}
template
void __chunk_insertion_sort(_RandomAccessIterator, _Distance, _Compare p3) {
_RandomAccessIterator d;
__insertion_sort(d, p3);
}
template
void __merge_sort_with_buffer(_RandomAccessIterator p1, _Pointer, _Compare p3)
{
__chunk_insertion_sort(p1, 0, p3);
}
template
void __stable_sort_adaptive(_RandomAccessIterator, _Pointer, _Distance,
_Compare p4) {
_RandomAccessIterator e;
__merge_sort_with_buffer(e, 0, p4);
}
template
void __stable_sort(_RandomAccessIterator p1, _Compare p2) {
__stable_sort_adaptive(
p1, 0, typename A<_RandomAccessIterator>::difference_type(), p2);
}
template
void stable_sort(_RandomAccessIterator, _RandomAccessIterator p2, _Compare) {
B<_Compare> f;
__stable_sort(p2, f);
}
class D {
public:
void m_fn1();
};
class F {
struct G {
D MFI;
int operator()(int p1, int p2) {
if (p1)
return 0;
if (p2)
return 1;
MFI.m_fn1();
}
};
void m_fn1(int &p1) const;
};
void F::m_fn1(int &p1) const {
int *g, *h;
stable_sort(h, g, G());
}
markus@x4 llvm_build % g++ -O2 -c test.ii
test.ii: In member function ‘void F::m_fn1(int&) const’:
test.ii:74:6: internal compiler error: in add_old_iv_candidates, at
tree-ssa-loop-ivopts.c:2541
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 Markus Trippelsdorf changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #10 from Markus Trippelsdorf --- Started with r205848.
[Bug lto/59469] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #1 from Markus Trippelsdorf --- Created attachment 31417 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31417&action=edit testcase
[Bug lto/59469] New: LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 Bug ID: 59469 Summary: LLVM build failure with gcc LTO Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: octoploid at yandex dot com Building LLVM with LTO fails: ... lib/libLLVMAsmParser.so: error: undefined reference to 'llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits&, llvm::ilist_iterator, llvm::ilist_iterator)' This only happens with "-O3 -flto": markus@x4 llvm_build % g++ -flto-partition=none -flto -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii markus@x4 llvm_build % nm ./a.out | c++filt | grep "llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits::transferNodesFromList(llvm::ilist_traits::transferNodesFromList(llvm::ilist_traits&, llvm::ilist_iterator, llvm::ilist_iterator) markus@x4 llvm_build % g++ -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii markus@x4 llvm_build % nm ./a.out | c++filt | grep "llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits::transferNodesFromList(llvm::ilist_traits&, llvm::ilist_iterator, llvm::ilist_iterator) markus@x4 llvm_build % I will try to reduce this further.
[Bug lto/59469] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #2 from Markus Trippelsdorf ---
markus@x4 llvm_build % cat BasicBlock.ii
struct A {};
namespace llvm {
struct B {};
template struct ilist_traits : B {};
template class ilist_iterator : A {
public:
ilist_iterator(int) {}
int operator!=(ilist_iterator &);
void operator++();
};
template >
class C : Traits {
C &transfer_L2;
public:
A splice_where;
void splice() { this->transferNodesFromList(transfer_L2, 0, 0); }
};
class Function;
template
class SymbolTableListTraits : B {
public:
ItemParentClass *getListOwner();
void transferNodesFromList(ilist_traits &p1,
ilist_iterator,
ilist_iterator);
};
class BasicBlock {
Function *getParent();
void moveBefore();
};
template
void
SymbolTableListTraits::transferNodesFromList(
ilist_traits &p1, ilist_iterator p2,
ilist_iterator p3) {
ItemParentClass a = *getListOwner() = *p1.getListOwner();
int b = *ilist_traits::getSymTab(0);
for (; p2 != p3; ++p2)
;
}
template <>
struct ilist_traits : SymbolTableListTraits {
static int *getSymTab(Function *);
};
class Function : BasicBlock {
public:
C &getBasicBlockList();
};
}
using namespace llvm;
BasicBlock c;
void BasicBlock::moveBefore() {
c.getParent()->getBasicBlockList().splice();
c.getParent()->getBasicBlockList().splice();
}
markus@x4 llvm_build % cat Function.ii
struct A {};
namespace llvm {
template struct ilist_traits;
class Function;
struct B {};
template class ilist_iterator : A {};
template class SymbolTableListTraits : B {
void transferNodesFromList(ilist_traits &p1,
ilist_iterator,
ilist_iterator);
};
class BasicBlock;
template
void
SymbolTableListTraits::transferNodesFromList(
ilist_traits &p1, ilist_iterator,
ilist_iterator) {}
}
using namespace llvm;
template class ::SymbolTableListTraits;
markus@x4 llvm_build % g++ -flto -O3 -fPIC -shared BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
markus@x4 llvm_build % g++ -flto -O2 -fPIC -shared BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
09e0 t llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits&,
llvm::ilist_iterator, llvm::ilist_iterator)
markus@x4 llvm_build % g++ -O3 -fPIC -shared BasicBlock.ii Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
0b50 W llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits&,
llvm::ilist_iterator, llvm::ilist_iterator)
markus@x4 llvm_build % clang++ -flto -O3 -w -fPIC -shared BasicBlock.ii
Function.ii
markus@x4 llvm_build % nm ./a.out | c++filt | grep ::transferNodesFromList
0b70 W llvm::SymbolTableListTraits::transferNodesFromList(llvm::ilist_traits&,
llvm::ilist_iterator, llvm::ilist_iterator)
markus@x4 llvm_build %
[Bug lto/59469] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #3 from Markus Trippelsdorf --- BTW it is interesting that gcc compiles the attached testcase faster when using LTO. % time g++ -flto=4 -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii 52.48s user 0.59s system 168% cpu 31.545 total % time g++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii 46.94s user 0.30s system 99% cpu 47.258 total (for comparison clang trunk (70% faster): % time clang++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii Function.ii 15.48s user 0.14s system 99% cpu 15.628 total)
[Bug lto/59469] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #5 from Markus Trippelsdorf --- (In reply to Andrew Pinski from comment #4) > (In reply to Markus Trippelsdorf from comment #3) > > BTW it is interesting that gcc compiles the attached testcase faster > > when using LTO. > > > > % time g++ -flto=4 -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii > > Function.ii > > 52.48s user 0.59s system 168% cpu 31.545 total > > % time g++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii > > Function.ii > > 46.94s user 0.30s system 99% cpu 47.258 total > > > > (for comparison clang trunk (70% faster): > > % time clang++ -Wfatal-errors -fPIC -shared -fno-rtti -O3 BasicBlock.ii > > Function.ii > > 15.48s user 0.14s system 99% cpu 15.628 total) > > Is GCC configured with --enable-checking=release? If not then you should > not compare to LLVM's compile time. Yes. Sorry, I forgot to mention it: --enable-checking=release PGO/LTO build.
[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from Markus Trippelsdorf --- I'm still getting: ... libreoffice-4.1.3.2/canvas/source/factory/cf_service.cxx:528:1: warning: macro "__code_model_small__" is not used [-Wunused-macros] } ^
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #7 from Markus Trippelsdorf --- Gcc now uses slim-LTO-objects by default. Therefore you need to run binutils (ar, nm, ranlib) that use the linker plugin. You can use gcc-ar, etc. for this purpose.
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #9 from Markus Trippelsdorf --- (In reply to David Kredba from comment #8) > Thank you Markus. > Could you please tell me if binutils 2.24.51.0.2 are OK for this? Unfortunately not out of the box. I use the attached simple patch for binutils. With this I can symlink to the linker plugin in /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins (my be a different directory on your machine) and ar, nm and ranlib will use the plugin by default. I can also switch between gcc and llvm plugins, e.g.: markus@x4 ~ % plugin_gcc markus@x4 ~ % ll /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins total 12K drwxr-xr-x 2 root root 4.0K Dec 14 12:01 . drwxr-xr-x 3 root root 4.0K Oct 7 2012 .. lrwxrwxrwx 1 root root 65 Dec 14 12:01 liblto_plugin.so.0.0.0 -> /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/liblto_plugin.so.0.0.0 markus@x4 ~ % plugin_clang markus@x4 ~ % ll /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins total 8.0K drwxr-xr-x 2 root root 4.0K Dec 14 12:01 . drwxr-xr-x 3 root root 4.0K Oct 7 2012 .. lrwxrwxrwx 1 root root 26 Dec 14 12:01 LLVMgold.so -> /usr/local/lib/LLVMgold.so markus@x4 ~ % Where plugin_gcc and plugin_clang are simple scripts to change the symlink. > I will try AR=gcc-ar etc in the meantime. This should work.
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #10 from Markus Trippelsdorf --- Created attachment 31437 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31437&action=edit binutils patch
[Bug lto/59505] gcc-4.9.0-20131208 can't link glsl_compiler with -flto=4 in -m32 where gcc-4.8.2 works fine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505 --- Comment #12 from Markus Trippelsdorf --- (In reply to David Kredba from comment #11) > And I will try your binutils patch. > > Do you think that for 4.9.0 GCC release binutils will support > slim-LTO-objects? > LTO support for general use in Gentoo will not be enabled without it in my > opinion. (But maybe if USE/FEATURE lto will be detected they can let > ebuild/emerge export AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib to > environment.) I'm not sure. I've posted the simple patch a while ago and it was ignored. BTW the best solution would be if one could install *both* plugins to the ../lib/bfd-plugins directory and the correct one would be used automatically. I don't know if anyone is working on that.
[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265 Markus Trippelsdorf changed: What|Removed |Added CC||octoploid at yandex dot com --- Comment #1 from Markus Trippelsdorf --- Created attachment 31440 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31440&action=edit testcase with gcda Also happens during Firefox PGO build: markus@x4 src % c++ -w -c -fprofile-use -fprofile-correction -std=gnu++0x -O2 Unified_cpp_3.ii In file included from /var/tmp/moz-build-dir/js/src/Unified_cpp_3.cpp:137:0: /var/tmp/mozilla-central/js/src/jit/MCallOptimize.cpp: In member function ‘virtual void js::jit::LPhi::printInfo(FILE*)’: /var/tmp/mozilla-central/js/src/jit/MCallOptimize.cpp:1484:1: internal compiler error: Segmentation fault
[Bug ipa/59265] [4.9 Regression] Segmentation fault in ipa_note_param_call for -fprofile-use in SPEC CPU2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #2 from Markus Trippelsdorf ---
Here's a reduced testcase that works without any gcda file:
markus@x4 testcase % < test.ii
class A {
int m_fn1() const;
unsigned m_fn2() const;
};
class B {
public:
virtual void m_fn1();
};
class C final : B {
C();
virtual void m_fn2() { m_fn1(); }
};
int a;
unsigned A::m_fn2() const {
if (m_fn1())
return 0;
a = m_fn2();
}
C::C() {}
markus@x4 testcase % c++ -c -fprofile-use -O2 -std=c++11 test.ii
test.ii: In member function ‘virtual void C::m_fn2()’:
test.ii:19:9: internal compiler error: Segmentation fault
C::C() {}
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #7 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #6) > With -fno-fat-lto-objects we are also faster on SPEC build time and I think > it should be the case in general. We produce considerably less code and > most of time is spent in the backend. For super large projects with > parallel makefiles the time spent in serial WPA may overweight the benefits, > but for GCC and firefox I believe the only problem is that it builds > multiple binaries from same static libraries. Here we end up optimizing the > static libraries many times, while in traditional build we optimize just > once. Naive question: Why not use dynamic libraries in the case of gcc? > Let me see if I can reproduce the weak symbol. In these cases my life would > be a lot easier if you attached the resolution file and told me the > unmangled name of the symbol. But thanks a lot for the analysis and LTO > testing! It is badly needed. sorry: _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ % cat BasicBlock.res 2 BasicBlock.o 9 234 e1ebf4c224baf514 PREVAILING_DEF_IRONLY_EXP _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ 239 e1ebf4c224baf514 PREVAILING_DEF_IRONLY_EXP _ZN4llvm10BasicBlock10moveBeforeEv 290 e1ebf4c224baf514 PREVAILING_DEF_IRONLY_EXP c 247 e1ebf4c224baf514 UNDEF _ZN4llvm14ilist_iteratorINS_10BasicBlockEEneERS2_ 252 e1ebf4c224baf514 UNDEF _ZN4llvm14ilist_iteratorINS_10BasicBlockEEppEv 257 e1ebf4c224baf514 UNDEF _ZN4llvm12ilist_traitsINS_10BasicBlockEE9getSymTabEPNS_8FunctionE 262 e1ebf4c224baf514 UNDEF _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE12getListOwnerEv 283 e1ebf4c224baf514 UNDEF _ZN4llvm8Function17getBasicBlockListEv 288 e1ebf4c224baf514 UNDEF _ZN4llvm10BasicBlock9getParentEv Function.o 1 214 bf4c643d7570440b PREEMPTED_IR _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #11 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #8) > OK, the unmangled name of symbol is: > 0004c8c0 T > _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes > FromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ > > and obviously for me it is T for -O2 and for -O3 it is optimized out. Both > seems legitimate. Can you please re-check with current mainline? > > I get: > df live regs: 7.74 (12%) usr 0.00 ( 0%) sys 7.72 (12%) > wall 0 kB ( 0%) ggc > df live&initialized regs: 11.02 (17%) usr 0.00 ( 0%) sys 10.91 (17%) > wall 0 kB ( 0%) ggc > CPROP : 20.03 (32%) usr 0.44 (65%) sys 20.51 (32%) > wall7968 kB ( 5%) ggc > > (with checking on, but still seems something for steve, I do not think there > is particularly expensive checking in CPROP) > > I am re-checking with 4.8 4.7 and 4.8 are also slow. perf top shows: 12.80% cc1plus cc1plus [.] compute_cprop_data() 8.64% cc1plus cc1plus [.] df_worklist_dataflow(dataflow*, bitmap_head*, int*, int) 5.80% cc1plus cc1plus [.] bitmap_set_bit(bitmap_head*, int) 4.61% cc1plus cc1plus [.] bitmap_ior_into(bitmap_head*, bitmap_head const*) ...
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #12 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #10) > I also saw in past problems with GNU-ld and comdat symbols becoming static > while being comdat somewhere else. Do you use gold or ld? Can you perhaps > try to use the other one and see if anything changes? I use gold. But it doesn't matter in this case, because bfd behaves identical. Thanks for your analysis. I just added a few __attribute__((used)) for now and this fixes the issue.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #16 from Markus Trippelsdorf --- (In reply to H.J. Lu from comment #14) > (In reply to H.J. Lu from comment #13) > > Can you try bfd linker, hjl/linux/release/2.24.51.0.2, from > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=summary > > > > It has a modified LTO bfd linker. > > You need to build LLVM from scratch with my bfd linker. I've tried your bfd version, but it doesn't help.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #17 from Markus Trippelsdorf --- In the non-lto case one has: lib/libLLVMAsmParser.so: U _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ lib/libLLVMCore.so: 00071e90 W _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8 Later they get linked together: ... -o bin/llvm-as lib/libLLVMAsmParser.so ... lib/libLLVMCore.so ... In the lto case the weak symbol in lib/libLLVMCore.so is optimized out and the build fails. lib/libLLVMCore.so normally gets this weak symbol from BasicBlock.ii and Function.ii, that I've attached above. If I understand you correctly, you say that the undefined symbol of lib/libLLVMAsmParser.so is a bug in LLVM.
