adding 64bit configuraiton; updating an old fortran project

[Groos__Geoff]

I am looking to port and update a visual fortran project written by a scientific genius (read: not one who deals with visual studio idiosyncrasies well) from release-only x86-only to release-or-debug on x86-or-x64. The critical blocking feature is x64 support. nice-to-have's include tests that link the same way our application does (read: via dll) and use of "attach to process: myapp-wrapping-java-calling-mydll.exe" working correctly.

To do this I've created a new solution file and attempted to basically rewrite the vfproj files by hand after they were generated by visual studio. This has been informative and overwhelming.

edit: some notes, "application code" is mostly java and is mostly UI/etc, as distinct from my fortran "science code", which is ifort 2017 compiled to a dll loaded by the java application code.

So far:

1. I got it building, but I have to call ifort twice every time I want to rebuild, else it screws up the dependency ordering and attempts to compile sub-modules in the wrong order. The original author said "yeah, sometimes ifort does that". I've sort've punted this one because it doesn't seem to block me. My build agents wont like this. TODO.
2. I re-compiled x86 for debug and release, dropped it into my app. Preliminary tests show everything fine (except now ifort is encoding boolean true as 0XFF instead of 0x01. Probably in the release notes somewhere? Not blocking.)
3. re-compile for debug|x64, move small mountains in app code to get it on x64, run my app: I get a SIG_SEGV (trapped by JVM and exposed as a InvalidMemoryAccessError) half-way through my native code's execution. So I need to debug!
4. Run my application, attempt to "attach to process" from visual studio: no luck. Symbols not loaded.
5. I want to run the science code's embedded tests; I don't know if my science code works at all (read: without the mangling & lazy loading by app-code), so I go to run the handy test functions that are embedded in our release code (?). Unfortunately the vfproj is ConfigurationType="typeDynamicLibrary", and Visual studio doesn't let me change that, so I cant run it directly. I removed the ConfigurationType, got a exe instead of a dll, which, when run, errors out with "Not a valid win32 application". I then tried to create a new vfproj for the tests that would consume its dependency vfproj science code. I'm stumped at how I can/should app such a dependency, since visual studios usual "references" block is missing, and adding the .lib (dll wrapper) in the additional-include directories fails with unknown symbol.

So now I'm stumped. I cant test it, I cant debug it. It works a little bit.

My immediate questions:

1. Whats the easiest way I can add a reference to an existing project (ideally via a static reference)?
2. What do I need to do to get visual studio's "debugger: attach to process" working?

Tomorrow I'll minimize the project to remove source code in an attempt to upload it here. Any help is appreciated.

[FortranFan]

Groos, Geoff wrote:

.. Any chance the fortran team could provide a builtin akin to `INT4(arg)` and `INT8(arg)` for `INT_C_SIZE_T(arg)`?

So my major work areas now are:

1. why is my stack corrupt? ..
2. I want to change fortrans runtime error behaviour to leverage something like a exception-style long-jump. For all pure errors (divide by zero, FPE related, etc) this should be a reasonably effective recovery mechanism.
3. I want to change fortrans error behaviour to output somewhere other than standard-error. Ideally of course it would hit my logging framework at level SEVERE, but without some kind of general-purpose callback

@Groos, Geoff:

Please see response #21: if you use standard Fortran (some books may help: this one and this), you will see the language already provides most of what you need in the context you've presented in this thread starting with INT elemental intrinsic function: https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-int

And if you use standard Fortran features, it can considerably ease your code development and help reduce issues with stack corruption.

I would suggest against "I want to change fortrans runtime error behaviour to leverage something like a exception-style long-jump".  Re: "errors (divide by zero, FPE related, etc)" look at facilities in Fortran with IEEE exceptions; assume your code base will run on devices with IEEE floating-point?

Re: "I want to change fortrans error behaviour to output somewhere other than standard-error. Ideally of course it would hit my logging framework at level SEVERE, but without some kind of general-purpose callback" 

- hmm.. error handling in Fortran with procedure parameters or simple file-based IO or interoperation via C-compliant callback is what is straightforward here.  Trying "to change fortrans error behaviour" looks rather risky.