[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #12 from Chen Gang gang.chen at asianux dot com --- I am just comparing the issue code demo and the other 3 correct code demo (the demostrations which del one param, or add one param, or add two params are all correct). I find the issue code contents additonal one 'code_label' insn in its rtx tree, before create trace. I will continue analyzing, it seems, by comparing the issue demo and the other 3 correct demo, and dumping related information step by step, can find the root cause.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #10 from Chen Gang gang.chen at asianux dot com --- Created attachment 30826 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30826action=edit (sorry, it is cc1 issue) It is the related command line for cc1 and the summary work flow for gcc-4.8.0 and gcc-4.9.0 Oh, sorry, the comments #9 is obsoleted, it is not caused by xgcc (although their work flow are different with each other), our issue is cc1 issue. The attachment is the related command line for cc1 and the summary call flow for gcc-4.8.0 and gcc-4.9.0. I will continue to analyze the first different between them. Welcome any suggestions and completions, thanks.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #11 from Chen Gang gang.chen at asianux dot com --- It seems, I am really really a newbie !! 1. after append -gstabs+, can let gdb work well. 2. can use the internal dump_file (dump_start/dump_end) to analyze all information (although I still don't know how to use it now). 3. that means: what I have done above is almost all 'spam'. :-( I will continue trying tomorrow.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #8 from Chen Gang gang.chen at asianux dot com --- For gcc-4.9.0, I got summary trace for it (call stack for cc1, how many the related loopings during calling flow), hope it may be a little useful. (I will do the same thing for gcc-4.8.0, and compare them). And it seems: gdb can not print the variables' value when g++ -g -Wall -static-libstdc++ -static-libgcc which is effect with cc1 and xgcc. If can let gdb print the vaiables' value, life will be a little easier (don't need dump the related variables' values mannually). Welcome any additional suggestions or completions. (gdb) bt #0 maybe_record_trace_start(rtx_def*, rtx_def*) () at ../../gcc-4.9.0/gcc/dwarf2cfi.c:2184 #1 0x006da82b in scan_trace(dw_trace_info*) () at ../../gcc-4.9.0/gcc/dwarf2cfi.c:2399 #2 0x006dadeb in create_cfi_notes() () at ../../gcc-4.9.0/gcc/dwarf2cfi.c:2557 #3 0x006db8e5 in execute_dwarf2_frame() () at ../../gcc-4.9.0/gcc/dwarf2cfi.c:2912 #4 0x006dc5e3 in (anonymous namespace)::pass_dwarf2_frame::execute() () at ../../gcc-4.9.0/gcc/dwarf2cfi.c:3408 #5 0x00989d20 in execute_one_pass(opt_pass*) () at ../../gcc-4.9.0/gcc/passes.c:2201 #6 0x00989f41 in execute_pass_list(opt_pass*) () at ../../gcc-4.9.0/gcc/passes.c:2257 #7 0x00989f72 in execute_pass_list(opt_pass*) () at ../../gcc-4.9.0/gcc/passes.c:2258 #8 0x00989f72 in execute_pass_list(opt_pass*) () at ../../gcc-4.9.0/gcc/passes.c:2258 #9 0x0068cbbd in expand_function(cgraph_node*) () at ../../gcc-4.9.0/gcc/cgraphunit.c:1723 #10 0x0068d085 in expand_all_functions() () at ../../gcc-4.9.0/gcc/cgraphunit.c:1828 #11 0x0068d9e9 in compile() () at ../../gcc-4.9.0/gcc/cgraphunit.c:2165 #12 0x0068db62 in finalize_compilation_unit() () at ../../gcc-4.9.0/gcc/cgraphunit.c:2242 #13 0x005225ac in c_write_global_declarations() () at ../../gcc-4.9.0/gcc/c/c-decl.c:10125 #14 0x00a4c25b in compile_file() () at ../../gcc-4.9.0/gcc/toplev.c:560 #15 0x00a4e22e in do_compile() () at ../../gcc-4.9.0/gcc/toplev.c:1891 #16 0x00a4e3a3 in toplev_main(int, char**) () at ../../gcc-4.9.0/gcc/toplev.c:1969 #17 0x00e5b390 in main () (gdb) r -Os -mint32 -mh -fomit-frame-pointer -g /tmp/ana/namei/namei.c Starting program: /android/src/build-gcc-h8300g/gcc/xgcc -Os -mint32 -mh -fomit-frame-pointer -g /tmp/ana/namei/namei.c gchen_tag: progname: xgcc, string: cc1 Detaching after fork from child process 8965. gchen_tag: execute_pass_list: level: 1, count: 0. gchen_tag: execute_pass_list: level: 1, count: 1. gchen_tag: execute_pass_list: level: 1, count: 2. gchen_tag: execute_pass_list: level: 1, count: 3. gchen_tag: execute_pass_list: level: 1, count: 4. gchen_tag: execute_pass_list: level: 1, count: 5. gchen_tag: execute_pass_list: level: 1, count: 6. gchen_tag: execute_pass_list: level: 1, count: 7. gchen_tag: execute_pass_list: level: 1, count: 8. gchen_tag: execute_pass_list: level: 1, count: 9. gchen_tag: execute_pass_list: level: 1, count: 10. gchen_tag: execute_pass_list: level: 1, count: 11. gchen_tag: execute_pass_list: level: 1, count: 12. gchen_tag: execute_pass_list: level: 1, count: 0. gchen_tag: execute_pass_list: level: 1, count: 1. gchen_tag: execute_pass_list: level: 1, count: 2. gchen_tag: execute_pass_list: level: 1, count: 3. gchen_tag: execute_pass_list: level: 1, count: 4. gchen_tag: execute_pass_list: level: 1, count: 5. gchen_tag: execute_pass_list: level: 1, count: 6. gchen_tag: execute_pass_list: level: 2, count: 0. gchen_tag: execute_pass_list: level: 2, count: 1. gchen_tag: execute_pass_list: level: 2, count: 2. gchen_tag: execute_pass_list: level: 2, count: 3. gchen_tag: execute_pass_list: level: 2, count: 4. gchen_tag: execute_pass_list: level: 2, count: 5. gchen_tag: execute_pass_list: level: 2, count: 6. gchen_tag: execute_pass_list: level: 2, count: 7. gchen_tag: execute_pass_list: level: 2, count: 8. gchen_tag: execute_pass_list: level: 2, count: 9. gchen_tag: execute_pass_list: level: 2, count: 10. gchen_tag: execute_pass_list: level: 2, count: 11. gchen_tag: execute_pass_list: level: 2, count: 12. gchen_tag: execute_pass_list: level: 2, count: 13. gchen_tag: execute_pass_list: level: 2, count: 14. gchen_tag: execute_pass_list: level: 2, count: 15. gchen_tag: execute_pass_list: level: 2, count: 16. gchen_tag: execute_pass_list: level: 1, count: 7. gchen_tag: execute_pass_list: level: 1, count: 8. gchen_tag: execute_pass_list: level: 1, count: 9. gchen_tag: execute_pass_list: level: 1, count: 10. gchen_tag: execute_pass_list: level: 1, count: 0. gchen_tag: execute_pass_list: level: 2, count: 0. gchen_tag: execute_pass_list: level: 2, count: 1. gchen_tag: execute_pass_list: level: 2, count: 2. gchen_tag: execute_pass_list: level: 2, count: 3. gchen_tag: execute_pass_list: level: 2, count: 4. gchen_tag: execute_pass_list
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #9 from Chen Gang gang.chen at asianux dot com --- Created attachment 30825 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30825action=edit Issue is within xgcc, can exclude cc1 by comparing the summary log between gcc-4.8.0 and gcc-4.9.0. By comparing the summary log between gcc-4.8.0 and gcc-4.9.0, the issue is within xgcc, we can exclude cc1. The attachment contents 3 files. err.diff: the gcc-4.9.0 summary log. correct.diff: the gcc-4.8.0 summary log. info.diff: my modification for gcc-4.9.0, so can print the related summary log (the same modification for gcc-4.8.0) I will continue to analyzing the details within xgcc, and also print more related varaibles for analyzing. Welcome any additional suggestions and completions, thanks.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #7 from Chen Gang gang.chen at asianux dot com --- Created attachment 30821 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30821action=edit some simple modification based on the reduced .c file. After learning from what you have done, and give a little additional trying, it seems we can focus on the new_devcode_dev(). If it is not defined or defined as a simple inline function, can cause issue. If use normal parameter (not inline function), it will be OK. If add/del one parameter before new_devcode_dev(), it also be OK. Please check the attachment for details. Hmm... next, is it a suitable/correct way to debug gcc-4.9.0 (can cause issue) and gcc-4.8.0 (no issue) for it with gdb, and comparing them? (I am just trying in this way) Thanks.
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 --- Comment #4 from Chen Gang gang.chen at asianux dot com --- Created attachment 30810 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30810action=edit the .i file for fs/ocfs2/dlm/dlmdomain.c (bzip2 compressed) I put the related .i files in attachments, which need bzip2 -d to decompress.
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 --- Comment #5 from Chen Gang gang.chen at asianux dot com --- Created attachment 30811 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30811action=edit the .i file for fs/ocfs2/dlm/dlmrecovery.c (bzip2 compressed)
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #4 from Chen Gang gang.chen at asianux dot com --- Created attachment 30812 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30812action=edit the .i file for fs/ext4/mballoc.c (bzip2 compressed) I put .i file in attachment which need bzip2 -d to decompress.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #5 from Chen Gang gang.chen at asianux dot com --- Created attachment 30813 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30813action=edit the .i file for fs/namei.c (bzip2 compressed) I put .i file for fs/namei.c which need bzip2 -d to decompress.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #1 from Chen Gang gang.chen at asianux dot com --- It is for Linux kernel next-20130828 version. and for the latest Linux kernel, h8/300 has been removed.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #2 from Chen Gang gang.chen at asianux dot com --- it is not found in gcc-4.8.0.
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- The related command line: /usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/.namei.o.d -nostdinc -isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include -I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude -I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32 -fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(namei) -DKBUILD_MODNAME=KBUILD_STR(namei) -c -o fs/.tmp_namei.o fs/namei.c
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #4 from Chen Gang gang.chen at asianux dot com --- (In reply to Chen Gang from comment #2) it is not found in gcc-4.8.0. That means: gcc-4.8.0 has no this issue, only 4.9.0 has (and in my memory, gcc-4.7.4 may also has this issue, but I am not quite sure).
[Bug c/58400] New: gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Bug ID: 58400
Summary: gcc for h8300 internal compiler error: insn does not
satisfy its constraints at fs/ext4/mballoc.c: In
function 'mb_free_blocks':
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
For Linux kernel next-20130828 version:
The command line:
/usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/ext4/.mballoc.o.d -nostdinc
-isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include
-I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude
-I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32
-fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g
-femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -DMODULE -DKBUILD_STR(s)=#s
-DKBUILD_BASENAME=KBUILD_STR(mballoc) -DKBUILD_MODNAME=KBUILD_STR(ext4) -c
-o fs/ext4/.tmp_mballoc.o fs/ext4/mballoc.c
The issue:
fs/ext4/mballoc.c: In function 'mb_free_blocks':
fs/ext4/mballoc.c:1459:1: error: insn does not satisfy its constraints:
}
^
(insn 453 831 454 59 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 32 [0x20])) [0 %sfp+-20 S1
A32]))
(const_int 1 [0x1])
(and:SI (reg:SI 5 r5)
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) fs/ext4/mballoc.c:1322 113 {*tstsi_variable_bit_qi}
(nil))
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #1 from Chen Gang gang.chen at asianux dot com --- fs/ext4/mballoc.c:1459:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:411 0x8e0a95 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc-4.9.0/gcc/rtl-error.c:109 0x8e0abf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc-4.9.0/gcc/rtl-error.c:120 0x89be7b reload_cse_simplify_operands ../../gcc-4.9.0/gcc/postreload.c:411 0x89da9c reload_cse_simplify ../../gcc-4.9.0/gcc/postreload.c:181 0x89da9c reload_cse_regs_1 ../../gcc-4.9.0/gcc/postreload.c:220 0x89deab reload_cse_regs ../../gcc-4.9.0/gcc/postreload.c:68 0x89deab rest_of_handle_postreload ../../gcc-4.9.0/gcc/postreload.c:2332 0x89deab execute ../../gcc-4.9.0/gcc/postreload.c:2368 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. make[2]: *** [fs/ext4/mballoc.o] Error 1 make[1]: *** [fs/ext4] Error 2 make: *** [fs] Error 2 The gcc information: [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.9.0/lto-wrapper Target: h8300-gchen-elf Configured with: ../gcc-4.9.0/configure --without-header --disable-nls --enable-language=c,c++ --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=h8300-gchen-elf Thread model: single gcc version 4.9.0 20130910 (experimental) (GCC)
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #2 from Chen Gang gang.chen at asianux dot com --- For gcc-4.8.0 and gcc-4.7.4, it has this issue too.
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- If no opitimization (without -Os), it will be OK.
[Bug c/58401] New: gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401
Bug ID: 58401
Summary: gcc for h8300 internal compiler error: insn does not
satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c:
In function 'dlm_query_join_handler'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
For Linux kernel next-20130828 version
The related command:
/usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/ocfs2/dlm/.dlmdomain.o.d
-nostdinc -isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include
-I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude
-I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32
-fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g
-femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -Ifs/ocfs2 -DMODULE
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(dlmdomain)
-DKBUILD_MODNAME=KBUILD_STR(ocfs2_dlm) -c -o fs/ocfs2/dlm/.tmp_dlmdomain.o
fs/ocfs2/dlm/dlmdomain.c
The related issue:
fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler':
fs/ocfs2/dlm/dlmdomain.c:941:1: error: insn does not satisfy its constraints:
}
^
(insn 334 716 335 29 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 3 [0x3])) [0 %sfp+-17 S1 A8]))
(const_int 1 [0x1])
(and:SI (reg:SI 1 r1 [+-3 ])
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) fs/ocfs2/dlm/dlmdomain.c:899 113 {*tstsi_variable_bit_qi}
(nil))
fs/ocfs2/dlm/dlmdomain.c:941:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
0x8e0a95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0/gcc/rtl-error.c:109
0x8e0abf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0/gcc/rtl-error.c:120
0x89be7b reload_cse_simplify_operands
../../gcc-4.9.0/gcc/postreload.c:411
0x89da9c reload_cse_simplify
../../gcc-4.9.0/gcc/postreload.c:181
0x89da9c reload_cse_regs_1
../../gcc-4.9.0/gcc/postreload.c:220
0x89deab reload_cse_regs
../../gcc-4.9.0/gcc/postreload.c:68
0x89deab rest_of_handle_postreload
../../gcc-4.9.0/gcc/postreload.c:2332
0x89deab execute
../../gcc-4.9.0/gcc/postreload.c:2368
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.
make[3]: *** [fs/ocfs2/dlm/dlmdomain.o] Error 1
make[2]: *** [fs/ocfs2/dlm] Error 2
make[1]: *** [fs/ocfs2] Error 2
make: *** [fs] Error 2
The gcc information:
[root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.9.0/lto-wrapper
Target: h8300-gchen-elf
Configured with: ../gcc-4.9.0/configure --without-header --disable-nls
--enable-language=c,c++ --disable-threads --disable-shared --enable-werror=no
target_configargs=enable_vtable_verify=yes --target=h8300-gchen-elf
Thread model: single
gcc version 4.9.0 20130910 (experimental) (GCC)
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #1 from Chen Gang gang.chen at asianux dot com --- If no '-Os', it will have no issue. This bug may duplicate with Bug58400, but I am not quite sure, so send a new bug for it.
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401
--- Comment #2 from Chen Gang gang.chen at asianux dot com ---
Alos for fs/ocfs2/dlm/dlmrecovery.c
/usr/local/bin/h8300-gchen-elf-gcc -Wp,-MD,fs/ocfs2/dlm/.dlmrecovery.o.d
-nostdinc -isystem /usr/local/lib/gcc/h8300-gchen-elf/4.9.0/include
-I/root/linux-next/arch/h8300/include -Iarch/h8300/include/generated -Iinclude
-I/root/linux-next/arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi
-I/root/linux-next/include/uapi -Iinclude/generated/uapi -include
/root/linux-next/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized -mh -mint32
-fno-builtin -g -D__linux__ -DUTS_SYSNAME=\uClinux\ -fno-reorder-blocks
-fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g
-femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -Ifs/ocfs2 -DMODULE
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(dlmrecovery)
-DKBUILD_MODNAME=KBUILD_STR(ocfs2_dlm) -c -o fs/ocfs2/dlm/.tmp_dlmrecovery.o
fs/ocfs2/dlm/dlmrecovery.c
fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_begin_reco_handler':
fs/ocfs2/dlm/dlmrecovery.c:2769:1: error: insn does not satisfy its
constraints:
}
^
(insn 588 587 589 40 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 7 sp)
(const_int 4 [0x4])) [0 %sfp+-8 S1 A32]))
(const_int 1 [0x1])
(and:SI (reg:SI 3 r3 [orig:125 D.60588+-3 ] [125])
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) fs/ocfs2/dlm/dlmrecovery.c:2748 113 {*tstsi_variable_bit_qi}
(nil))
fs/ocfs2/dlm/dlmrecovery.c:2769:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:411
0x8e0a95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0/gcc/rtl-error.c:109
0x8e0abf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0/gcc/rtl-error.c:120
0x89be7b reload_cse_simplify_operands
../../gcc-4.9.0/gcc/postreload.c:411
0x89da9c reload_cse_simplify
../../gcc-4.9.0/gcc/postreload.c:181
0x89da9c reload_cse_regs_1
../../gcc-4.9.0/gcc/postreload.c:220
0x89deab reload_cse_regs
../../gcc-4.9.0/gcc/postreload.c:68
0x89deab rest_of_handle_postreload
../../gcc-4.9.0/gcc/postreload.c:2332
0x89deab execute
../../gcc-4.9.0/gcc/postreload.c:2368
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.
make[3]: *** [fs/ocfs2/dlm/dlmrecovery.o] Error 1
make[2]: *** [fs/ocfs2/dlm] Error 2
make[1]: *** [fs/ocfs2] Error 2
make: *** [fs] Error 2
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- It has too many same issues (maybe they are duplicating), if necessary, I will list them too (non-reply means not need list them).
[Bug c/58256] New: gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
Bug ID: 58256
Summary: gcc for h8300 internal compiler error: in
maybe_record_trace_start
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
[root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.9.0/lto-wrapper
Target: h8300-gchen-elf
Configured with: ../gcc-4.9.0/configure --target=h8300-gchen-elf
--without-header --disable-nls --enable-language=c --disable-threads
--disable-shared --enable-werror=no
Thread model: single
gcc version 4.9.0 20130827 (experimental) (GCC)
In file included from include/linux/thread_info.h:11:0,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:4,
from include/linux/slab.h:12,
from fs/namei.c:20:
fs/namei.c: In function 'SyS_mknodat':
include/linux/bug.h:33:45: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2217
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/syscalls.h:104:31: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
#define __SC_TEST(t, a) (void)BUILD_BUG_ON_ZERO(!__TYPE_IS_LL(t) sizeof(t)
sizeof(long))
^
include/linux/syscalls.h:91:23: note: in expansion of macro '__SC_TEST'
#define __MAP1(m,t,a) m(t,a)
^
include/linux/syscalls.h:92:35: note: in expansion of macro '__MAP1'
#define __MAP2(m,t,a,...) m(t,a), __MAP1(m,__VA_ARGS__)
^
include/linux/syscalls.h:93:35: note: in expansion of macro '__MAP2'
#define __MAP3(m,t,a,...) m(t,a), __MAP2(m,__VA_ARGS__)
^
include/linux/syscalls.h:94:35: note: in expansion of macro '__MAP3'
#define __MAP4(m,t,a,...) m(t,a), __MAP3(m,__VA_ARGS__)
^
include/linux/syscalls.h:97:22: note: in expansion of macro '__MAP4'
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
^
include/linux/syscalls.h:194:3: note: in expansion of macro '__MAP'
__MAP(x,__SC_TEST,__VA_ARGS__);\
^
include/linux/syscalls.h:183:2: note: in expansion of macro '__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:177:36: note: in expansion of macro 'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
^
fs/namei.c:3209:1: note: in expansion of macro 'SYSCALL_DEFINE4'
SYSCALL_DEFINE4(mknodat, int, dfd, const char __user *, filename, umode_t,
mode,
^
0x68949a maybe_record_trace_start
../../gcc-4.9.0/gcc/dwarf2cfi.c:2217
0x689739 create_trace_edges
../../gcc-4.9.0/gcc/dwarf2cfi.c:2309
0x68981c scan_trace
../../gcc-4.9.0/gcc/dwarf2cfi.c:2522
0x68a29e create_cfi_notes
../../gcc-4.9.0/gcc/dwarf2cfi.c:2548
0x68a29e execute_dwarf2_frame
../../gcc-4.9.0/gcc/dwarf2cfi.c:2903
0x68a29e execute
../../gcc-4.9.0/gcc/dwarf2cfi.c:3399
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.
make[1]: *** [fs/namei.o] Error 1
make: *** [fs] Error 2
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #7 from Chen Gang gang.chen at asianux dot com --- (In reply to Manuel López-Ibáñez from comment #6) The infamous PR18501 *** This bug has been marked as a duplicate of bug 18501 *** Thanks.
[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #64 from Chen Gang gang.chen at asianux dot com --- (In reply to Manuel López-Ibáñez) Firstly, thank you very much for keeping tracing this bug almost 10 years, and provided your suggestions as much as possible. What you have done is valuable to developers (at least to me); at least the developers can easily and quickly know about this gcc common issue in time, and they will notice about it and think another ways to process this issue in their own projects (e.g. firstly compile with -O0 to see warnings). And sorry for I am not quite familiar with gcc compilier implementation, so at least now, I can not fix this issue, although of cause this issue really can be fixed (just as what you said). Thanks again.
[Bug c/57856] New: for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856
Bug ID: 57856
Summary: for an uninitialized variable, gcc assumes it already
has value instead of report uninitialized warnings.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
Created attachment 30477
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30477action=edit
Related disassemble code.
For Linux kernel source code mm/vmscan.c, function putback_lru_page(),
version is next-20130621.
Gcc assumes lru == LRU_UNEVICTABLE instead of report warnings (uninitializing
lru).
I got gcc source code from svn, configure make make install.
[root@gchenlinux linux-next]# which gcc
/usr/local/bin/gcc
[root@gchenlinux linux-next]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.9.0 20130704 (experimental) (GCC)
The related source code:
580 void putback_lru_page(struct page *page)
581 {
582 int lru;
583 int was_unevictable = PageUnevictable(page);
584
585 VM_BUG_ON(PageLRU(page));
586
587 redo:
588 ClearPageUnevictable(page);
589
590 if (page_evictable(page)) {
591 /*
592 * For evictable pages, we can use the cache.
593 * In event of a race, worst case is we end up with an
594 * unevictable page on [in]active list.
595 * We know how to handle that.
596 */
597 lru_cache_add(page);
598 } else {
599 /*
600 * Put unevictable pages directly on zone's unevictable
601 * list.
602 */
603 lru = LRU_UNEVICTABLE;
604 add_page_to_unevictable_list(page);
605 /*
606 * When racing with an mlock or AS_UNEVICTABLE clearing
607 * (page is unlocked) make sure that if the other thread
608 * does not observe our setting of PG_lru and fails
609 * isolation/check_move_unevictable_pages,
610 * we see PG_mlocked/AS_UNEVICTABLE cleared below and move
611 * the page back to the evictable list.
612 *
613 * The other side is TestClearPageMlocked() or
shmem_lock().
614 */
615 smp_mb();
616 }
617
618 /*
619 * page's status can change while we move it among lru. If an
evictable
620 * page is on unevictable list, it never be freed. To avoid that,
621 * check after we added it to the list, again.
622 */
623 if (lru == LRU_UNEVICTABLE page_evictable(page)) {
624 if (!isolate_lru_page(page)) {
625 put_page(page);
626 goto redo;
627 }
628 /* This means someone else dropped this page from LRU
629 * So, it will be freed or putback to LRU again. There is
630 * nothing to do here.
631 */
632 }
633
634 if (was_unevictable lru != LRU_UNEVICTABLE)
635 count_vm_event(UNEVICTABLE_PGRESCUED);
636 else if (!was_unevictable lru == LRU_UNEVICTABLE)
637 count_vm_event(UNEVICTABLE_PGCULLED);
638
639 put_page(page); /* drop ref from isolate */
640 }
/*
* Related disassemble code:
* make defconfig under x86_64 PC.
* make menuconfig (choose Automount devtmpfs at /dev... and KGDB)
* make V=1 EXTRA_CFLAGS=-W (not find related warnings, ref warn.log in
attachment)
* objdump -d vmlinux vmlinux.S
* vi vmlinux.S
*
* The issue is: compiler assumes lru == LRU_UNEVICTABLE instead of report
warnings (uninitializing lru)
*/
810f3d20 putback_lru_page:
810f3d20: 55 push %rbp
810f3d21: 48 89 e5mov%rsp,%rbp
810f3d24: 41 55 push %r13
810f3d26: 41 54 push %r12
810f3d28: 4c 8d 67 02 lea0x2(%rdi),%r12 ; for
ClearPageUnevictable(page);
810f3d2c: 53 push %rbx
810f3d2d: 4c 8b 2fmov(%rdi),%r13 ;
was_unevictable = PageUnevictable(page);
810f3d30: 48 89 fbmov%rdi,%rbx
810f3d33: 49 c1 ed 14 shr$0x14,%r13
810f3d37: 41 83 e5 01 and$0x1,%r13d
810f3d3b: eb 28
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 Chen Gang gang.chen at asianux dot com changed: What|Removed |Added CC||gang.chen at asianux dot com --- Comment #2 from Chen Gang gang.chen at asianux dot com --- Created attachment 30478 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30478action=edit Compiling command(use red hat 4.7.2 as a demo), it's same for gcc 4.9.0 compiling from source code.
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #3 from Chen Gang gang.chen at asianux dot com --- Created attachment 30479 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30479action=edit The related warnings, not find uninitailized warning for lru.
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #4 from Chen Gang gang.chen at asianux dot com --- Created attachment 30480 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30480action=edit This attachment is for gcc 4.9.0 from compiling source code (sorry, the original disassembly code is for red hat 4.7.2)
[Bug middle-end/57856] for an uninitialized variable, gcc assumes it already has value instead of report uninitialized warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57856 --- Comment #5 from Chen Gang gang.chen at asianux dot com --- (In reply to Andrew Pinski from comment #1) I think this is a dup of another bug. Firstly, thank you reply as soon as possible. Could you provide the related Bug number ? Thanks.
