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

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

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