On Tue, Nov 07, 2017 at 10:38:43PM +0200, Janne Blomqvist wrote: > On Tue, Nov 7, 2017 at 10:06 PM, Steve Kargl > <s...@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
