[PATCH, fortran, PR 82869] Introduce default_logical_type_node and logical_type_node

[Janne Blomqvist]

On Wed, Nov 8, 2017 at 1:57 PM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> On Wed, Nov 8, 2017 at 12:27 AM, Steve Kargl
> <sgk@troutmask.apl.washington.edu> wrote:
>> On Tue, Nov 07, 2017 at 10:38:43PM +0200, Janne Blomqvist wrote:
>>> On Tue, Nov 7, 2017 at 10:06 PM, Steve Kargl
>>> <sgk@troutmask.apl.washington.edu> wrote:
>>> > On Tue, Nov 07, 2017 at 08:26:15PM +0200, Janne Blomqvist wrote:
>>> >> +
>>> >> +  logical_type_node = gfc_get_logical_type (4);
>>> >
>>> > Can you add a comment to note that the 4 is purposely chosen?
>>> > A year or so from now, someone might change this to gfc_default_logical_kind
>>> > without understand/recalling why 4 is used.
>>>
>>> The patch contains a comment explaining that in trans-types.h.
>>
>> Well, did say I scanned the patch ;-)
>>
>>> However, a bit of further experimenting with my patch revealed that
>>> one can cause these latent bugs I feared to appear by playing with
>>> -fdefault-integer-8 / -finteger-4-integer-8 with the example from
>>> bugzilla (so we end up passing a pointer to a logical(kind=4) variable
>>> but we tell libgfortran it's kind=8). I did fix the most obvious ones
>>> in the attached patch (on top of the previous one), but I'm not
>>> convinced it's exhaustive.
>>>
>>> So I wonder, do we actually care enough about -fdefault-integer-8 /
>>> -finteger-4-integer-8 to do this kind of micro-optimization (i.e. use
>>> 4 byte logical temporary variables if we can even when we use
>>> -fdefault-integer-8 / -finteger-4-integer-8), or should we play it
>>> safe and just use default_logical_type_node everywhere?
>>
>> I certainly don't care about fallout when one uses -fdefault-*
>> options.  I've stated more than once I think these should
>> be removed, because these options break storage association
>> (among other things).  I a little surprise that -finteger-4-integer-8
>> have an effect, but I admit I haven't looked closely at the
>> internal representation of a Fortran logical and its relationship
>> to INTEGER(4).
>>
>> --
>> steve
>
>
> So in the end I decided to play it safe and do the simpler approach.
> Patch that I committed as r254526 attached. Unless there are
> objections, I'll apply it to the GCC-7 tree in a few days as well
> since it's a regression.

Applied to the gcc-7 branch in r254706.



-- 
Janne Blomqvist