IA32/EM64T with VC++/IVF

[g_f_thomas]

When I try to build an EM64T mixed language project from its IA32 it succeeds if IVF calls VC++ but not the other way round. Is this to be expected? I did a search on this but couldn't follow the subtleties involved. Do I need IC++ and some special release of the Platform SDK and to debug in IDB, or what?

Thanks,

Gerry

[Steven_L_Intel1]

Need more info. What version IVF? What version VC++? What goes wrong?

In order to use C++ from Visual Studio, you need VS2005, and unless you have the Standard Edition, you must do a Custom Install and select "x64 Compiler and Tools" (or go back and "change" the VS2005 install later.)

Assuming you have VS2005 (with the x64 support) and IVF10, there should be no problem building mixed-language solutions in VS05. You do not need a SDK nor do you need Intel C++ (though of course we'd love it if you did.)

I've never seen a problem quite like you describe, so I need more data.

If you're NOT using VS2005, then you have to build from the command line and install the Platform SDK to get its C++ compiler.

[g_f_thomas]

I got it to work. It looks like the Alias attribute functions differently on ia32 and em64t platforms and that ivf10x64 regards Decorate as not being a valid attribute for DEC$.

Gerry

[Steven_L_Intel1]

ALIAS behaves exactly the same on both platforms, and DECORATE is accepted on both platforms. It is true that the standard decoration rules differ, however, in that most symbols are not decorated at all, so DECORATE would tend to have no effect on x64, but it is accepted (as is STDCALL which effects only name case and pass-by-value).

Can you provide more details as to what you saw?

[g_f_thomas]

On both ia32 and i64 (aka em64t) use of Decorate causes the compiler to issue the message:

Error: Not a valid attribute for the DEC$ ATTRIBUTES directive. [DECORATE]
1>compilation aborted for ... (code 1)

When ia32 and i64 build they dumpbin the symbols, _x and x, say, respectively and the Alias for ia32 would read

Alias : '_x'

and for i64 would read

Alias :'x'

In C++ the invocation would read

x(...)

whatever the platform. All of this is reproducible with IVF 10.0.027 in VS 2005 Pro (with all doodads, Platform SDK, SP1+) on XP Pro/SP2 and Vista U and a colleague confirms that i64 apps run on a live updated XP x64 2003 Server on an Intel processor.

The varying behavior of Alias on i64 has been noted here

http://docs.hp.com/en/T1918-96029/ch01s03.html#cacccdcf

on a non Microsoft OS.

Gerry

[g_f_thomas]

On both ia32 and i64 (aka em64t) use of Decorate causes the compiler to issue the message:

Error: Not a valid attribute for the DEC$ ATTRIBUTES directive. [DECORATE]
1>compilation aborted for ... (code 1)

When ia32 and i64 build they dumpbin the symbols, _x and x, say, respectively and the Alias for ia32 would read

Alias : '_x'

and for i64 would read

Alias :'x'

In C++ the invocation would read

x(...)

whatever the platform. All of this is reproducible with IVF 10.0.027 in VS 2005 Pro (with all doodads, Platform SDK, SP1+) on XP Pro/SP2 and Vista U and a colleague confirms that i64 apps run on a live updated XP x64 2003 Server on an Intel processor.

The varying behavior of Alias on i64 has been noted here

http://docs.hp.com/en/T1918-96029/ch01s03.html#cacccdcf

on a non Microsoft OS.

Gerry

[Steven_L_Intel1]

Example showing the DECORATE problem, please.

I read that HP article but don't see how it is relevant. Yes, as I mentioned earlier, the default decoration rules are different for Windows on IA-32 and Intel 64. On Linux, the Fortran convention is that Fortran routines have a trailing underscore, which is what that HP article discusses.

[g_f_thomas]

2:25:32 PM

I've already pasted the VS output pane that IVF generates on use of Decorate. What do you get?

HP'sstatement that that "Some experimentation with the alias form may be necessary as experience demonstrates neither form has always been both accepted and honored by every release of the Intel compilers" is equally applicable to inter ivf compiler inconsistencies for Windows 32 and 64. To boot, Decorate should be fixed or itswoolly treatment in the documentation revised.

Gerry

[Steven_L_Intel1]

I don't see that you included the source that generated that message. Here's an example I tried:

F:MyProjects>type t.f90
program test
interface
subroutine sub (x)
!DEC$ ATTRIBUTES DECORATE,ALIAS:"Sub" :: sub
real x
end subroutine sub
end interface

call sub(3.0)

end
F:MyProjects>ifort t.f90
Intel Visual Fortran Compiler for applications running on Intel 64, Version 10.0 Build 20070613 Package ID: W_FC_C_10.0.026
Copyright (C) 1985-2007 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.

-out:t.exe
-subsystem:console
t.obj
t.obj : error LNK2019: unresolved external symbol Sub referenced in function MAIN__
t.exe : fatal error LNK1120: 1 unresolved externals

Note that the DECORATE attribute was accepted and that it had no effect, which is correct on Intel 64.

I also do not agree with the HP text regarding ALIAS. The author of that text is confused.

DECORATE has had some issues, especially when /iface was used, but I'm not aware of anything in the last year or so. The HP text did not mention DECORATE.

[g_f_thomas]

The example you tried doesn't compile so to draw inference from it is simply wrong. Here's a sample that works:

subroutine sub [Decorate, Alias:'_MySuB'](x)
real x[REFERENCE]
x = 2*x
return
end subroutine sub

Since the thread deals with mixed language solutions where the Alias is required and the Decorate may or may not be, here is a C++ driver that statically links to the f95 'sub' which C++ wants to reference as 'MySub':

#include

extern "C" void MySuB(float *x);
void main ();

void main ()
{
float x = 2.5;
MySuB( &x);
printf("%f ", x);
}

Tips:
1. include the _CRT_SECURE_NO_WARNINGS preprocessor define
2. link both the f95 and c++ against the same MT DLLs
3. don't autogenerate interfaces as these don't currently honor DEC$ attributes
4. otherwise accept all default settings

If you play around with Decorate, Alias, and _MySub/MySub across platforms, one finds that when used alone, Decorate does nothing but cause the comiler to issue 'Error: Not a valid attribute for the DEC$ ATTRIBUTES directive' but in concert with Alias it obviates the keyboarding of _.

How was http://software.intel.com/en-us/forums//topic/41796 resolved?

Gerry

[Steven_L_Intel1]

Gerry, the example I gave certainly does compile. It didn't link only because I wanted to show what external symbol was used. You have not yet shown me an example where DECORATE is rejected by the compiler on Intel 64.

I also recommend against using the Microsoft PowerStation square bracket syntax for attributes that MS didn't support, such as DECORATE. This is unsupported and may break without notice. If in fact the example you have (but have not shown) uses DECORATE in the MS square bracket syntax, then I recommend changing to the documented and supported syntax.

[g_f_thomas]

If you can't verify for yourself that ivf produces the following output using the instructions provided (with or without MSFP [ ] style):

------ Rebuild started: Project: Decor2, Configuration: Debug|x64 ------

Deleting intermediate files and output files for project 'Decor2', configuration 'Debug|x64'.

Compiling with Intel Fortran Compiler 10.0.027 [Intel 64]...

Test2.F90

C:UsersOwnerDocumentsVisual Studio 2005ProjectsDecorDecorTest2.F90(2) : Error: Not a valid attribute for the DEC$ ATTRIBUTES directive. [DECORATE]

compilation aborted for C:UsersOwnerDocumentsVisual Studio 2005ProjectsDecorDecorTest2.F90 (code 1)

Build log written to "file://C:UsersOwnerDocumentsVisual Studio 2005ProjectsDecorDecor2x64DebugBuildLog.htm"

Decor2 - 2 error(s), 0 warning(s)

---------------------- Done ----------------------

or

------ Rebuild started: Project: Decor2, Configuration: Debug|x64 ------

Deleting intermediate files and output files for project 'Decor2', configuration 'Debug|x64'.

Compiling with Intel Fortran Compiler 10.0.027 [Intel 64]...

Test2.F90

Creating library...

Build log written to "file://C:UsersOwnerDocumentsVisual Studio 2005ProjectsDecorDecor2x64DebugBuildLog.htm"

Decor2 - 0 error(s), 0 warning(s)

---------------------- Done ----------------------

then I can't be of further help.

Once again:

How was http://software.intel.com/en-us/forums//topic/41796

resolved?

Gerry

[Steven_L_Intel1]

You can certainly help - post the source for your test2.f90. You have not done that, as far as I can see. The only code you have posted compiles fine (as you said). Every example I throw at the EM64T compiler with DECORATE passes.

As for the other thread, like this one, no actual example was provided (in that case, the C code.) My crystal ball is out for repairs.

[g_f_thomas]

Test2.f90 or whatever you want to call it is

subroutine sub [Decorate, Alias:'_MySuB'](x)
real x[REFERENCE]
x = 2*x
return
end subroutine sub

as previously posted.

I resent your repeated insinuation that I'm fabricating what ivf 10.0.027 issues on demand. If you're having such trouble verifying this fact why dont you check among your colleagues to see if anyone remembers wording the error message in question. BTW, the only code that you have shown to support your assertion was broken.

Gerry

[Steven_L_Intel1]

Again, the code I posted is NOT broken and it effectively demonstrates my position.

Here's what I get with your test case:

F:MyProjects>type t.f90
subroutine sub [Decorate, Alias:'_MySuB'](x)
real x[REFERENCE]
x = 2*x
return
end subroutine sub
F:MyProjects>ifort -c t.f90
Intel Visual Fortran Compiler for applications running on Intel 64, Version 10.0 Build 20070809 Package ID: W_FC_C_10.0.027
Copyright (C) 1985-2007 Intel Corporation. All rights reserved.


F:MyProjects>

As I commented earlier, this use of DECORATE with the MS syntax is not supported, but it seems to work at the present time. What switches are you specifying on the command line?

[g_f_thomas]

The output from your example

-out:t.exe
-subsystem:console
t.obj
t.obj : error LNK2019: unresolved external symbol Sub referenced in function MAIN__
t.exe : fatal error LNK1120: 1 unresolved externals

indicates that while it compiled it failed to link. A reasonable view is that the example is broken and demonstrates nothing other than it ought to be fixed.

In

http://software.intel.com/en-us/forums//topic/41796

you state to the OP

"Take off the alias attribute - you don't need it and it's incorrect on EM64T"

and nothing changed for the OP with the intimation that he was confused, just like the guy from HP?

In response to Jim D's suggestion

"If ALIAS for leading _ is incorrect on EMT64 (sic em64t) I am sure then that this is a common mistake. Therefore I would like to submit the suggestion that a compiler Information message be issued when ALIAS is use to declare an _'d alias"

you state

"I don't think that is appropriate. The assumption is that the user knows what the alias should be. We introduced the DECORATE attribute if all you want to do is change the "spelling" of the name, and I would recommend its use instead of including the decoration in the alias."

So why not takethis advise to others and remove the Alias. I don't use the command line, I use VS. As I mentioned before Decorate, when used alone, with or without the MS syntax, spawns an error.

Gerry

[Steven_L_Intel1]

Gerry,

The example I gave fails to link deliberately. I used that as a convenience to display the external symbol generated by the compiler. Showing it another way would have been more complicated. I'm sorry you were confused by this. The example does demonstrate that no compiler message is generated for proper use of DECORATE, which was my intention.

I have asked the developers to look at the compiler sources and they cannot find any way in which this message would be emitted. I don't doubt that you are seeing it, but there's something else in play that is not yet shown here. In VS, go to the Fortran -> Command Line property page and copy and paste the set of command options used. Or paste the build log showing the invocation of the compiler and the output. Even better would be to open an issue with Intel Premier Support and attach a ZIP of the project that is getting this error. I'd certainly like to see it.

I'm not sure where you're going with the reference to the other thread. As I said earlier, no test case was provided so whatever the other poster's problem was, it related to something not shown. What that might be, I don't know, and I don't see that it is relevant to this discussion.

It is my position that one should use DECORATE instead of including decoration in ALIAS. That's cross-platform portable and is why we created it. It works.

[g_f_thomas]

Here's the file

subroutine

sub(x) !DEC$ ATTRIBUTES Decorate: 'MySub' :: sub real x

x = 2*x

return

end subroutine

sub

The BuildLog is attached.

Gerry

[Steven_L_Intel1]

Ah, now I see. You misunderstand the syntax.

DECORATE is not a substitute for ALIAS, it is a keyword all by itself that adds to it. What you want is:

!DEC$ ATTRIBUTES DECORATE, ALIAS:'MySub' :: sub

Now do you understand why I was insisting on seeing an actual test case?

[g_f_thomas]

No I did not. In all of my postswith the exception of the last

!DEC$ ATTRIBUTES DECORATE, ALIAS:'MySub' :: sub

was used. Why was the last different? so that you would finally get it. At least twice I alluded to the use of DECORATE alone as precipitating an error. The purpose ofDECORATE is to remove the need to type an underscore of the ALIAS'ed symbol across platforms.Contrary to what you claimed in the previous thread, both are required unless youwant to type the _ in Win32 and remember to omit it in Intel 64. I know which Iprefer as I abhor use of the underscore.

To end on a more upbeat vain,EM64T is handy and easy to use for those of us who make do in a 32 bit world.

Gerry

ps How does a compiler emit errors that no one has anticipated?

[Steven_L_Intel1]

The last had a syntax error, the others did not. You get the error message only with the syntax error. It was not just "DECORATE alone" but you had used DECORATE as if it were a replacement for ALIAS, with a colon and a string following it. This is incorrect syntax. If you had shown this line earlier, instead of your example with the MS bracket syntax (where, note, you correctly include ALIAS), then we would have been done much sooner.

I think you misunderstood what I wrote earlier. I was trying to say that you should use ALIAS to specify the "spelling" of the name, including mixed case if needed, and DECORATE to apply any platform and calling-convention required decoration such as leading underscore or trailing @n. By including decoration inside the ALIAS, you reduce portability.

Compilers are very complicated pieces of code. Sometimes it is not at all obvious, looking at a particular spot, what sort of program would cause it to end up there. Only when we have an actual source to run through the compiler can we trace the path and figure out what happened. This is why test cases are critically important and we can't, as some people assume, deduce a problem by, for example, looking at generated code or an error message.

The error message given in this case could certainly be improved so that you would have more quickly recognized the problem. I'll agree that it is misleading. But I'll also note that this message would be given on all of our platforms, not just EM64T as you initially indicated.