[tree-ssa] C++ regressions after merge

[tree-ssa] C++ regressions after merge

[Diego Novillo]

The latest merge has produced several C++ regressions that are
not present in mainline.  Many of the new failures seem to be
mismatched symbols:

/home/dnovillo/merge-tree-ssa/src/gcc/testsuite/g++.old-deja/g++.brendan/cvt3.C: In function `void foo(bar, bar*)':
/home/dnovillo/merge-tree-ssa/src/gcc/testsuite/g++.old-deja/g++.brendan/cvt3.C:47: error: no matching function for call to `nnyacc::assign(NDAMValueRefSLList*&, NDAMValueRefSLList*&)'
HV~C^H):524318: error: candidates are: static void nnyacc::assign(void*&, void*&)

We also seem to be munging locus information (the error message
shows garbage).  Another problem I found is that the gimplifier
is trying to put __cxa_throw on the RHS of assignments.  This
causes grief in the RTL expanders because __cxa_throw is of type
void.

There's a fair number of regressions (~170), but they all seem
more or less related.  The other front ends seem in good shape.

I could try and track these regressions down but I'm not very
familiar with C++ front end.  Would people object if I checked in
the merge anyway so that you can help me fix them?


Thanks.  Diego.

Re: [tree-ssa] C++ regressions after merge

[law]

In message <20030408141719.GA7371@tornado.toronto.redhat.com>, Diego Novillo wr
ites:
 >The latest merge has produced several C++ regressions that are
 >not present in mainline.  Many of the new failures seem to be
 >mismatched symbols:
 >
 >/home/dnovillo/merge-tree-ssa/src/gcc/testsuite/g++.old-deja/g++.brendan/cvt3
 >.C: In function `void foo(bar, bar*)':
 >/home/dnovillo/merge-tree-ssa/src/gcc/testsuite/g++.old-deja/g++.brendan/cvt3
 >.C:47: error: no matching function for call to `nnyacc::assign(NDAMValueRefSL
 >List*&, NDAMValueRefSLList*&)'
 >HV~C^H):524318: error: candidates are: static void nnyacc::assign(void*&, voi
 >d*&)
 >
 >We also seem to be munging locus information (the error message
 >shows garbage).  Another problem I found is that the gimplifier
 >is trying to put __cxa_throw on the RHS of assignments.  This
 >causes grief in the RTL expanders because __cxa_throw is of type
 >void.
 >
 >There's a fair number of regressions (~170), but they all seem
 >more or less related.  The other front ends seem in good shape.
 >
 >I could try and track these regressions down but I'm not very
 >familiar with C++ front end.  Would people object if I checked in
 >the merge anyway so that you can help me fix them?
I would object very strongly as it would make trying to track down the
existing C++ issues extremely difficult.  Please please please do not
check in the merge.

In fact, I would *strongly* recommend you track down the memory corruption
problems now before doing anything else.  


jeff

Re: [tree-ssa] C++ regressions after merge

[Diego Novillo]

On Tue, 2003-04-08 at 10:26, law@redhat.com wrote:

> I would object very strongly as it would make trying to track down the
> existing C++ issues extremely difficult.  Please please please do not
> check in the merge.
> 
Oops.  Too late ;)

OK, not a problem.  In that case, the diff for the merge can be found at

http://people.redhat.com/dnovillo/pub/20030408-tree-ssa-mainline-merge.diff.gz

If anyone has time, I'll appreciate help in fixing these problems.


Thanks.  Diego.

Re: [tree-ssa] C++ regressions after merge

[Diego Novillo]

On Tue, 08 Apr 2003, Diego Novillo wrote:

> On Tue, 2003-04-08 at 10:26, law@redhat.com wrote:
> 
> > I would object very strongly as it would make trying to track down the
> > existing C++ issues extremely difficult.  Please please please do not
> > check in the merge.
> > 
> Oops.  Too late ;)
> 
> OK, not a problem.  In that case, the diff for the merge can be found at
> 
> http://people.redhat.com/dnovillo/pub/20030408-tree-ssa-mainline-merge.diff.gz
> 
> If anyone has time, I'll appreciate help in fixing these problems.
> 
> Thanks.  Diego.
> 
Hmm, my message seems to have been confusing.  Just to clarify, I
did *not* check-in the merge.  I will only check it in after all
the regressions have been fixed.


Diego.

Re: [tree-ssa] C++ regressions after merge

[Steven Bosscher]

Op di 08-04-2003, om 16:51 schreef Diego Novillo:
> On Tue, 2003-04-08 at 10:26, law@redhat.com wrote:
> 
> > I would object very strongly as it would make trying to track down the
> > existing C++ issues extremely difficult.  Please please please do not
> > check in the merge.
> > 
> Oops.  Too late ;)
> 
> OK, not a problem.  In that case, the diff for the merge can be found at
> 
> http://people.redhat.com/dnovillo/pub/20030408-tree-ssa-mainline-merge.diff.gz
> 
> If anyone has time, I'll appreciate help in fixing these problems.

Dunno if you have commited the merge already, but I guess not since it
is not in the mailing lists.

I applied your patch, and found one problem in cp/call.c:

---------------------------
+  else if (TYPE_P (candidate->fn))
+    errfn ("%s %T <conversion>", msgid, candidate->fn);
+  else
+    errfn ("%H%s %+#D%s", &TREE_LOCUS (candidate->fn), msgid,
			   ^
+          candidate->fn, candidate->viable == -1 ? " <near match>" : "");
---------------------------

You should not have the ampersand there, TREE_LOCUS is a pointer
already. Removing it fixes the bogus file/line information you saw:

With ampersand:
test.cc:16: error: call of `(CLogger) (int, const char[5])' is ambiguous
8O:786462: error: candidates are: void CLogger::operator()(int, const char*)
8O:786462: error:                 void CLogger::operator()(int, const char*, 
   ...)

Without it:
test.cc:16: error: call of `(CLogger) (int, const char[5])' is ambiguous
test.cc:6: error: candidates are: void CLogger::operator()(int, const char*)
test.cc:7: error:                 void CLogger::operator()(int, const char*, 
   ...)

I'll rerun the test suite and see if it helps for all of 'em.

Greetz
Steven

Re: [tree-ssa] C++ regressions after merge

[Jason Merrill]

On Tue, 8 Apr 2003 10:17:19 -0400, Diego Novillo <dnovillo@redhat.com> wrote:

> Another problem I found is that the gimplifier is trying to put
> __cxa_throw on the RHS of assignments.  This causes grief in the RTL
> expanders because __cxa_throw is of type void.

This is probably due to code that looks like

  int i = ok ? 42 : throw FlamingDeath;

but this should have been caught by the code in simplify_cond_expr which
checks for void arms.

Jason

Re: [tree-ssa] C++ regressions after merge

[Diego Novillo]

On Thu, 10 Apr 2003, Jason Merrill wrote:

> On Tue, 8 Apr 2003 10:17:19 -0400, Diego Novillo <dnovillo@redhat.com> wrote:
> 
> > Another problem I found is that the gimplifier is trying to put
> > __cxa_throw on the RHS of assignments.  This causes grief in the RTL
> > expanders because __cxa_throw is of type void.
> 
> This is probably due to code that looks like
> 
>   int i = ok ? 42 : throw FlamingDeath;
> 
> but this should have been caught by the code in simplify_cond_expr which
> checks for void arms.
> 
Well, maybe.  The original source code is g++.dg/eh/cond1.C:23,
which once preprocessed looks like:

    try { (0 ? has_destructor() : throw 0); abort(); } catch (int) { };

which produces a CLEANUP_POINT_EXPR for the body of the try{}.
That cleanup expression contains a TARGET_EXPR with the call to
__cxa_throw somewhere in its body.

That TARGET_EXPR was created by cp/call.c:build_conditional_expr:

-----------------------------------------------------------------------------
#0  0x08051f68 in build_conditional_expr (arg1=0x403766a0, arg2=0x403b8a9c, arg3=0x403b8a9c) at /home/dnovillo/tree-ssa/src/gcc/cp/call.c:3510
#1  0x080f5daf in cp_parser_question_colon_clause (parser=0x403b8a9c, logical_or_expr=0x403b43f4) at /home/dnovillo/tree-ssa/src/gcc/cp/parser.c:5278
...
-----------------------------------------------------------------------------

The TARGET_EXPR looks like this:

(gdb) pt *expr_p
 <target_expr 0x403b43f4
    arg 0 <var_decl>
    arg 1 <throw_expr>
        arg 0 <compound_expr>
            arg 0 <compound_expr>
                arg 0 <target_expr>
                    arg 1 <call_expr>
                        side-effects nothrow
                        arg 0 <addr_expr>
                            constant arg 0 <function_decl __cxa_allocate_exception>>
                        arg 1 <tree_list value <integer_cst 4>>>>
                arg 1 <must_not_throw_expr type <void_type 0x40371c40 void>
                    arg 0 <init_expr type <integer_type int>
                        arg 0 <indirect_ref type <integer_type int>
                            arg 0 <nop_expr>>
                        arg 1 <integer_cst constant 0>>>>
            arg 1 <call_expr type <void_type void>
                arg 0 <addr_expr type <pointer_type>
                    constant arg 0 <function_decl __cxa_throw>>
                arg 1 <tree_list value <var_decl>
                    chain <tree_list
                        value <addr_expr type <pointer_type>
                            readonly arg 0 <var_decl _ZTIi>>
                        chain <tree_list value <integer_cst 0>>>>>>>
    arg 2 <call_expr type <void_type void>
        arg 0 <addr_expr type <pointer_type>
            arg 0 <function_decl __comp_dtor>>
        arg 1 <tree_list>

It is simplify_target_expr the one creating the MODIFY_EXPR with
the call to __cxa_throw on the RHS:

2318      /* TARGET_EXPR temps aren't part of the enclosing block, so add it to
the
2319         temps list.  */
2320      gimple_add_tmp_var (temp);
2321
2322      /* Build up the initialization and add it to pre_p.  */
2323      init = build (MODIFY_EXPR, void_type_node, temp, init);
2324      simplify_expr (&init, pre_p, post_p, is_simple_stmt, fb_none);
2325      add_tree (init, pre_p);
2326


This is as far as I could get.  AFAICS, simplify_cond_expr is
working fine.  It's simplify_target_expr the one munging things
up.


Diego.