------- Comment #1 from spark at gcc dot gnu dot org 2007-06-29 21:41 ------- Below is the email I sent to Jim Wilson asking for help with the analysis of the bug.
-------- Hi Jim, This is an analysis of a correctness bug on ia64, which root cause has to do with your code. After dataflow merge, Richard Guenther reported two runtime failures in SPEC CPU2000 programs on ia64. It turned out to be related to the following code you wrote (or at least committed, according to svn). From ia64.h: 928 /* A C expression whose value is RTL representing the location of the incoming 929 return address at the beginning of any function, before the prologue. This 930 RTL is either a `REG', indicating that the return value is saved in `REG', 931 or a `MEM' representing a location in the stack. This enables DWARF2 932 unwind info for C++ EH. */ 933 #define INCOMING_RETURN_ADDR_RTX gen_rtx_REG (VOIDmode, BR_REG (0)) 934 935 /* ??? This is not defined because of three problems. 936 1) dwarf2out.c assumes that DWARF_FRAME_RETURN_COLUMN fits in one byte. 937 The default value is FIRST_PSEUDO_REGISTER which doesn't. This can be 938 worked around by setting PC_REGNUM to FR_REG (0) which is an otherwise 939 unused register number. 940 2) dwarf2out_frame_debug core dumps while processing prologue insns. We 941 need to refine which insns have RTX_FRAME_RELATED_P set and which don't. 942 3) It isn't possible to turn off EH frame info by defining DWARF2_UNIND_INFO 943 to zero, despite what the documentation implies, because it is tested in 944 a few places with #ifdef instead of #if. */ 945 #undef INCOMING_RETURN_ADDR_RTX Here, because INCOMING_RETURN_ADDR_RTX is ultimately undef'ed, dataflow doesn't see any definition of the return address register, and happily treats b0 as not live throughout the function body. Then, global allocator, guided by this information, allocates b0 for something else - leading to the return address corruption. Removing the undef leads to an ICE in dwarf2out.c (probably due to 2 in your comment ?). Certainly from the new dataflow point of view, we need this macro to be defined, because, otherwise, the use of b0 in the return is considered a use without def. Previously, flow() didn't consider uninitialized registers and just having a use of b0 in the return was sufficient, as it made b0 live across the entire function thanks to flow's backward only live analysis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
