Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

[Andre Vehreschild <vehre at gmx dot de>]

Hi Jerry,

> For those of us who don't always get it, can you explain this line:
> 
> -  /* There's no ABS for HOST_WIDE_INT, so here we go. It also takes care
> -     of the asymmetric range of the integer type.  */
> -  n = (unsigned HOST_WIDE_INT) (m < 0 ? -m : m);
> +  n = wi::abs (wrhs).to_shwi ();                <======

I am not sure, what you expect here. Do you desire me to add a comment to the
code or tell my intentions why I think the new line is idem-potent to the old
one?

If the latter, well, the new line is not completely idem-potent to the old one.
But first things first; The comment that I also stripped, says that the next
line is a crutch to implement an abs on HOST_WIDE_INTs because there is no
function for abs available on HOST_WIDE_INTs. While browsing for alternatives
I've learned, that gcc/wide-int.h does implement abs() on wide_ints which are
the base of the wrhs in the expression. So in the old expression m ==
wrhs.to_shwi() so I thought it would be sufficient to do the abs on the
wide_int and than convert it to HOST_WIDE_INT. That is I reversed only the
order of conversion to HOST_WIDE_INT and abs().

To be precise, the code is not 100% idem-potent to the old one. The first issue
is about the asymmetry of the signed int, where the 0 is counted to the
positive values making the number of negative values larger by one.
Nevertheless doing the -m as in the old code for signed 64-bit -huge(_8) gives
a number whose value should not fit into the datatype, but surprisingly is
shown as such in the debugger. This might prove a bigger difference on systems
that do not use 1-complement for negative numbers.

The second issue is that in the old code the cast should be "cutting" the "too
large" positive. IMO the result should have been 0 because 1...1 (64 ones)
negated should be 10...0 (64 zeros), casted to 64-bit leaving only the zeros.
What magic is done here behind the scenes is not known to me, but the behavior
of the compiled program seems reasonable and the sanitizer stops complaining. I
therefore choose to go for this solution.

Again, I have been working mostly in the trans-phase of gfortran and this part
of numeric conversion is untrotten territory to me. So all ideas and comments
how to improve this are welcome. The solution I presented is more an
identification of the problem, not the best solution possible. For the latter I
need all your expertise. So how can we improve this?

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de