Re: [PATCH][RFC] Gimplify unit-at-a-time (again)

[Richard Guenther <rguenther at suse dot de>]

On Fri, 17 Jul 2009, Richard Guenther wrote:

> On Thu, 16 Jul 2009, Jason Merrill wrote:
> 
> > On 07/06/2009 03:27 PM, Richard Guenther wrote:
> > > FAIL: g++.dg/warn/unused-result1.C  (test for warnings, line 9)
> > 
> > Hmm, I guess we don't get the warning because that function isn't reachable?
> > Should be fine to just add a call to the testcase, I suppose.
> 
> The test was added specifically for the case where there was no call to
> the inline function IIRC.  And yes, we drop the function before we
> get to the warning machinery - in the end moving it to work on GENERIC
> rather than GIMPLE would fix the issue.
> 
> > > FAIL: g++.dg/gomp/block-1.C (test for excess errors)
> > > FAIL: g++.dg/gomp/block-2.C (test for excess errors)
> > > FAIL: g++.dg/gomp/block-3.C (test for excess errors)
> > > FAIL: g++.dg/gomp/block-5.C (test for excess errors)
> > 
> > These are just changes in error messages, but the old messages were clearer.
> 
> The old messages are still there, we just get additional ones from
> the gimple pass which is now run even though the function had errors
> before (we happen to have two places that emit the same diagnostics for
> slightly different cases).
> 
> > > FAIL: g++.old-deja/g++.jason/report.C (test for excess errors)
> > > Excess errors:
> > > /space/rguenther/trunk/gcc/testsuite/g++.old-deja/g++.jason/report.C:65:54:
> > > warning: control reaches end of non-void function
> > > /space/rguenther/trunk/gcc/testsuite/g++.old-deja/g++.jason/report.C:36:1:
> > > warning: control reaches end of non-void function
> > 
> > These are spurious warnings; both of these functions end with return
> > statements, they just happen to be ill-formed return statements.
> 
> Right.  The frontend hands us return <error_mark_node>; which the
> gimplifier drops on the floor.  Later diagnostic that now still runs
> even after the function has errors emits the warning for this reason.
> 
> For these kind of things I don't know what is best - maybe keeping
> a error/sorrycount per function would work.  But I'm not teribly
> concerned by these warnings-after-errors (at least I didn't want to
> make this patch even larger).
> 
> > > +       /* ???  From C++ generated thunks we get parms replaced by wrongly
> > > +          typed constants.  */
> > 
> > Is that from mapping null_pointer_node into the vtt parm for clones? Does
> > doing the conversion in maybe_clone_body do the trick?
> 
> I'll check.

It works ok, I have removed the inliner hunk and added the conversion
in maybe_clone_body.

Are the C++ frontend changes ok with that change?

Thanks,
Richard.