Internal compiler error in expand_end_loop, at stmt.c:2563

[Jan Hubicka]

> On Thu, 20 Sep 2001, Jan Hubicka wrote:
> >> Jan, my gutt and the ChangeLog indicate that this is "yours":
> >>
> >>   % gccvs check.ii -O3
> >>   check.C: In constructor `SIMPLE_SAT::SIMPLE_SAT(const std::vector<MC_RULE,
> >>      std::allocator<MC_RULE> >&, const GATOMSET&)':
> >>   check.C:473: Internal compiler error in expand_end_loop, at stmt.c:2563
> >>
> >> Seen on i386-unknown-freebsd4.3 since two, three days; check.ii.bz2 is
> >> attached.
> > I've finally got to reproduce the problem.  There appears to be problem with
> > inlining function that already has inpaired notes.
> > I am not quite sure how that can happen and if my insn emitting changes had
> > introduced it.
> 
> I'm rather sure this was triggered (even if not necessarily directly
> caused) by your patches, and the bug is still here. If have attached a
> preprocessed source file generated using today's CVS sources on a Debian
> GNU/Linux i686 box.
Hi,
I've spent about another 4 hours hunting this bug.  It appears to be in
the C++ frontend, so I am CCing everyone who made changes to the frontend
around the date.

I've tracked down the problem to be in exception region too early closed,
so it's REGION_END note appears in the middle of loop.
This is caused by CTOR_STMT expanding (with BEGIN set to 0), that is
aparently inpaired with CTOR_STMT with BEGIN set to 1.  This appears
to come from the code:
  if (DECL_CONSTRUCTOR_P (current_function_decl))
    {
      if (processing_template_decl)
        add_stmt (build_min_nt
                  (CTOR_INITIALIZER,
                   member_init_list, base_init_list));
      else
        {
          tree ctor_stmt;

          /* Mark the beginning of the constructor.  */
          ctor_stmt = build_stmt (CTOR_STMT);
          CTOR_BEGIN_P (ctor_stmt) = 1;
          add_stmt (ctor_stmt);

          /* And actually initialize the base-classes and members.  */
          emit_base_init (member_init_list, base_init_list);
        }
    }
  else if (DECL_DESTRUCTOR_P (current_function_decl)

that does not generate the CTOR_STMT when processing_template_decl is set
(and this is the case).  If I hack the corresponding finish_constructor_body
to not emit CTOR_STMT if the flag is set, the crash goes away, but it is
most probably not proper fix.

I have no cluse what is CTOR_INITIALIZER used for (there is no documentation
eighter in tree.def now c-tree.texi), so probably someone with more 
C++ frontend knowledge needs to help me.
Please!

Honza