[c++-delayed-folding] First stab at convert_to_integer

[Marek Polacek]

On Fri, Oct 16, 2015 at 02:07:51PM -1000, Jason Merrill wrote:
> On 10/16/2015 07:35 AM, Marek Polacek wrote:
> >>This code path seems to be for pushing a conversion down into a binary
> >>expression.  We shouldn't do this at all when we aren't folding.
> >
> >I tend to agree, but this case is tricky.  What's this code about is
> >e.g. for
> >
> >int
> >fn (long p, long o)
> >{
> >   return p + o;
> >}
> >
> >we want to narrow the operation and do the addition on unsigned ints and then
> >convert to int.  We do it here because we're still missing the
> >promotion/demotion pass on GIMPLE (PR45397 / PR47477).  Disabling this
> >optimization here would regress a few testcases, so I kept the code as it was.
> >Thoughts?
> 
> That makes sense, but please add a comment referring to one of those PRs and
> also add a note to the PR about this place.  OK with that change.
 
Done.  But I can't seem to commit the patch to the c++-delayed-folding
branch; is that somehow restricted?  I'm getting:

svn: E170001: Commit failed (details follow):
svn: E170001: Authorization failed
svn: E170001: Your commit message was left in a temporary file:
svn: E170001:    '/home/marek/svn/c++-delayed-folding/svn-commit.tmp'

and I've checked out the branch using
svn co svn://mpolacek@gcc.gnu.org/svn/gcc/branches/c++-delayed-folding/

> >Moreover, there are some places in the C++ FE where we still call
> >convert_to_integer and not convert_to_integer_nofold -- should they be
> >changed to the _nofold variant?
> 
> Not in build_base_path; its arithmetic is compiler generated and should
> really be delayed until genericize anyway.  Likewise for
> get_delta_difference.
> 
> I think the call in finish_omp_clauses could change.

All right, I'll submit a separate patch.  Thanks,

	Marek