This is the mail archive of the gcc-bugs@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]

[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu



------- Comment #2 from zadeck at naturalbridge dot com  2007-06-30 02:05 -------
Index Nav:       [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:    [Date Prev] [Date Next]         [Thread Prev] [Thread Next]
Other format:   [Raw text]
Re: Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h

    * From: Jim Wilson <wilson at specifix dot com>
    * To: "Seongbae Park (&#48149;&#49457;&#48176;, &#26420;&#25104;&#22521;)"
<seongbae dot park at gmail dot com>
    * Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Maxim Kuvyrkov
<mkuvyrkov at ispras dot ru>
    * Date: Fri, 29 Jun 2007 14:46:55 -0700
    * Subject: Re: Fwd: INCOMING_RETURN_ADDR_RTX in ia64.h
    * References: <ab3a61990706180044w7f892d93qc6c210e5530be35@mail.gmail.com>
<ab3a61990706181307s14428f4am6e9ef73684289088@mail.gmail.com>

Seongbae Park (&#48149;&#49457;&#48176;, &#26420;&#25104;&#22521;) wrote:
> 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.

The problem here is that defining INCOMING_RETURN_ADDR_RTX automatically
enables the DWARF2_UNWIND_INFO support.  See defaults.h which does:

/* If we have a definition of INCOMING_RETURN_ADDR_RTX, assume that
   the rest of the DWARF 2 frame unwind support is also provided.  */
#if !defined (DWARF2_UNWIND_INFO) && defined (INCOMING_RETURN_ADDR_RTX)
#define DWARF2_UNWIND_INFO 1
#endif

The DWARF2_UNWIND_INFO support happens not to work on IA-64 for various
reasons.  This doesn't matter, as IA-64 has its own unwind info format
that we use instead of the DWARF2 info, as required by the ABI.
Emitting DWARF2 unwind info would just bloat the object files
unnecessarily.  Since we didn't need INCOMING_RETURN_ADDR_RTX for other
reasons, and because we don't want gcc to emit the DWARF2 unwind info,
the simple solution was just to not define INCOMING_RETURN_ADDR_RTX.

Since the dataflow stuff now needs INCOMING_RETURN_ADDR_RTX, I think the
right solution is to uncouple DWARF2_UNWIND_INFO and
INCOMING_RETURN_ADDR_RTX so that we can have the latter without the former.

The first easy step is to put
#define DWARF2_UNWIND_INFO 0
in the config/ia64/ia64.h file.

The second harder step is to fix everyplace in the compiler that uses
DWARF2_UNWIND_INFO to check its value instead of just checking to see if
it is defined.  So for instance, in final.c, instead of
#if defined (DWARF2_UNWIND_INFO)
      if (dwarf2out_do_frame ())
        dwarf2out_frame_debug (insn, false);
#endif
we would have
#if defined (DWARF2_UNWIND_INFO)
      if (DWARF2_UNWIND_INFO && dwarf2out_do_frame ())
        dwarf2out_frame_debug (insn, false);
#endif
or something like that.

There are some things we can't avoid though.  There are a lot of
functions in dwarf2out.c that get included in cc1 when
DWARF2_UNWIND_INFO is defined, and these will now be included in the
IA-64 cc1 even though they will never be called, which is unfortunate.

An alternative solution would be to delete the 3 lines of code in
defaults.h that set DWARF2_UNWIND_INFO when INCOMING_RETURN_ADDR_RTX is
defined, then add a definition of DWARF2_UNWIND_INFO to all targets that
need it.  This is a better solution from an IA-64 point of view, since
it presents us from defining a lot of functions we don't need or want.
Unfortunately, finding and fixing all target header files that now need
to define DWARF2_UNWIND_INFO will be error prone.  Unless maybe we just
assume that all targets except IA-64 should define it, which is easy
enough.  I would not be able to test such a patch though, as I do not
have access to all targets that would be modified.

Yet another solution would be to add another macro
INCOMING_RETURN_ADDR_RTX_2 which acts like INCOMING_RETURN_ADDR_RTX,
except that it doesn't enable the unwanted and undesirable
DWARF2_UNWIND_INFO as a side-effect.  Not very elegant, but it would be
a simpler change.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]