Hi Steve, Following an email from Dominique to me, I think not. In the course of fixing PR49954, I put right the setting of the descriptor dtype. Since this gets passed to the IO runtime, I think that this is the reason for the difference in behaviour.
I think that another week of effort should put right gfortran's woes with deferred characters. As well as concatenation problems that I think I have fixed, parentheses cause instant death :-( Cheers Paul On 14 November 2015 at 18:49, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Sat, Nov 14, 2015 at 06:39:28PM +0100, Paul Richard Thomas wrote: >> >> I am completely unable to reproduce the problems that Dominique is >> reporting for deferred_character_4.f90. This might be because the >> patch has moved on to fix PR49554 :-) >> >> Concatenation expressions assigned to deferred length character arrays >> need careful handling to ensure that the temporary creation for the >> concatenation operator occurs at the right place, that the descriptor >> dtype is updated and an array temporary is created if there is any >> dependency between lhs and rhs. This latter has been implemented in >> resolve.c. >> >> Testcases 4-6 have been added to reflect the additional fixes afforded >> by the original patch, as reported by Dominique (thanks!). >> >> As soon as this patch has been committed, I will prepare a version for >> 4.9 and 5 branches >> >> Bootstrapped and regtested on FC21/x86_64 - OK for trunk? >> > > Hi Paul, > > I was going to cast an eye over your diff today. I'll > build and run some tests on FreeBSD. Dominiq uses > MacOS. So, perhaps, some latent memory corruption > issue. > > -- > steve -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
