- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you provide more details as to what you saw?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here's the file
subroutine
sub(x) !DEC$ ATTRIBUTES Decorate: 'MySub' :: sub real xx = 2*x
returnend subroutine
subThe BuildLog is attached.
Gerry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page