Created attachment 45308 [details] generated sv_init.i 1) The exact version of GCC: $ gcc --version gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2) The system type: x86_64-linux-gnu. On Ubuntu 18.10. Also happens on Arch Linux with GCC 8.2.1. 3) the options given when GCC was configured/built; See attachment. 4) the complete command line that triggers the bug /usr/bin/cc -DCOLORIZE_CONSOLE -DSINGLE_BINARY -DUSE_SELECT -DVECTORIZE_SINCOS -DXASH_BUILD_COMMIT=\"b5b493b1\" -DXASH_DEDICATED -DXASH_FASTSTR -DXASH_FORCEINLINE -DXASH_USE_STB_SPRINTF -I/home/a1ba/projects/xash/xash3d/engine/. -I/home/a1ba/projects/xash/xash3d/engine/common -I/home/a1ba/projects/xash/xash3d/engine/common/imagelib -I/home/a1ba/projects/xash/xash3d/engine/common/soundlib -I/home/a1ba/projects/xash/xash3d/engine/client -I/home/a1ba/projects/xash/xash3d/engine/client/vgui -I/home/a1ba/projects/xash/xash3d/engine/server -I/home/a1ba/projects/xash/xash3d/engine/../common -I/home/a1ba/projects/xash/xash3d/engine/../pm_shared -m32 -save-temps -g -O2 -fvisibility=hidden -o CMakeFiles/xash.dir/server/sv_init.c.o -c /home/a1ba/projects/xash/xash3d/engine/server/sv_init.c or in case of just sv_init.i gcc -m32 -save-temps -g -O2 -fvisibility=hidden -o sv_init.o sv_init.i 5) the compiler output (error messages, warnings, etc.) sv_init.s: Assembler messages: sv_init.s:31551: Error: can't resolve `L0' {*ABS* section} - `.LC28' {.rodata.str1.1 section} 6) the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command See attachment. I tried to compile without -O2, -g or -m32 and it seems only this combination makes assembler to fail.
Started with r256580. Got fixed or went latent with r265677 on the trunk. Reduced testcase with -m32 -dA -g -O2 -fpie -fvisibility=hidden: void foo (char *b) { unsigned c = 0; --c; do if (++*b++ == 0) break; while (--c); if (c == 0) while (*b++) ; } void bar (void) { foo (""); }
must really be latent before/after the revs. I see .value 0xf # Location expression size .byte 0x3 # DW_OP_addr .long .LC0 .byte 0x72 # DW_OP_breg2 .sleb128 0 .byte 0x1c # DW_OP_minus .byte 0x3 # DW_OP_addr .long -2-.LC0@gotoff .byte 0x22 # DW_OP_plus .byte 0x9f # DW_OP_stack_value in debug_loc. To me looks like a missed expression simplification and failure to reject this "constant". Note that .long .LC0@gotoff+2 works, so doing that and DW_OP_negate (if exists) might work. Of course the @gotoff looks odd to me given the non-@gotoff reference to .LC0 above.
Of course it is latent before/after. In const_ok_for_output_1 we have /* FIXME: Refer to PR60655. It is possible for simplification of rtl expressions in var tracking to produce such expressions. We should really identify / validate expressions enclosed in CONST that can be handled by assemblers on various targets and only handle legitimate cases here. */ switch (GET_CODE (rtl)) { case SYMBOL_REF: break; case NOT: case NEG: return false; default: return true; } that catches some problematic cases, but in this case the simplification created (const (minus (const_int -2) (unspec ...))) and that makes the unspec negated too. So, we could e.g. add a case to the above switch that case MINUS: if there are any UNSPECs in subexpressions of the second operand, punt. Of course, if we want to try harder, we could try to negate the expression and see if it is valid that way etc.
Created attachment 45321 [details] gcc9-pr88635.patch Untested fix.
Author: jakub Date: Sat Jan 5 11:12:35 2019 New Revision: 267594 URL: https://gcc.gnu.org/viewcvs?rev=267594&root=gcc&view=rev Log: PR debug/88635 * dwarf2out.c (const_ok_for_output_1): Reject MINUS that contains SYMBOL_REF, CODE_LABEL or UNSPEC in subexpressions of second argument. Reject PLUS that contains SYMBOL_REF, CODE_LABEL or UNSPEC in subexpressions of both operands. (mem_loc_descriptor): Handle UNSPEC if target hook acks it and all the subrtxes are CONSTANT_P. * config/i386/i386.c (ix86_const_not_ok_for_debug_p): Revert 2018-11-09 changes. * gcc.dg/debug/dwarf2/pr88635.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr88635.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
Author: jakub Date: Thu Feb 7 14:25:01 2019 New Revision: 268617 URL: https://gcc.gnu.org/viewcvs?rev=268617&root=gcc&view=rev Log: Backported from mainline 2019-01-07 Jakub Jelinek <jakub@redhat.com> PR debug/88723 * dwarf2out.c (const_ok_for_output_1): Remove redundant call to const_not_ok_for_debug_p target hook. (mem_loc_descriptor) <case UNSPEC>: Only call const_ok_for_output_1 on UNSPEC and subexpressions thereof if all subexpressions of the UNSPEC are CONSTANT_P. 2019-01-05 Jakub Jelinek <jakub@redhat.com> PR debug/88635 * dwarf2out.c (const_ok_for_output_1): Reject MINUS that contains SYMBOL_REF, CODE_LABEL or UNSPEC in subexpressions of second argument. Reject PLUS that contains SYMBOL_REF, CODE_LABEL or UNSPEC in subexpressions of both operands. (mem_loc_descriptor): Handle UNSPEC if target hook acks it and all the subrtxes are CONSTANT_P. * gcc.dg/debug/dwarf2/pr88635.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/debug/dwarf2/pr88635.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/dwarf2out.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
Fixed for 8.3+ too.