On Tuesday 03 October 2006 11:08, Joseph S. Myers wrote:
> On Tue, 3 Oct 2006, Jan van Dijk wrote:
> > More serious is the fact that the compiler translates 1*(Inf,Inf) into
> > (NaN,NaN). This is plain wrong, but, as Joseph mentioned, the solution
> > requires the implementation of mixed-mode MULT_EXPRESSIONS, since
> > apparently
> >
> > 1*(Inf,Inf) == (Inf,Inf) != (1,0)*(Inf,Inf)==(NaN,NaN).
>
> In C99 mode, the libgcc function should be called to ensure that you don't
> get (NaN,NaN), as per the Annex G algorithm.
I just noticed that g++ was fixed wrt this issue somewhere between 4.1.0 and
HEAD.In the tree dump with -O0 with 4.1.0, I noticed an expanded form of the
multiplication, without handling of the (NaN,NaN) case. With HEAD __muldc3 is
called and the result is correct, indeed.
> > Is the latter project suitable for a motivated newby? I am willing to
> > spend some time and effort into this issue, but will definitely need
> > guidance from time to time.
>
> Instead of trying mixed-type expressions, call save_expr on both real and
> complex operands, multiply the real and imaginary parts separately and
> then form a COMPLEX_EXPR of the results. Likewise for addition,
> subtraction and complex/real division (real/complex division can continue
> to be handled like complex/complex). You'll need to change how
> build_binary_op uses c_common_type since in these cases you'll no longer
> want to convert both operands to that type - the complex operand should be
> converted to it, but the real operand to the corresponding real type.
That is a lot for me to digest, but gives me nice starting point for studying
gcc. Thank you.
Regards,
Jan van Dijk.
