Hi Paul,
> I am trying to respond to Mikael's comment that only kind=1 is handled. I'll
> use your patch as a basis.
actually the last version of the patch that I posted yesterday should
already handle that (and includes a kind=4 test case). But if you find
any remaining problems, please let me know.
Also Tobias already told me privately that his "mixed feeling" were
not strong enough to oppose against committing the patch. So right now
the only thing standing between the patch and trunk seems to be you ;)
Cheers,
Janus
> On Mar 5, 2014 2:53 PM, "Janus Weil" <ja...@gcc.gnu.org> wrote:
>>
>> Hi Mikael,
>>
>> >> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>> >>
>> > I'm asking for one more minor change, namely:
>> >
>> >> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>> >> return false;
>> >> }
>> >>
>> >> + /* Add the hidden deferred length field. */
>> >> + if (c->ts.type == BT_CHARACTER && c->ts.deferred &&
>> >> !c->attr.function
>> >> + && !sym->attr.is_class)
>> >> + {
>> >> + char name[GFC_MAX_SYMBOL_LEN+1];
>> >> + gfc_component *strlen;
>> >> + sprintf (name, "_%s", c->name);
>> >
>> > It's not more costly to have a more explicit name like "_%s_length" or
>> > something, and I prefer having the latter in complicated dumps or in the
>> > debugger.
>>
>> I agree.
>>
>>
>> > OK with that change, with the associated buffer size update. Also Steve
>> > noted that the buffer size should take the terminating null character
>> > into account.
>>
>> Steve's comment somehow got lost in the noise. I have updated both the
>> name and the buffer size now in resolve_fl_derived0 as well as
>> gfc_deferred_strlen. Updated patch attached.
>>
>> A few people expressed mixed feelings, therefore I'll wait a couple of
>> days to allow the naysayers to chime in. In the absence of further
>> feedback, I'll commit the patch on the weekend.
>>
>> Cheers,
>> Janus
