Created attachment 25114 [details] reduced testcase Compiler output: $ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -O3 -gdwarf-2 -fno-tree-sink --param max-vartrack-expr-depth=140 testcase.c testcase.c:29:1: internal compiler error: in output_loc_list, at dwarf2out.c:8188 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. (gdb) bt #0 fancy_abort (file=0x125e160 "/mnt/svn/gcc-trunk/gcc/dwarf2out.c", line=8188, function=0x1266840 "output_loc_list") at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892 #1 0x00000000006f3e0c in output_loc_list (die=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:8188 #2 output_location_lists (die=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7514 #3 0x00000000006f3bd1 in output_location_lists (die=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7516 #4 0x00000000006f3bd1 in output_location_lists (die=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7516 #5 0x00000000006f3bd1 in output_location_lists (die=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:7516 #6 0x0000000000714457 in dwarf2out_finish (filename=Unhandled dwarf expression opcode 0xf3 ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:22620 #7 0x00000000009dc3ce in compile_file (argc=18, argv=0x7fffffffda88) at /mnt/svn/gcc-trunk/gcc/toplev.c:597 #8 do_compile (argc=18, argv=0x7fffffffda88) at /mnt/svn/gcc-trunk/gcc/toplev.c:1886 #9 toplev_main (argc=18, argv=0x7fffffffda88) at /mnt/svn/gcc-trunk/gcc/toplev.c:1962 #10 0x00007ffff6192d2d in __libc_start_main () from /lib64/libc.so.6 #11 0x000000000055a609 in _start () Tested revisions: r178096 - crash
DWARF has a fixed limit for the size of expression in .debug_loc - 64KB, so with insane high parameters you can trigger it.
Shouldn't we limit the max of the param then?
But what would be a good limit for the parameter? On some targets some people have managed to trigger it even with the parameter 20 which has been the default for a while, but on other code/targets even a few hundred is fine. As I wrote on gcc-patches I think, what we could do is just drop the expression on the floor instead of asserting if it is >= 64KB, or we could stick it into a DW_TAG_dwarf_procedure (though, I think >= 64KB location expressions ought to be rarely useful).
(In reply to comment #3) > But what would be a good limit for the parameter? On some targets some people > have managed to trigger it even with the parameter 20 which has been the > default for a while, but on other code/targets even a few hundred is fine. > As I wrote on gcc-patches I think, what we could do is just drop the expression > on the floor instead of asserting if it is >= 64KB, or we could stick it into a > DW_TAG_dwarf_procedure (though, I think >= 64KB location expressions ought to > be rarely useful). I suppose we can't know in advance and turn the max-vartrack-expr-depth param into a max-dwarf2-expr-size param? That we could limit to 64kb ...
This is basically a dup of bug 51695 because that is also a >= 64KB expression. *** This bug has been marked as a duplicate of bug 51695 ***