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]

[PATCH] PR18683: Bad C++/cgraph/middle-end/rs6000 interaction (fix1)


PR middle-end/18683 is a critical ICE-on-valid regression in current
mainline affecting C++ on powerpc targets.  It is caused by an obscure
interaction between the rs6000 backend and the g++ front-end during
local register allocation.  The unfortunate sequence of events (described
in the bugzilla PR) causes reg_renumber to be reset to zero during
register allocation, which leads to a segmentation fault.

There are several possible ways to tackle this issue...

In the patch below, the solution is to avoid reseting reg_renumber in
pop_function_context_from.  My understanding is that as we don't try
to save the value of reg_renumber in push_function_context_to, we
shouldn't be changing it on leaving a function context.  My understanding
is that reg_renumber should be reset to zero at the beginning of
generating RTL for a function (in either init_function_for_compilation
*or* prepare_function_start, but probably not both as currently done),
this value then remains zero during the early RTL optimization passes,
and is assigned a value via allocate_reg_info during register allocation
and remains set for the rest of the function's RTL passes.  I also believe
that we should only be generating RTL for a single function at a time.

If the above assumptions are true, the routines push_function_context
and pop_function_context used by the front-ends should have no affect
on the RTL optimizers internal data structures.


In addition to this change, I'll also submit another change to the
rs6000 backend that is also sufficient to resolve the failure.  However
both of these fixes may possibly be papering over a more fundamental
problem in the interaction between g++ and cgraph; should we guarantee
that current_function_decl has an assembler name before generating RTL?


The following patch has been tested on both powerpc-unknown-linux-gnu
and i686-pc-linux-gnu with a full "make bootstrap", all default languages,
and regression tested with a top-level "make -k check" with no new
failures.  This patch is sufficient to fix the attached test case on
powerpc-unknown-linux-gnu.

Ok for mainline?



2004-12-20  Roger Sayle  <roger@eyesopen.com>

	PR middle-end/18683
	* function.c (pop_function_context_from): Don't reset reg_renumber.

	* g++.dg/opt/pr18683-1.C: New test case.


Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.593
diff -c -3 -p -r1.593 function.c
*** function.c	19 Dec 2004 04:42:09 -0000	1.593
--- function.c	19 Dec 2004 21:56:57 -0000
*************** pop_function_context_from (tree context
*** 286,292 ****
    outer_function_chain = p->outer;

    current_function_decl = p->decl;
-   reg_renumber = 0;

    lang_hooks.function.leave_nested (p);

--- 286,291 ----


// PR middle-end/18683
// { dg-do compile }
// { dg-options "-O0" }

template<typename _CharT>
struct basic_ostream
{
  basic_ostream& operator<<(int __n);
};

extern basic_ostream<char>  cout;

template<int> struct linear_congruential
{
  template<class CharT>
  friend basic_ostream<CharT>&
  operator<<(basic_ostream<CharT>& os,
             const linear_congruential& lcg)
  {
    return os << 1;
  }
};

void instantiate_all()
{
  linear_congruential<0> lcf;
  cout << lcf;
}


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833


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