Re: clang makes segfaulting code with -march=core2 on i386
On 16.09.2014 10:53, Andrey Chernov wrote: Probably it have sense to track down and look at first post-4.7 gcc/tree.c change which cause fail (gcc47 works with BOOTSTRAP=off). Anybody have an idea what kind of magic in gcc is changed, when this DEV-PHASE file is altered? Some debug code or internal assertion checking might be turned on or off? Either try to grep the file or string space simple shifted by several bytes. As I test today, gcc5 20140914 from the ports builds normally with BOOTSTRAP=off -march=core2 -O2 -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
Re: clang makes segfaulting code with -march=core2 on i386
On 12 Sep 2014, at 22:52, Andrey Chernov a...@freebsd.org wrote: On 13.09.2014 0:44, Andrey Chernov wrote: On 12.09.2014 22:40, Andrey Chernov wrote: I don't have -current i386 combination, but I can try -current x64 later (with different -march). It works on -current, amd64, -march=core2. So it either -stable or i386-specific clang bug. I forget to say that real CPU on -current tested is not the same as for failing i386: QuadCore Intel Core i7-3820 After some massaging of gcc's source to disable its built-in segfault handlers, I get this backtrace: Program received signal SIGSEGV, Segmentation fault. find_parameter_packs_r (tp=0x2c3212fc, walk_subtrees=0xbfbfda60, data=0xbfbfdb58) at .././../gcc-4.8.3/gcc/cp/pt.c:3063 3063 if (TYPE_P (t) (gdb) bt #0 find_parameter_packs_r (tp=0x2c3212fc, walk_subtrees=0xbfbfda60, data=0xbfbfdb58) at .././../gcc-4.8.3/gcc/cp/pt.c:3063 #1 0x086a111c in walk_tree_1 (tp=optimized out, func=optimized out, data=optimized out, pset=0x295e00a0, lh=optimized out) at .././../gcc-4.8.3/gcc/tree.c:10700 #2 0x086a15f6 in walk_tree_1 (tp=optimized out, func=optimized out, data=optimized out, pset=0x295e00a0, lh=optimized out) at .././../gcc-4.8.3/gcc/tree.c:10954 #3 0x086a1555 in walk_tree_1 (tp=optimized out, func=optimized out, data=optimized out, pset=optimized out, lh=optimized out) at .././../gcc-4.8.3/gcc/tree.c:10747 #4 0x081ed0ef in cp_walk_subtrees (tp=0xbfbfdb68, walk_subtrees_p=0x29401674, func=optimized out, data=optimized out, pset=optimized out) at .././../gcc-4.8.3/gcc/cp/tree.c:3522 #5 0x086a118c in walk_tree_1 (tp=optimized out, func=optimized out, data=optimized out, pset=optimized out, lh=optimized out) at .././../gcc-4.8.3/gcc/tree.c:10723 #6 0x0813b6fc in check_for_bare_parameter_packs (t=0x2c388514) at .././../gcc-4.8.3/gcc/cp/pt.c:3357 #7 0x081c4707 in check_return_expr (retval=0x2c388514, no_warning=optimized out) at .././../gcc-4.8.3/gcc/cp/typeck.c:8156 #8 0x081da7b9 in finish_return_stmt (expr=0x2c388514) at .././../gcc-4.8.3/gcc/cp/semantics.c:793 #9 0x0819a799 in cp_parser_jump_statement (parser=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:10150 #10 cp_parser_statement (parser=0x298ea1c0, in_statement_expr=0x0, in_compound=optimized out, if_p=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:8877 #11 0x081990c8 in cp_parser_statement_seq_opt (parser=0x298ea1c0, in_statement_expr=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9241 #12 0x08198f5f in cp_parser_compound_statement (parser=optimized out, in_statement_expr=optimized out, in_try=optimized out, function_body=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:9195 #13 0x0819dd96 in cp_parser_implicitly_scoped_statement (parser=optimized out, if_p=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:10237 #14 0x0819a8e4 in cp_parser_selection_statement (parser=0x298ea1c0, if_p=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9347 #15 cp_parser_statement (parser=0x298ea1c0, in_statement_expr=0x0, in_compound=optimized out, if_p=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:8864 #16 0x0819ddbb in cp_parser_implicitly_scoped_statement (parser=optimized out, if_p=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:10244 #17 0x0819a8e4 in cp_parser_selection_statement (parser=0x298ea1c0, if_p=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9347 #18 cp_parser_statement (parser=0x298ea1c0, in_statement_expr=0x0, in_compound=optimized out, if_p=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:8864 #19 0x081990c8 in cp_parser_statement_seq_opt (parser=0x298ea1c0, in_statement_expr=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9241 #20 0x0819dbfe in cp_parser_already_scoped_statement (parser=0x298ea1c0) at .././../gcc-4.8.3/gcc/cp/parser.c:10273 #21 0x0819a045 in cp_parser_iteration_statement (parser=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:9938 #22 cp_parser_statement (parser=0x298ea1c0, in_statement_expr=0x0, in_compound=optimized out, if_p=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:8870 #23 0x081990c8 in cp_parser_statement_seq_opt (parser=0x298ea1c0, in_statement_expr=0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9241 #24 0x08198f5f in cp_parser_compound_statement (parser=optimized out, in_statement_expr=optimized out, in_try=optimized out, function_body=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:9195 #25 0x08198e33 in cp_parser_function_body (parser=optimized out, parser=optimized out, in_function_try_block=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:17816 #26 cp_parser_ctor_initializer_opt_and_function_body (parser=0x298ea1c0, in_function_try_block=optimized out) at .././../gcc-4.8.3/gcc/cp/parser.c:17852 #27 0x08198a14 in cp_parser_function_definition_after_declarator (parser=0x298ea1c0, inline_p=false) at .././../gcc-4.8.3/gcc/cp/parser.c:21831 #28 0x08183dcb in cp_parser_function_definition_from_specifiers_and_declarator (parser=optimized out, decl_specifiers=optimized out, attributes=optimized out,
Re: clang makes segfaulting code with -march=core2 on i386
On 13.09.2014 20:45, Dimitry Andric wrote: After some massaging of gcc's source to disable its built-in segfault handlers, I get this backtrace: Do you get this with my core or finally able to reproduce it by yourself? I think it's most likely this is some type of undefined behavior in gcc, which leads to randomly corrupted tree values. Of course, it could also be a clang bug, but I don't see any 64-bit instructions in there at all. This needs to be investigated further, but it's very hard to understand what is going on the guts of gcc's parser. Let alone to reduce this to some sort of reproducible test case. By first glance I see a lots of optimized out things. It is known that in edge cases gcc preserves more unused values than clang. It can be the possible case. I'll try to lower -O level preserving -march=core2 and see. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
Re: clang makes segfaulting code with -march=core2 on i386
On 13 Sep 2014, at 20:00, Andrey Chernov a...@freebsd.org wrote: On 13.09.2014 20:45, Dimitry Andric wrote: After some massaging of gcc's source to disable its built-in segfault handlers, I get this backtrace: Do you get this with my core or finally able to reproduce it by yourself? I was able to reproduce it, on stable/10. I could not reproduce it on head, but that is how it sometimes goes with this kind of issue. :) I think it's most likely this is some type of undefined behavior in gcc, which leads to randomly corrupted tree values. Of course, it could also be a clang bug, but I don't see any 64-bit instructions in there at all. This needs to be investigated further, but it's very hard to understand what is going on the guts of gcc's parser. Let alone to reduce this to some sort of reproducible test case. By first glance I see a lots of optimized out things. It is known that in edge cases gcc preserves more unused values than clang. It can be the possible case. I'll try to lower -O level preserving -march=core2 and see. It seems to work for me with -O1 -march=core2, and while valgrind does complain a little, the warnings are all benign. I'll see if I can mix and match a few -O2 and -O1 compiled objects, to zero in on where the problematic area(s) are. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
clang makes segfaulting code with -march=core2 on i386
Hi. Please look at this thread. At the end the bug trigger found, since removing -march=core2 fix the thing. tijl@ suspects that clang produce 64bit instruction on i386 in that case. https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html -- http://ache.vniz.net/ ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: clang makes segfaulting code with -march=core2 on i386
On 12.09.2014 21:20, Dimitry Andric wrote: On 12 Sep 2014, at 17:01, Andrey Chernov a...@freebsd.org wrote: Please look at this thread. At the end the bug trigger found, since removing -march=core2 fix the thing. tijl@ suspects that clang produce 64bit instruction on i386 in that case. https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html I just built lang/gcc successfully on 11.0-CURRENT and i386, using -march=core2, but saw no crashes at all. Is this limited specifically to stable/10? Do you also have a coredump of the crashed process? -Dimitry For all cases check in 'make config' that BOOTSTRAP is off, because it not fail when gcc bootstraps itself. To see correct error place set env MAKE_JOBS_UNSAFE=yes because gcc try to build some things in parallel and segfault can come in the middle of other unrelated compilation. Not only lang/gcc segfaulting, but also lang/gcc48 and lang/gcc49 (last one fails in stdc++ too but for different (first) file). xgcc does not dump core by default. I use -dH switch to force core dump running the faulting command manually. Core was generated by `cc1plus'. Program terminated with signal 6, Aborted. (gdb) bt #0 0x28f4c307 in kill () from /lib/libc.so.7 #1 0x28f4c297 in raise () from /lib/libc.so.7 #2 0x28f4a8d6 in abort () from /lib/libc.so.7 #3 0x0892f138 in real_abort () #4 0x0892e7ac in diagnostic_action_after_output () #5 0x0892e4ca in diagnostic_report_diagnostic () #6 0x0892f106 in internal_error () #7 0x0853b17e in crash_signal () #8 0xbfbff004 in ?? () #9 0x000b in ?? () #10 0x0001 in ?? () #11 0xbfbfab40 in ?? () #12 0x08d208d8 in ?? () #13 0x0853b140 in alloc_for_identifier_to_locale () #14 0x081f2a8c in gt_pch_nx_lang_tree_node () #15 0x081f1bd6 in gt_pch_nx_lang_tree_node () #16 0x081f26c1 in gt_pch_nx_lang_tree_node () #17 0x081f22ab in gt_pch_nx_lang_tree_node () #18 0x081f2260 in gt_pch_nx_lang_tree_node () #19 0x081f1e62 in gt_pch_nx_lang_tree_node () #20 0x081f271b in gt_pch_nx_lang_tree_node () #21 0x081f231d in gt_pch_nx_lang_tree_node () #22 0x081f4304 in gt_pch_nx_lang_type () #23 0x081f270c in gt_pch_nx_lang_tree_node () #24 0x081f1ba9 in gt_pch_nx_lang_tree_node () #25 0x081f226f in gt_pch_nx_lang_tree_node () #26 0x081f1ba9 in gt_pch_nx_lang_tree_node () #27 0x081f2a8c in gt_pch_nx_lang_tree_node () #28 0x081f42f5 in gt_pch_nx_lang_type () #29 0x081f270c in gt_pch_nx_lang_tree_node () #30 0x081f26fd in gt_pch_nx_lang_tree_node () #31 0x081f26ee in gt_pch_nx_lang_tree_node () #32 0x081f26d0 in gt_pch_nx_lang_tree_node () #33 0x081f26df in gt_pch_nx_lang_tree_node () #34 0x081f1ba9 in gt_pch_nx_lang_tree_node () #35 0x081f26c1 in gt_pch_nx_lang_tree_node () #36 0x081f2260 in gt_pch_nx_lang_tree_node () #37 0x081f2a8c in gt_pch_nx_lang_tree_node () #38 0x081f271b in gt_pch_nx_lang_tree_node () #39 0x081f1ff9 in gt_pch_nx_lang_tree_node () [rest stripped...] As you see, last meaningful info say something about locale. If system locale assumed here, I use ru_RU.KOI8-R. I try to check this thing with LANG=C later. I don't have -current i386 combination, but I can try -current x64 later (with different -march). Instruction set may depends on CPU, I have Core2 Duo E8400 which should match -march=core2 in theory. For lang/gcc the bug starts on second stdc++ file compiling, related log from the entering stdc++ directory: gmake[5]: Entering directory `/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3' Making all in include gmake[6]: Entering directory `/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/include' mkdir -p ./i386-portbld-freebsd10.1/bits/stdc++.h.gch /usr/ports/lang/gcc/work/build/./gcc/xgcc -shared-libgcc -B/usr/ports/lang/gcc/work/build/./gcc -nostdinc++ -L/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/src -L/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/src/.libs -B/usr/local/i386-portbld-freebsd10.1/bin/ -B/usr/local/i386-portbld-freebsd10.1/lib/ -isystem /usr/local/i386-portbld-freebsd10.1/include -isystem /usr/local/i386-portbld-freebsd10.1/sys-include-x c++-header -nostdinc++ -g -O2 -pipe -march=core2 -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG -I/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/include/i386-portbld-freebsd10.1 -I/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/include -I/usr/ports/lang/gcc/work/gcc-4.8.3/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /usr/ports/lang/gcc/work/gcc-4.8.3/libstdc++-v3/include/precompiled/stdc++.h \ -o i386-portbld-freebsd10.1/bits/stdc++.h.gch/O2ggnu++0x.gch mkdir -p ./i386-portbld-freebsd10.1/bits/stdc++.h.gch /usr/ports/lang/gcc/work/build/./gcc/xgcc -shared-libgcc -B/usr/ports/lang/gcc/work/build/./gcc -nostdinc++ -L/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/src -L/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/src/.libs
Re: clang makes segfaulting code with -march=core2 on i386
On 12.09.2014 22:40, Andrey Chernov wrote: As you see, last meaningful info say something about locale. If system locale assumed here, I use ru_RU.KOI8-R. I try to check this thing with LANG=C later. Does not help. The same fault with LANG=C too. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
Re: clang makes segfaulting code with -march=core2 on i386
On 12.09.2014 22:40, Andrey Chernov wrote: I don't have -current i386 combination, but I can try -current x64 later (with different -march). It works on -current, amd64, -march=core2. So it either -stable or i386-specific clang bug. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
