INCLUDE-ing a file that contains fpp directives

[OP1]

Is there a way to INCLUDE a file that contains fpp directives, such as __LINE__ ?

For instance, assume I have a module MY_MOD for which FPP preprocessing is allowed. This MY_MOD module has a CONTAIN section in which a INCLUDE 'MY_SUB.f90' statement appears. The subroutine MY_SUB contains, somewhere, a __LINE__ preprocessing directive.

When doing so the compiler complains about __LINE__ not being recognized.

Now, if, instead of using the Fortran INCLUDE statement, I try to use the FPP #INCLUDE preprocessing directive directly (shot in the dark...), my code compiles well but then when I execute it I get a program exception/access violation.

All this is with IVF 11.1 - and yes I know that with IVF 12 I could avoid all these headaches by using submodules ;) .

Any thoughts?

Thanks,
Olivier

[Steven_L_Intel1]

Well, no, you could not use submodules in version 12. We have not yet implemented those.

The problem is that fpp doesn't see INCLUDE. #include should work. If you're getting a run-time error, thast's a different problem which you'll need to debug.

[OP1]

I think I have a better diagnostic of what happens with the #INCLUDE directives.

Assume that:

1. My module contains (in the CONTAIN section) such #INCLUDE preprocessor directives.
2. I Build>Clean my solution.
3. I manually delete all content in the DEBUG and RELEASE folders for my solution.
4. I rebuild the entire solution.

If, after step 4, I launch the code, it starts working properly and then crashes with a Program Exception/Access Violation error somewhere.

Now, assume that:

5. I manually request a new compilation of the module just after step 4.

Then the code works properly. It seems that multiple compiling passes are required.

Strange - and a bit unsettling as far as having confidence in what the code actually does.

Olivier

[Steven_L_Intel1]

As an experiment, try turning off Fortran > Diagnostics > Check Routine Interfaces. (I think that's where it was in 11.1).

[OP1]

ok - so I turned off the "Check Routine Interfaces" option. Then I cleaned up the solution, and deleted all file from the DEBUG and RELEASE directories.
The first compilation pass to rebuild thewhole thingled to many ERROR #7002 errors (I guess because the .mod files had not been created yet). A second compilation pass was successful and the code was built.
However, when launching it, again I bumped into this Program Exception - access violation error.

This time, no matter how many times I tried to recompile manuallymy module, I couldn't get rid of this error.

Odd. I will use the double-compile strategy as a workaround (with the Check Routine Interfaces on), but I think something fishy is going on here.

Olivier

[Steven_L_Intel1]

Close Visual Studio. Delete the .suo and .u2d files in the project directory (these are "hidden" files so you may need to change the folder viewing options to see them). Then reopen the project and do Build > Rebuild.

[OP1]

Steve,

Deleting the .suo and .u2d files helped build the code (with Check Routine Interfaces on)in one pass (no more #7002 errors), but I still got the access violation error. Again, compiling once more the incriminated module helped solve the problem.

Olivier

[Steven_L_Intel1]

I'm going to guess that you are accessing memory outside the bounds somewhere and the order in which modules get linked changes the behavior. I can't think of anything else that would change simply by recompiling - if you have /warn:interface disabled. There have been bugs where that option changed code inappropriately.

[OP1]

Steve,

The culprit was a subroutine that was INCLUDEd (through fpp #INCLUDE directive)in the CONTAINS portion of the module, and which needed an explicit interface (due to having a deferred-shape argument). The option of having interfaces generated automatically was turned on however(and the corresponding warning message was issued by the compiler); but I suppose a glitch still happened somewhere.

The problem was solved by using an explicit interface for this subroutine. The code builds nicely in one pass now - without causing runtime errors.

I tried to create a small reproducer for this - to no avail.Butifyou are still interested I can try a little harder.

Thanks,
Olivier

[Steven_L_Intel1]

I'm a bit confused here - any procedure in the CONTAINS section of a module automatically has an explicit interface, both within the module and for any caller that USEs the module.

[OP1]

Steve,

You are correct - I didn't describe the situation properly. It is actually the INCLUDEd subroutine that calls another subroutine which in turn requires an explicit interface. I will try to see if I can reproduce this behavior on a small scale test code.

Thanks,
Olivier

[Steven_L_Intel1]

Ah, now that makes sense, and may not be easy to reproduce. Did not /warn:interface detect this? (It might not depending on order of compilation.)

[jimdempseyatthecove]

Steve,

Does Visual Studio dependency walker, with IVF add-ons, make dependency checks on fpp #include files?
If not, then module source files with #include would not get rebuilt when required.

[Steven_L_Intel1]

Yes, the build dependency analyzer does take #include files into account.