Character string is lost

I have what seems to be an impossible-to-report problem with a character string getting lost in the 64-bit version! The core of the problem looks something like the following:

Use m, Only: c2 ! c2 is a character string
Character(Len=16) :: c1
Write ( Unit=c1, Fmt='(A)' ) c2
c1 = c1 ! bug is avoided with this line, as long as this comment is deleted!
Print * c1

I recognise that the above is incomplete code, so it cannot be tested. But I don't know where to begin to start to create an example to illustrate this because the bug does not occur when (a) compiling in 32-bit, (b) adding useless lines like line 4. Even more perplexing, the problem reappears when adding a comment to line 4, and it can also be made to disappear if I delete code that is never even called. The full code is about 160,000 lines. I am happy to try to forward that to Paul if diagnosing this problem does not look like a massive task.

Simon

I have not seen UNIT=<character variable> before. Is that legal? It is not faulted by FTN95 but perhaps it should be.

Hi Paul, I've been using Unit=character for years, actually probably decades. Actually, in this case, I don't think it is integral to the problem I am experiencing since I have other examples that do not use this construct anyway. But, yes, it is probably worth checking how FTN95 handles it. I am uncertain of what the Fortran standard is, but my understanding is that Unit becomes a negative number when it is using an internal file. But it may well be illegal to attempt to pass the character explicitly as the Unit number. If anybody knows I would be happy to hear. Simon

Simon

Ah yes. I did not recognise it as an internal write statement.

Have you looked at the point of failure using the debugger? Have you tried omitting the ONLY in the USE statement?

Hi Paul, Unfortunately, if I try to compile using /DEBUG /CHECK, I get the following error somewhere else in the program:

AMD backend failure:Failed to do register-memory emit for MOV_Q at ...

in each case at a Subroutine declaration. Plus I get some Internal compiler errors, again at some Subroutine declarations. None of these problems occur when compiling without those options, nor do they occur when compiling in 32-bit, with or without.

Simon

1. Please send a simple program that illustrates the /64 /CHECK failure. This is probably something that we need to fix.

2. Try using /DEBUG on its own. That might help you to work out what is going wrong.

Hi Paul, I will try to send a simple program, but I estimate it will take more than a full day's work, so I can't promise to do it soon. If I remove /CHECK, then I no longer et compilation errors. and some of the runtime errors go away. When I get some free time, I will try to isolate all these issues ...

Here are portions of F2008 that pertain:

F2008: 9.6.2R913: io-control-spec is UNIT = io-unit OR ... 9.5.1: R901: io-unit is file-unit-number OR * OR internal-file-variable

Here is the source of a modified version of the test program that runs correctly with the 9.05 version of FTN95

module m
character(12) :: c2 = 'String c2xyz'
end module

program buggy
Use m, Only: c2 ! c2 is a character string
Character(Len=16) :: c1
Write ( Unit=c1, Fmt='(A)' ) c2
Print *, c1 
end program

Thanks for the confirmation. It appears that my partial code was legal, so I'll have to try and find a way to isolate the problem.