ALIAS aliased

[jimdempseyatthecove]

I am attempting to write a multi-language application. Part in IFV 9.1 and part in MS VC++ (VS2005). I am experiencing some problems with

!DEC$ ATTRIBUTES ALIAS : 'MucketyMuck' :: WiddyWiddyDo

The problem is the enquoted string is not consistantly munged up. I get variations on

_MUCKETYMUCK

_mucketymuck

_MucketyMuck

Somtimes it is upcased, other times it is locased and other it keeps the case. But it does not consistently convert case. ALIAS is supposed to use the enquoted string As-Is.

Also, I have problems inserting the enquoted string of some C++ member functions. Uggly as they are they should pass OK in the enquoted string. I don't know if it is a FPP thing as I have the Fortran Preprocessor enabled. I think it chokes on ?? or @@ inside the function name.

Any thoughts?

What would really be nice is to be able to specify an alternate name to the member function of interest.

Lacking that, I think I can create a global variable holding the address of the C++ member function but visibletoIVF (in an IVF friendly naming format). This way I can execute the function via one indirecton as opposed to writting a shell function.

Jim Dempsey

[Steven_L_Intel1]

Actual examples, please. I haven't seen this in my own usage, and I have included the full C++ mangled name in an ALIAS directive without problems.

[jimdempseyatthecove]

In an interfaces file

module QuickThreadInterfaces
...

interface
function QuickThreadInit(qtInit)
!DEC$ ATTRIBUTES ALIAS : '_QuickThreadInit' :: QuickThreadInit
 use QuickThreadInitStructure
 logical :: QuickThreadInit
 type(T_QuickThreadInit) :: qtInit
end function QuickThreadInit
end interface

interface
integer(DWORD) function QuickThreadQueueMain(MainCode)
!DEC$ ATTRIBUTES ALIAS : '_QuickThreadQueueMain' :: QuickThreadQueueMain
 use kernel32
 logical, external :: MainCode
end function QuickThreadQueueMain
end interface
...
end module QuickThreadInterfaces
------------------------------------
In a source file

...
 use QuickThreadInterfaces
...
 if(.not.QuickThreadInit(qtInit)) then
...
 YourQueueMain = QuickThreadQueueMain(MainCode)

-----------------------
The .asm output
...
;;; if(.not.QuickThreadInit(qtInit)) then

 push edi ;135.12
 lea eax, DWORD PTR [ebp-56] ;135.12
 mov DWORD PTR [esp], eax ;135.12
 call _QUICKTHREADINIT ;135.12
...
;;; YourQueueMain = QuickThreadQueueMain(MainCode)

 push edi ;143.20
 mov eax, DWORD PTR [ebp+8] ;143.20
 mov DWORD PTR [esp], eax ;143.20
 call _quickthreadqueuemain ;143.20
------
----------------

QuickThreadInit got upcased, QuickThreadQueueMain got lowcased.

Why?

Jim

[Steven_L_Intel1]

I mean a real, complete, compilable example. If I construct one using your excerpts here, I don't see a problem. Two additional questions:

1. Are these .f90 or .f/.for files?

2. What compiler options are in effect?

[jimdempseyatthecove]

I will have to see if I can make a short simple example that exhibits the problem.

They are F90 files, and a C++ file. I am trying to make a common library to be used by both F90 and C++ applications. I have a library written in F90 that works. I want a C++ library with classes and such that works too. Having a single library that works will be best for maintenance porposes. I prefer to have the library in C++ due to the fact that some of the intrinsics are inlined (the Interlocked...). Also I don't want to have to use shell functions. Passing a dozen arguments to a shell function which passes the same dozen arguments to a dinky routine isn't my idea of efficency.

It would be nice if there were a hack orfeature in MS VC++ which permits a function to have multiple names. One that C++ is happy about, and one the IVF is happy about.

Something like

#pragma ALIAS "AlternateName" SomeClass::MemberFuncion

Let C++ keep the decorated name, let the rest of the world use the alternate name.

I did manage to get the application linked. Had to work through the link error messages changing name spelling cases here and there. It works today, don't have much confidence it will work after next version update of IVF or MS VC.

Jim

[Steven_L_Intel1]

If the compiler is not behaving as documented, we want to know about it. Your post is the first I have seen saying that text inside an ALIAS is not honored. Please do come up with a complete example and then submit it to Intel Premier Support.

The symptoms you describe suggest to me that neither ALIAS is being recognized, for whatever reason,and that in one case you have ATTRIBUTES C for a routine, hence the downcase, and for the other no ATTRIBUTES C which makes it upcased. Common errors I have seen include directives going past column 72 in fixed-form source and misspellings of the routine name in the directive.

[jimdempseyatthecove]

When (if) I have time, I will see if I can write a simple failing example. For now I am back-logged with work.

I did experiment with the placement of the declaration of the return arg (on function statement line, and as type declaration inside function body), and on use or absense of use of "use kernel32". No difference. It was behaving as if an internal default for ATTRIBUTES was being used and flipped. As a work around that "should" work in all cases I am falling back to naming the shell functions with all upper case. Makes reading difficult - but it works, always.

I have a question on a different topic, will poste a new thread.

Jim