5508: Declaration of routine 'CPTITLE' conflicts with previous declaration

[scrognoid]

I get this error, although grep assures me there is no other declaration of this routine.

I am using the latest version, purchased this week.

Related: How do I get the Solution Browser to show full paths, so I know I'm not getting the routine from the wrong place?

[Steven_L_Intel1]

Try doing a Build > Rebuild Solution and see if that helps.

If you click on the file name in Solution Explorer, you should see a "File Properties" pane that will give the full path. If it is not visible, press F4.

[scrognoid]

Quoting - Steve Lionel (Intel)

Try doing a Build > Rebuild Solution and see if that helps.

If you click on the file name in Solution Explorer, you should see a "File Properties" pane that will give the full path. If it is not visible, press F4.

Rebuild did not fix it, but deleting the Debug directory did. Not sure why.

[ArturGuzik]

Quoting - scrognoid

Rebuild did not fix it, but deleting the Debug directory did. Not sure why.

Cleaning solution is probably enough (instead of brute force "delete folder"). It deletes then all intermediate files. Most probably VS just gets confused. I observe the same for .Net projects as well, after modifications to settings, importing some parts from other projects etc.

A.

[scrognoid]

Quoting - ArturGuzik

Cleaning solution is probably enough (instead of brute force "delete folder"). It deletes then all intermediate files. Most probably VS just gets confused. I observe the same for .Net projects as well, after modifications to settings, importing some parts from other projects etc.

A.

Clean Solution didn't work. I had tried that.

[scrognoid]

Quoting - ArturGuzik

Cleaning solution is probably enough (instead of brute force "delete folder"). It deletes then all intermediate files. Most probably VS just gets confused. I observe the same for .Net projects as well, after modifications to settings, importing some parts from other projects etc.

A.

I'm still having the problem. Clean solution doesn't fix it, nor Rebuild. It wasn't just deleting Debug that made it go way, it was switching to Release. Apparently Debug is doing the check, but Release isn't. But where is the conflict coming from? How do I 'unconfuse' VS? Do I need to scrap the solution and start over?

[Steven_L_Intel1]

Evidently, generated interface checking is the problem. Can you attach the source? You can turn off interface checking under Diagnostics.

[scrognoid]

I think I uploaded the solution in cross.zip to a folder called scrognoid. (The UI for Add Files is a bit vague.) Thanks. There are a few extra files used by another compiler.

When I disable the specific diagnostic on the specific file, I just get "Compilation aborted"

[Steven_L_Intel1]

Please follow ALL the steps in this post explaining how to attach files. You appear to have missed the last few. Please also attach the DebugBuildlog.htm from a failed build.

[scrognoid]

trying again to attach.

[Steven_L_Intel1]

Ok. The error you have here is that in cross.f, line 385, you have a call to cfft1d where you pass RTIME as the second argument. RTIME is declared REAL*4. In fft_tools.f line 51, the corresponding dummy argument X is declared COMPLEX*8. This mismatch is not allowed by Fortran. I see a comment in that routine:

[plain]      complex*8 x(n)
      !tms 20080112 for intel fortran no type mismatch allowed
      real*4 xr(n*2)[/plain]

suggesting to me that the author recognized the error and had some workaround, but I'm not entirely sure what is intended in the rest of the routine.

I note that in cross.f, there is a rtimec declared with type COMPLEX*8 that is equivalenced to rtime, so if one passes rtimec instead then the mismatch is avoided. Unfortunately, there are a bunch of other type mismatch errors in the code that need to be dealt with, but I think you get the idea.

You said that the compilation aborted, but did you not see the error message preceding that?

error #6633: The type of the actual argument differs from the type of the dummy argument. [RTIME]

[scrognoid]

#6633 was not the error I was asking about. These old FFT routines do that, and I can work around them in several ways.

#5508 is no longer happening. I'm only a little surprised, since it made no sense - there was no other declaration that I could find. I guess the compiler just got confused and need a long weekend to get over it.

[scrognoid]

The original error 5508 keeps popping up. I can get rid of it if I quit VS2005, delete the contents of Debug and restart VS2005.

What is Clean supposed to do? Shouldn't it delete the files in Debug? It doesn't. The contents of my entire Solutions directory, including subfolders, are unchanged before and after Clean.

[Les_Neilson]

Quoting - scrognoid

The original error 5508 keeps popping up. I can get rid of it if I quit VS2005, delete the contents of Debug and restart VS2005.

What is Clean supposed to do? Shouldn't it delete the files in Debug? It doesn't. The contents of my entire Solutions directory, including subfolders, are unchanged before and after Clean.

If you look at Project->Properties->General you should see under "Extensions to delete on Clean" a list of file extensions. (semi-colon seperated) for both Debug and Release configurations.
If the list is empty or has been incorrectly modified then clean will not delete the appropriate files.

Les

[scrognoid]

Ah hah. "Clean Solution" does nothing (?!) Project>Clean does remove .obj and .mod as per your tip.

What are __genmod.f90 for and do I want to add them to my clean list?

[Steven_L_Intel1]

Quoting - scrognoid

Ah hah. "Clean Solution" does nothing (?!) Project>Clean does remove .obj and .mod as per your tip.

What are __genmod.f90 for and do I want to add them to my clean list?

Those are the sources for the generated interface modules. You don't need to clean them as they're just for your reference - the compiler does not read them.