Bug 63315 - -fcompare-debug bootstrap issue in libjava (fixup_abnormal_edges related)
Summary: -fcompare-debug bootstrap issue in libjava (fixup_abnormal_edges related)
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compare-debug-failure
Depends on:
Blocks:
 
Reported: 2014-09-19 19:46 UTC by Jakub Jelinek
Modified: 2022-01-18 23:04 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2014-09-19 19:46:19 UTC
In x86_64-linux trunk:
 ../configure --enable-languages=all,obj-c++,lto,go --disable-libcilkrts
 --enable-checking=release; GCC_COMPARE_DEBUG=1 make -j48 bootstrap > LOG 2>&1
 && GCC_COMPARE_DEBUG=1 make -j48 -k check > LOGC 2>&1; ../contrib/test_summary
 > LOGT 2>&1
bootstrap I'm seeing:
gcj: error: /tmp/ccb0xB2Sjx: -fcompare-debug failure (length)
make[3]: *** [gnu-xml-util.lo] Error 1
/usr/src/gcc/obj086/./gcc/gcj -B/usr/src/gcc/obj086/x86_64-unknown-linux-gnu/libjava/ -B/usr/src/gcc/obj086/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include    -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fsource-filename=/usr/src/gcc/obj086/x86_64-unknown-linux-gnu/libjava/classpath/lib/classes -fjni -findirect-dispatch -fno-indirect-classes -c -o gnu-xml-util.lo @gnu-xml-util.list -fcompare-debug --param min-nondebug-insn-uid=10000
fails, with:
--- ccn5lLfzjx.gk.gkd   2014-09-19 17:40:51.443440651 +0200
+++ ccn5lLfzjx.gkd      2014-09-19 17:40:47.340440895 +0200
@@ -77215,6 +77215,7 @@ Declarations used by gnu.xml.util.XCat$C
 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
 (note # 0 0 NOTE_INSN_FUNCTION_BEG)
+(note # 0 0 NOTE_INSN_DELETED)
 (insn/f:TI # 0 0 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [  S8 A8])
         (reg:DI 44 r15)) /usr/src/gcc/libjava/classpath/gnu/xml/util/XCat.java:971# {*pushdi2_rex64}
      (expr_list:REG_DEAD (reg:DI 44 r15)
difference.
Comment 1 Jakub Jelinek 2014-09-19 20:00:51 UTC
We have:
(insn 10025 3 10026 2 (set (reg:SI 85 [ D.39608 ])
        (mem/u/j:SI (const:DI (plus:DI (symbol_ref:DI ("_otable_gnu_xml_util_XCat$Catalog") [flags 0x2]  <var_decl 0x7ffff057c1b0
_otable_gnu_xml_util_XCat$Catalog>)  
                    (const_int 68 [0x44]))) [11 _otable_gnu_xml_util_XCat$Catalog+68 S4 A32]))
/usr/src/gcc/libjava/classpath/gnu/xml/util/XCat.java:971 90 {*movsi_internal}
     (expr_list:REG_EQUIV (mem/u/j:SI (const:DI (plus:DI (symbol_ref:DI
("_otable_gnu_xml_util_XCat$Catalog") [flags 0x2]  <var_decl 0x7ffff057c1b0 _otable_gnu_xml_util_XCat$Catalog>)
                    (const_int 68 [0x44]))) [11 _otable_gnu_xml_util_XCat$Catalog+68 S4 A32])
        (expr_list:REG_EH_REGION (const_int 1 [0x1])
            (nil))))
instruction that is at the end of bb2 and due to -fnon-call-exceptions marked as possibly throwing, then LRA comes and removes this insn for whatever reason (haven't looked), by turning it into NOTE_INSN_DELETED.  This insn is preceeded by some debug insns (for -g) and before that a CALL_INSN (supposedly non-throwing one, because it didn't terminate a bb before).
Then lra calls fixup_abnormal_edges, which for -g0 removes the NOTE_INSN_DELETED (for some strange reason considers the CALL_INSN, even when it can't throw, as the spot which has to end the bb) and in theory would delete any other non-throwing insns after the CALL_INSN.  But for -g, there is a DEBUG_INSN which it stops on.

So, either the bug is in LRA that it removed a possibly throwing insn, or that it hasn't updated outgoing edges of the bb when removing possibly throwing insn at the end.  Or it is in fixup_abnormal_edges, because it shouldn't consider CALL_INSNs that can't throw.  Or what fixup_abnormal_edges does is fine in the -g0 case and we should ignore DEBUG_INSNs during analysis and then throw them away or something.  Thoughts on this?
Comment 2 Andrew Pinski 2016-09-17 05:11:13 UTC
Does this work now>
Comment 3 Andrew Pinski 2021-08-27 06:14:45 UTC
So I looked and I suspect in the end was the same issue as PR 69838.

I have no way to prove this though.