Change double_int calls to new interface.

> Date: Tue, 11 Sep 2012 17:03:39 -0700
> From: Ian Lance Taylor <iant@google.com>
> 
> On Tue, Sep 11, 2012 at 3:12 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> > On 9/11/12, Andreas Schwab <schwab@linux-m68k.org> wrote:
> >> Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> >>> In file included from ../../../src/gcc/gcc/mcf.c:47:0:
> >>> ../../../src/gcc/gcc/mcf.c: In function 'void dump_fixup_edge(FILE*,
> >>> fixup_graph_type*, fixup_edge_p)':
> >>> ../../../src/gcc/gcc/system.h:288:78: error: integer overflow in
> >>> expression [-Werror=overflow]
> >>
> >> This is PR54528.
> >
> > The expression itself looks correct.  I have not been able to
> > duplicate the problem on x86.  I am now waiting on access to the
> > compile farm for access to a hppa system.  Does anyone have more
> > specific information on the condition that generates the error?
> 
> I haven't tried, but I bet you can get it to happen if you build a
> 32-bit compiler--that is, build a compiler using -m32 so that the
> compiler itself runs 32 bit code.

I don't think that helps since I don't see the problem on OpenBSD/i386
(i386-unknown-openbsd5.2) whith a strictly 32-bit compiler.  As I
wrote earlier, I suspect the key factor is HOST_WIDE_INT being 32-bit,
which means 32-bit architectures that don't sey need_64bit_hwint in
config.gcc.  The fact that m68k is affected as well strengthens my
suspicion.  So I expect arm to show the problem as well.  But people
probably haven't noticed since they cross-compile.

Anyway the "diff" below seems to fix the issue.  Guess the replacement
doesn't work!  Should be a big enough clue for Lawrence to come up
with a proper fix.

On 9/12/12, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Tue, 11 Sep 2012 17:03:39 -0700
>> From: Ian Lance Taylor <iant@google.com>
>>
>> On Tue, Sep 11, 2012 at 3:12 PM, Lawrence Crowl <crowl@googlers.com>
>> wrote:
>> > On 9/11/12, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> >> Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>> >>> In file included from ../../../src/gcc/gcc/mcf.c:47:0:
>> >>> ../../../src/gcc/gcc/mcf.c: In function 'void dump_fixup_edge(FILE*,
>> >>> fixup_graph_type*, fixup_edge_p)':
>> >>> ../../../src/gcc/gcc/system.h:288:78: error: integer overflow in
>> >>> expression [-Werror=overflow]
>> >>
>> >> This is PR54528.
>> >
>> > The expression itself looks correct.  I have not been able to
>> > duplicate the problem on x86.  I am now waiting on access to the
>> > compile farm for access to a hppa system.  Does anyone have more
>> > specific information on the condition that generates the error?
>>
>> I haven't tried, but I bet you can get it to happen if you build a
>> 32-bit compiler--that is, build a compiler using -m32 so that the
>> compiler itself runs 32 bit code.
>
> I don't think that helps since I don't see the problem on OpenBSD/i386
> (i386-unknown-openbsd5.2) whith a strictly 32-bit compiler.  As I
> wrote earlier, I suspect the key factor is HOST_WIDE_INT being 32-bit,
> which means 32-bit architectures that don't sey need_64bit_hwint in
> config.gcc.  The fact that m68k is affected as well strengthens my
> suspicion.  So I expect arm to show the problem as well.  But people
> probably haven't noticed since they cross-compile.
>
> Anyway the "diff" below seems to fix the issue.  Guess the replacement
> doesn't work!  Should be a big enough clue for Lawrence to come up
> with a proper fix.
>
> Index: fold-const.c
> ===================================================================
> --- fold-const.c	(revision 191150)
> +++ fold-const.c	(working copy)
> @@ -982,13 +982,15 @@
>        break;
>
>      case MINUS_EXPR:
> -/* FIXME(crowl) Remove this code if the replacment works.
> +      /* FIXME(crowl) Remove this code if the replacment works.  */
> +#if 1
>        neg_double (op2.low, op2.high, &res.low, &res.high);
>        add_double (op1.low, op1.high, res.low, res.high,
>  		  &res.low, &res.high);
>        overflow = OVERFLOW_SUM_SIGN (res.high, op2.high, op1.high);
> -*/
> +#else
>        res = op1.add_with_sign (-op2, false, &overflow);
> +#endif
>        break;
>
>      case MULT_EXPR:

My suspicions were on the shift operation.  I will update the last patch
I sent out with a fix.  I will probably need help testing.