1 msgThe Linux binutils 2.17.50.0.17 is released

Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h
\ Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) (18 Jun 2007)
. \ Jim Wilson (29 Jun 2007)

3 msgNew LTO branch ready
1 msgRequesting SVN write access (Was: [PATCH frv] F...
3 msgmissing symbols
1 msggcov / gcov-dump
5 msg[M16C] : 20 bit data access
10 msgSuffix for __float128 FP constants
21 msgActivate -mrecip with -ffast-math?
4 msgMore vectorizer testcases?
3 msginit-regs pass initializes virtual-stack-vars?
2 msgStatus of simulator targets after dataflow merge
3 msgPR other/32351 [Was: Re: GCC Status Report (200...
5 msgFixing m68hc11 reorg after dataflow merge
24 msgPTR-PLUS merge into the mainline
4 msgWhen EOL? Replacing GCJ by IcedTea, GCC by LLVM.
73 msgI'm sorry, but this is unacceptable (union memb...
1 msggcc-4.3-20070615 is now available
11 msgGCC Status Report (2007-06-15)
4 msgAccess to raw repositories
Subject:Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h
Group:Gcc
From:Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ)
Date:18 Jun 2007


Forwarding to gcc@, as this might be interesting to other people,
and I'd like to ask whoever working on ia64 to take this issue up.

Seongbae

---------- Forwarded message ----------
From: Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) <seongbae.park>
Date: Jun 18, 2007 12:44 AM
Subject: INCOMING_RETURN_ADDR_RTX in ia64.h
To: wilson
Cc: Kenneth Zadeck <zadeck>, "Berlin, Daniel"
<dberlin>, Ian Lance Taylor <iant>, Paolo
Bonzini <paolo.bonzini>, Richard Guenther
<rguenther>


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.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"


© 2004-2008 readlist.com