error #5508: "This is in conflict with a previous declaration."

[WSinc]

When I installed it, I got an error I have never seen before in this project.

I didn't change ANY code.
It gives me an error #5508:
"This is in conflict with a previous declaration."

This was the only declaration.
A clean and rebuild does NOT work.

Now I can't compile my project at all.

[WSinc]

Here is more info:

Error 3 error #5508: Declaration of routine 'GENRATE' conflicts with a previous declaration C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsConsole1Console1generate.F90 1
Error 4 Compilation Aborted (code 1) C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsConsole1Console1generate.F90 1

I tried changing the name of the routine. It's only mentioned in three places, according to my project search:
1) Where it's called (once)
2) the SUBROUTINE statement, and
3) The END SUBROUTINE statement.

Is there a way around this (other than going back to build #66)?

[WSinc]

Another interesting development:

I changed ONE LINE of code in the main program, and I got the SAME ERROR message for that one also.
I did not change the declaration for the program.

DON'T DOWNLOAD THIS BUILD ! ! ! ! ! ! !

[Ron_Green]

Quoting - billsincl

Here is more info:

Error 3 error #5508: Declaration of routine 'GENRATE' conflicts with a previous declaration C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsConsole1Console1generate.F90 1
Error 4 Compilation Aborted (code 1) C:Documents and SettingsWilliamMy DocumentsVisual Studio 2008ProjectsConsole1Console1generate.F90 1

I tried changing the name of the routine. It's only mentioned in three places, according to my project search:
1) Where it's called (once)
2) the SUBROUTINE statement, and
3) The END SUBROUTINE statement.

Is there a way around this (other than going back to build #66)?

Well this is an odd one for sure.

Is it possible the source file 'generate.F90' got added to the project twice? Is there just one instance of it in your "Source Files"?

If you highlight the source file 'generate.F90' and right-click + Compile, do you get that error message?

Perhaps you could clean the solution, zip up the whole solution directory and attach it?

ron

[TimP]

Accepting multiple declarations of the same identifier in the same subroutine is a well-known extension of certain legacy compilers. Since 20 years ago, compilers are required at least to complain about the violation of standard, unless you set a special option to permit it. Intel Fortran never accepted this violation, as there is no way to guess which one to use, should they conflict. Except that it may possibly have slipped past earlier compilers. This has been discussed previously on this forum; maybe you should complain if the search tool can't find it.

[bmchenry]

Realize that the most convenient part of updates is that you can roll back to the prior while resolving why you are
e getting errors.
Tools->Options->Intel Visual Fortran->Compilers
and select the prior install (72) if you are having troubles with 74.
The new errors may be related to interface declarations/etc and i would check if maybe an option has been reset by the update.
I too amy experiencing some strange errors but kinda like the challenge to clean more of my code up to conform with the standard (and in the meantime can continue moving forward by rolling the version back, as required).

brian

[bmchenry]

turn off the 'Generate Interface Blocks' option of

Project menu->"your project" Properties->Fortran->Diagnostic->Generate Interface Blocks

i was experiencing similar errors and eliminated them by this simple change.

brian

[onkelhotte]

Quoting - bmchenry

turn off the 'Generate Interface Blocks' option of

Project menu->"your project" Properties->Fortran->Diagnostic->Generate Interface Blocks

i was experiencing similar errors and eliminated them by this simple change.

brian

Ive got the same error. The subroutine, the compiler is complaining about, is absolutely only declared once.

Cleaning the solution or deleting the debug folder by hand, nothing helped.

The Generate Interface Blocks option is in my opinion very useful, so I wont turn it off, although the project can be compiled without that option. SoI will use the 72 build instead.

Steve is only 2 days away and suddenly everything goes wrong ;-)

Markus

[rase]

I had the same problem and deinstalled build 74 rightaway. Unfortunately build 72 did not work again after removal of 74 although 72 was installed. I had to deinstall 72 to and reinstall it again. The repair function did not help. I had also some peculiar problems with Visual C/C++ build 74.

Again, loud and clear: Do not install build 74!

[bmchenry]

I disagree. The jury is still out on a verdict for build 74.After some initial sputtering, I find build 74 is working fine for me.
After encountering problems I simply used Tools->Options->Fortran->Compiler and set to ver 72.
Then after relaxing, i reapproached build 74 and eliminated the errors (see above) and things are working fine.
Bravo to Intel on the ability to easily swap between versions in the event issues are encountered!

[rase]

Objection, your honour. I expect from an update that it does not generate diagnostic messages which I cannot see a reason for, and never appeared in previous versions. I do not have the time to check each parameter in the options, just in case one of the compiler experts decided to do things differently (or erroneously).

[WSinc]

Quoting - billsincl

When I installed it, I got an error I have never seen before in this project.

I didn't change ANY code.
It gives me an error #5508:
"This is in conflict with a previous declaration."

This was the only declaration.
A clean and rebuild does NOT work.

Now I can't compile my project at all.

I did some further investigation:
1) It generates TWO of each GENMOD in the DEBUG folder. One is of type F90, which makes sense. The other one is typed as a "movie clip." Obviously it can't be a movie clip. Is this normal behavior?
2) I made sure there was only one of the problem subroutines in the project with the same name. So there is no chance for any ambiguity. It only generated a GENMOD for that routine (two of them?), and nowhere else.
3) I can make the error jump to another routine by just chaging one line of code in that routine.
4) deleting ALL of the genmods does not cure the problem. This is the same as a "clean," by the way, but I'm doing it manually.
I can appreciate why turning off the interface option would solve the problem, BUT then I don't get the useful diagnostic tool any more.

[Ron_Green]

In cases such as these where you suspect a new version broke something - please do file a bug report at premier.intel.com. OR if you can clean the project and zip up the entire solution folder and attach the zip file here.

Without a reproducer we cannot determine what is going wrong. We'd like to get to the bottom of this, especially if more than 1 user is seeing this behaviour.

ron

[bmchenry]

The second file is actually the compilation of the first, a MOD file not a movie file.
from the documentation on Genmod:
-----
This option tells the compiler to generate an interface block for each routine (that is, for each SUBROUTINE and FUNCTION statement) defined in the source file. The compiler generates two files for each routine, a .mod file and a .f90 file, and places them in the current directory or in the directory specified by the include (-I) or -module option. The .f90 file is the text of the interface block; the .mod file is the interface block compiled into binary form.

If source is specified, the compiler creates the *_mod.f90 as well as the *_mod.mod files. If nosource is specified, the compiler creates the *_mod.mod but not the *_mod.f90 files. If neither is specified, it is the same as specifying -gen-interfaces source (Linux and Mac OS X) or /gen-interfaces:source
-----

I would venture to guess there is a conflict between the source option and Genmod option. But I'll defer to Intel.
I would suggest you either revert to 72 or turn off genmod option and continue working.
I would call the issue"no biggie" as it's easily avoided by turing the option off.
You don't NEED interface declarations unless you are encountering problems.
And when you create a routine you should create the interface block.
The options should be used to quickly create them for legacy code and then probably should be inserted where needed in your code and the option turned off.
There is a new option to continue compilation on error so you can compile all your routines (hey..maybe it will link??)
from the release notes "You can now specify that project builds should continue on errors using Tools > Options > Intel Fortran > General > Continue on errors"

[John_Mahaffy]

Quoting - billsincl

I'm seeing similar behavior in a very large Fortran project. A couple hundred files compiled successfully before it hit one that produced this message. I have not isolated the special characteristics of this file, but can say that this is unique to the 74 build of Intel.

[Ron_Green]

Given the number of sightings, I think there is a regression with 074. But I need help to get this isolated and fixed, can someone PLEASE attach a reproducer or help me to generate one?

From what I gather, you have modules with INTERFACE blocks - is this for a GENERIC within the module? I need some guidance to get a reproducer.

HELP! :)


ron

[bmchenry]

Ron,

I will post up a small project to your attention to support which when compiled w/o -genmod works fine, but with -genmod on it produces the error.

should be out there shortly
brian

[WSinc]

Quoting - billsincl

When I installed it, I got an error I have never seen before in this project.

I didn't change ANY code.
It gives me an error #5508:
"This is in conflict with a previous declaration."

This was the only declaration.
A clean and rebuild does NOT work.

Now I can't compile my project at all.

Actually, the Character (len=*) interface still doesn't work properly across subroutine boundaries.
Could that have a bearing on this?

[WSinc]

Quoting - bmchenry

Realize that the most convenient part of updates is that you can roll back to the prior while resolving why you are
e getting errors.
Tools->Options->Intel Visual Fortran->Compilers
and select the prior install (72) if you are having troubles with 74.
The new errors may be related to interface declarations/etc and i would check if maybe an option has been reset by the update.
I too amy experiencing some strange errors but kinda like the challenge to clean more of my code up to conform with the standard (and in the meantime can continue moving forward by rolling the version back, as required).

brian

I don't get anything like that.
Under Tools > Options, I don't see "Intel Visual Fortran" anywhere, or anything resembling that.
Where do you see that menu? I sure don't...
I'm using VS 2008. Does that have anything to do with this?
Anyway, I can't roll back to 72, or continue despite errors, like you suggested.
I thought when we use an old standard syntax it converts it to the new standard anyway
(not that we actually see it).
Is there a "cleanup" tool available anywhere?

[bmchenry]

I'm using Net .2003 for INtel. .2005 for salford (.net applications). Haven't messed with 2008 yet.
Could someone with .Net 2008 please post up directions to set back the version?
I can only guess that it may be a 'hidden' menu issue. Check your menu's option for 'show all'.

[onkelhotte]

Quoting - billsincl

I don't get anything like that.
Under Tools > Options, I don't see "Intel Visual Fortran" anywhere, or anything resembling that.
Where do you see that menu? I sure don't...
I'm using VS 2008. Does that have anything to do with this?
Anyway, I can't roll back to 72, or continue despite errors, like you suggested.
I thought when we use an old standard syntax it converts it to the new standard anyway
(not that we actually see it).
Is there a "cleanup" tool available anywhere?

Of course you can switch back the compiler version with VS2008. Im using the professional version:

Markus