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

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear All,

I wonder if a good way around it would be to ask the masters of the
arcane mysteries to hide this sort of C++ snippet behind a gfc_xxx
function? That way, maintainers like myself (I am not entirely
innocent of said mysteries but has been a little while), needn't worry
our pretty little heads about it and, if adequately commented, we
might even learn something :-) I presume that it would get inlined in
any case so there would be no performance hit.

Best regards

Paul

On 9 December 2016 at 19:51, Jerry DeLisle <jvdelisle@charter.net> wrote:
> On 12/09/2016 08:49 AM, Andre Vehreschild wrote:
>>
>> Hi Steve,
>>
>> Oh I was totally oblivious that this is C++. It comes naturally to me. So
>> I did not get what the problem could be. What to do about it? Are there
>> defines that hide this?
>>
>> - Andre
>>
>> Am 9. Dezember 2016 17:29:16 MEZ, schrieb Steve Kargl
>> <sgk@troutmask.apl.washington.edu>:
>>>
>>> On Fri, Dec 09, 2016 at 11:23:02AM +0100, Andre Vehreschild wrote:
>>>>
>>>> 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?
>>>>
>>>
>>> I think the issue here is that some who contribute to gfortran have
>>> ZERO knowledge of C++.  The line you remove is quite clear.  The new
>>> line is quite opaque.  As more C++ creeps into the Fortran FE, it is
>>> likely that some may stop contributing.
>>
>>
>
> The issue for me has less to do with C++ syntax and more to do with not
> knowing the classes available.  Zooming out on the subject chunk of code:
>
> static int
> gfc_conv_cst_int_power (gfc_se * se, tree lhs, tree rhs)
> {
>   tree cond;
>   tree tmp;
>   tree type;
>   tree vartmp[POWI_TABLE_SIZE];
>   HOST_WIDE_INT m;
>   unsigned HOST_WIDE_INT n;
>   int sgn;
>   wide_int wrhs = rhs;
>
>   /* If exponent is too large, we won't expand it anyway, so don't bother
>      with large integer values.  */
>   if (!wi::fits_shwi_p (wrhs))
>     return 0;
>
>   m = wrhs.to_shwi ();
>   /* 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);
>
> We see wide_int. I was not right away familiar with where that was defined
> and whether it is a class or not. The :: tells me wi is a class. Then I see
> we have another snippet of C++ already there on trunk. So then I have to
> wonder where is this class defined and how do I find documentation for its
> methods. Then I have to either ignore it and trust it is right or spend a
> lot of time digging around to find the documentation. I can sort of infer it
> from the abbreviated function names, but really don't know it from rote.
>
> Although C++ has its good qualities, one of the downsides is it introduces
> you to so much abstraction and hidden layers of functions that you are
> forced to find an editor or IDE with a class browser so you can find and
> look at the definitions. I find it ironic that the very intended concept of
> hiding the details actually leads to obfuscation, the unintended result,
> simplification leading to complexity. (As opposed to C which I can hold a
> small book in my hand, or a pdf file that contains all I need to know.)
>
> And all of the above I say regarding what we do to flip a bit in an integer
> and cast it to a different size. ( and to stop the sanitizer from
> complaining )
>
> I am forced to wonder why we are doing this exercise. Was this a false
> positive from the sanitizer? I am not asking you to change it. If this is
> the best way one can find, then it is what it is.
>
> Jerry
>
>
>
>



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama