Split source needed for correctness

[TimP]

I've been concerned about behavior of applications which make use of module procedures, preventing testing of separate compilation. I noticed today that ifort no longer  works on the classic paranoia benchmark with default options plus protect_parens unless it is split into individual source per procedure.  Although I've had applications where Qip[-] helped, it makes no difference here. It's mostly f77, no modules. Apparently protect_parens fails at one point with the single source file.  I would think this application should be ok to file in ips or post on github.

[Steven_L_Intel1]

Tim, is there something you'd like us to do here? I couldn't quite follow. Maybe you're interested in fsplit?

[TimP]

I did use fsplit to get the version which still works with current fort.  There's also f90split, but I don't think module procedures can be turned automatically to external.

I'm pointing out that bad effects of concatenated source and difficulty with possible interprocedural transformation (even if ostensibly turned off) discourage me from using slightly more modern methods like module procedures.  I'm also aware from the past that in-lining may turn range violation into a failure, but this doesn't look to be that problem.

I did turn up some discrepancies in integer sizes across calls in legacy code due to improved checking in modern compilers.as

In this case, /fp:source works and fixes all the paren situations. assume:protect_parens misses one when source isn't split.

.  In general, we want at least the default level of optimization to work when either  protect-parens or standard-semantics is set 

Without one of -standard-semantics, -fp:source, or assume:protect_parens, it hangs at run time in an infinite loop.  Single source file is not a problem for those instances of protect-parens.