This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi! Attached are two alternative patches to fix PR19192. The problem there is when expanding a SSA_NAME, we don't switch to the def_stmt's gimple_location and gimple_block, so everything is emitted in the scope and with location of the currently expanded stmt. After we are done with the def_stmt expansion, we should switch back the previous location/block, as further instructions emitted aren't from the def_stmt, but from the current stmt. The first version is probably slightly more riskier, as it affects more places (expand_expr/expand_normal/expand_expr_real is called in lots of places and it now newly restores the original block and location before the call). Both patches have been bootstrapped/regtested on x86_64-linux and i686-linux, both just caused a regression in dwarf2/inline2.c (that's why it is included in the patch too). The difference between unpatched and patched gcc is in locations (and as none of the third routine locations are current locations of any insns after the patch, its DW_TAG_inlined_subroutine/DW_TAG_lexical_block vanishes too): - # inline2.c:45 - .loc 1 45 0 + # inline2.c:52 + .loc 1 52 0 movl 8(%ebp), %eax addl $1, %eax movl %eax, 0 -.LBE15: -.LBE14: # inline2.c:53 Both of the locations are somewhat right and somewhat wrong. The addition is inline2.c:52, while the actual store is inline2.c:45, so best would be: # inline2.c:45 .loc 1 45 0 movl 8(%ebp), %eax addl $1, %eax # inline2.c:52 .loc 1 52 0 movl %eax, 0 # inline2.c:53 The reason for this is that the store is expanded by setting target to (mem:SI (reg)) and then expanding the PLUS_EXPR with that target. Without the patch, we don't switch expansion for the PLUS_EXPR recursion, with the patch the PLUS_EXPR expansion is done with inline2.c:52. But as target argument is passed, already the PLUS_EXPR expansion stores the result into target and returns target - thus for the inline2.c:45 location there is no code to be emitted. Not sure what exactly would be needed to make this more exact. The new testcase fails on i686-linux at -O1 and above, due to a separate issue for which I'm going to submit a patch once I bootstrap/regtest it. Ok for trunk? Which version? Jakub
Attachment:
Y608
Description: Text document
Attachment:
Y608y
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |