Inconsistent Compiler Error checking

[Pat]

Inconsistent Compiler Error checking using Intel 10.1 FORTRAN on WIn 7

Currently  using VS 2008 and Intel FORTRAN 10.1 on Win 7 enterprise.  Running 32 bit version of these on a 64 bit machine.   Using DEBUG settings only, compiler license is housed on a server.

I have  been noticing that compliation and linking of some development code will show successful creation of an executible with no errors on several consecutive "rebuild solution" attempts. (sometimes as many as 5-8) However on a later attempt, with no changes to the code, the complier suddenly finds an error in variable type, syntax, etc that it did not find on the previous attempts.  This seems rather unpredictable except that when it finally finds the error, it continues to find it.  Errors range from undeclared variables to dummy and acutal argument types not matching.

It is a bit of a troubling mystery that it doesn't find those errors every time.    Being a developer, I am concerned that I could create a binary that won't function correctly because the compiler missed an error during a "successful" attempt.

Look forward to replies.  Thanks.

Pat

[bmchenry]

you'll have to try to provide an example.

we're living in a digital world so it can't behave differently unless something you change in the code 'activates' part of the code that was ignored in a prior compilation or you change compiler options etc.

there are no gremlins which only come alive once in a while during compilations...or so i hope!

[Pat]

I would love to do that...except I don't know it finds an error until it does.  The only way to provide and example would be to save every executable I create with a different name in the hopes that that a later compilation would find the error ane then compare those two executabiles.  Besides providing an example my prove problematic due to IP restrictions  and the proprietary nature of the code.

I agree we live in a digital world, and I wouldn't have believed it if:

I hadn't saw it for myself;

And had others tell me very similar accounts of their experiences;

I have been a FORTRAN programmer since 1988 and have never saw a behavior like this affecting more than one user.  Are there any nuances in the VS2008 or Intel 10.1 installation that could be bunged up with an unintended partial or fautly installation of program(s)?

[Steven_L_Intel1]

I can understand argument mismatch errors appearing on a subsequent build - the compiler's "generated interface checking" feature relies on the routine being called having been compiled before the call is seen. Depending on the build order, that may not happen.

I can't understand syntax errors appearing suddenly, though.

[FortranFan]

Pat S. wrote:

Inconsistent Compiler Error checking using Intel 10.1 FORTRAN on WIn 7

Currently  using VS 2008 and Intel FORTRAN 10.1 on Win 7 enterprise.  Running 32 bit version of these on a 64 bit machine.   Using DEBUG settings only, compiler license is housed on a server.

I have  been noticing that compliation and linking of some development code will show successful creation of an executible with no errors on several consecutive "rebuild solution" attempts. (sometimes as many as 5-8) However on a later attempt, with no changes to the code, the complier suddenly finds an error in variable type, syntax, etc that it did not find on the previous attempts.  This seems rather unpredictable except that when it finally finds the error, it continues to find it.  Errors range from undeclared variables to dummy and acutal argument types not matching.

It is a bit of a troubling mystery that it doesn't find those errors every time.    Being a developer, I am concerned that I could create a binary that won't function correctly because the compiler missed an error during a "successful" attempt.

Look forward to replies.  Thanks.

Pat

Are you sure you're not inadvertently changing the project configuration to RELEASE instead of DEBUG or some other project setting when you see the errors?  The Release configuration may have different compiler switches which may explain the errors.

I don't know whether Intel Fortran 10.1 produces a BuildLog.htm output file or some other build log format.  If it does, you should try to save the log for a successful compile case.  And when the errors happen, compare the new log to the saved one.

Very strange issue this!

[Pat]

Steve,

That seems to ring true.  What I have seen in my  solution spaces is the build order sometime changes from build to build.  I only do rebuild solution as my option so I get clean builds.   All of our team uses the VS2008 interface to build solutions and I encourage them to do clean builds.    Is there a way to ensure the build order is always the same?

I thought it might be me doing someithing odd...like with fortranfan suggested about debug versus release selections.   But when others approached me describing the same symptopms, I didn't think it was a coincidence....

[Steven_L_Intel1]

Putting on my "Doctor Fortran" hat (and stethoscope), the best way to deal with this is to never rely on implicit interfaces - have every subroutine or function in a module. That way you'll never need to worry about build order and you'll always get error messages for call inconsistencies if they're valid.

Otherwise, no, there's no way to guarantee a particular build order.

[Pat]

Steve Lionel (Intel) wrote:

Putting on my "Doctor Fortran" hat (and stethoscope), the best way to deal with this is to never rely on implicit interfaces - have every subroutine or function in a module. That way you'll never need to worry about build order and you'll always get error messages for call inconsistencies if they're valid.

Otherwise, no, there's no way to guarantee a particular build order.

I appreciate the Dr. Fortran advice. For future I am planning to use makefiles where I believe I can control the order more explicitly. My understanding is VS2008 can load a makefile and create a project. Do I have that right? This may help folks who like to use graphical debugging but build using makefiles.

Thanks

[Steven_L_Intel1]

No, that's not correct. VS has not had makefile support in a very long time. But one can still build from the command line and debug in VS by building with the proper debug switches and then invoking devenv.exe on the executable to start debugging.

[FortranFan]

Pat wrote:

.. For future I am planning to use makefiles where I believe I can control the order more explicitly. ..

Listen to the good Doctor!

Your code shouldn't need to rely on an explicit, user-specified build order - the Doctor's message is it is not really "healthy!" to do so.  Let the IDE (Visual Studio) take care of it.  So it makes sense to stop looking for workarounds to achieve such a thing.

Yes, it'll be some work to reorganize code to move it past implicit interfaces and such, but it'll be worth it in the end.  Especially if you plan on using the code for any reasonable length of time.

[Pat]

Yesterday I hit the rebuild solution for a particular project and the compiler found two errors.  After an approximately 1 minute pause not clicking anything else nor doing anything else, I hit the rebuild solution button and it now finds the orignal two errors and 8 additional ones.   Subsequent selections of the rebuild solution button finds all 10 errors consistantly.  No action at all was taken between the first and second clicks of rebuild solution yet if found those additional 8 errors on the second push of the rebuild solution button.

My question is why doesn't the compiler find all the errors on the first rebuild solution invocation?  We have witnessed this behavior on several different FORTRAN projects since we have had VS 2008 and INtel 10.1 installed.  We are concerned that if the first two errors had not been found, the code would compile successfully.  We have had examples of that as well.

Thanks,

Pat

[andrew_4619]

The answer is that your code has errors and you do not have explicit interfaces so when compiling a routine with check interfaces the compiler has to relay on old generated interfaces from the last build that might be out of date or alternatively cannot check at all. In either case a second build can expose errors that were there the first time but could not be checked properly on the first build. 

Use modules and you will not have these problems and the code will be more reliable.

[Pat]

This was a "rebuild solution" activity both times...which executes a "clean" prior to compiling.   No selections or changes were made.  What I did was hit the rebuiuld soultion button to consecutive times with about a 1 minute pause in between.  There should have been no legacy residue left due to the clean command.  Does that change your observation?

[andrew_4619]

So can you be ABSOLUTELY sure you hit the rebuild menu item rather than the build menu item in both cases? Software is generally repeatable. Can you repeat this and post both build logs?

I stand by the comments make as being valid.

The code clearly has errors, the compiler found errors.  

[Steven_L_Intel1]

A rebuild might or might not detect argument consistency errors using generated interfaces, depending on the order of compilation.

[nvaneck]

gen-interfaces seems an easier first step. Putting everything into modules or procedure contains could be a huge job if variables in the subroutines use some of the same names as the host routine for different purposes.