Intrinsic Function DMOD not recognised - Compilation error for TrnSys Source Code

[Jeannieboef]

Dear Group,
Whilst using the unrecommended g95 compiler I've come accross some
interesting issues.
1) JFIX, is an intel library function which converts many types to
INTEGER(4), so I'm using INT instead.
2) There is a syntax in the formating section that looks like this:
A<maxDescripLength> which is supposed to read in maxDescripLength = 25
and combine it to the format to make A25. This is not working, I am
hard coding this.
3) The spacing of 5 empty spaces is crutial for the line continuation
from the left margin. Tab spaces must be deleted and replaced with
spaces.
4) The intrinsic funtion DMOD is not found. Does anyone know an
alternitive or what it means?
Kind regards,
Jean

[Larry Baker]

Jean,

What you are seeing is more likely DEC Fortran extensions, which
predate the Intel compilers. The DEC Fortran team eventually became
the Intel Fortran team.

On 13 Mar 2012, at 2:58 AM, Jeannieboef wrote:

> 1) JFIX, is an intel library function which converts many types to
> INTEGER(4), so I'm using INT instead.

JFIX was a non-standard variant of IFIX (from Fortran-77, one of the
specific intrinsic functions for generic intrinsic function INT) from
the days when you might tell the compiler to use 16-bits for the
default Integer size (non-compliant).

> 2) There is a syntax in the formating section that looks like this:
> A<maxDescripLength> which is supposed to read in maxDescripLength = 25
> and combine it to the format to make A25. This is not working, I am
> hard coding this.

This was a DEC Format statement extension that used a variable in the
I/O list to specify the field width. Today, you could accomplish the
same thing by dynamically writing a Format into a character variable
using an internal write, then using that character variable as the
Format in an I/O statement.

> 3) The spacing of 5 empty spaces is crutial for the line continuation
> from the left margin. Tab spaces must be deleted and replaced with
> spaces.

Tabs in liu of spaces at the start of a line in fixed format Fortran
source is commonly permitted by a number of Fortran compilers, but has
never been legal Fortran.

> 4) The intrinsic funtion DMOD is not found. Does anyone know an
> alternitive or what it means?

DMOD is the specific intrinsic function for the MOD generic intrinsic
function when the argument is Double Precision. It returns a Double
Precision result. It is standard Fortran. But, you might want to
change it to use the MOD generic intrinsic function so that it
automatically chooses the proper specific intrinsic function depending
on the type of the argument.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

[jfh]

On Mar 13, 10:58 pm, Jeannieboef <jeannieb...@googlemail.com> wrote:
> Dear Group,
> Whilst using the unrecommended g95 compiler I've come accross some
> interesting issues.

...

> 4) The intrinsic funtion DMOD is not found. Does anyone know an
> alternitive or what it means?

It works OK with (g95 0.92!) Jun 24 2009 and that isn't even the
latest available. Is Jean using a really out-of-date version?

-- John Harper

[jeannieboef]

Dear Larry,
Thanks for all the help. Do you know how I deal with the old style !DEC
$ATTRIBUTES to link up other dlls? I find these often in my Source Code.
Regards,
Jean

Sent from my iPhone

[Larry Baker]

You will have to research what their meaning is and then deduce why
they are being used. I think the only time I have ever used them was
to force a common alignment on an Alpha processor so that it was
exactly the same as on a VAX processor. You will want to search the
Internet for a DEC Fortran manual.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

On 27 Mar 2012, at 9:53 AM, jeannieboef wrote:

> Dear Larry,
> Thanks for all the help. Do you know how I deal with the old style !

> DEC$ATTRIBUTES to link up other dlls? I find these often in my

[jeannieboef]

dear Larry, dear group,

I have the following situation. There exists a kind of "main" dll
called TrnDll.dll which was written and compiled in intell visual
fortran. In that compiled code there are !DEC$ Atributes Dllimport
lines which 'decorate' the subroutine or function names as I
understand it. Other external dlls, like the one I'm working on, are
compiled to be linked to it. The source code I'm trying to use has
been modified by me for compilation with the g95 compiler, but the !DEC
$ Attributes DllExport line (directly the main subroutine name and
some of the function names) is not supported by g95. gcc has, I think,
a !gcc$ dllexport statement which is in the gcc 4.x.x directive.
gfortran has implimented this. Will this work in g95? is this a simple
find and replace? are there alternitives?

I have found some explainations of what the !DEC$ statements do, but
as I'm not a programmer explanations of how the callee or called
function pops variable from a stack is pretty Greek to me.

Your experience is sorely needed in lighting my way.

Kind regards,

Jean

Sent from my iPhone

[Larry Baker]

This is beyond my experience with DEC Fortran. If I had to guess,
what you are seeing are instructions to the compiler for performing
name mangling of external references so that they are compatible with
entry point names created by a different compiler. I remember
something about Microsoft compilers adding the number of bytes in the
argument list to the name of an entry point. Thus, if you wrote a
subroutine:

Subroutine JUNK( intarg )

The actual entry point would be named JUNK@4.

Perhaps this was only for their Fortran PowerStation compiler.

I would guess the code you have is calling C routines and is trying to
get the external reference correct. g95/gfortran do not mangle names
like that. But, they can and may by default (varies with compiler and
version) prepend or append extra underscores. A lot of times you will
see makefiles with --no-second-underscore for g95/gfortran to deal
with that.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

On 28 Mar 2012, at 11:38 PM, jeannieboef wrote:

> dear Larry, dear group,
>
> I have the following situation. There exists a kind of "main" dll
> called TrnDll.dll which was written and compiled in intell visual
> fortran. In that compiled code there are !DEC$ Atributes Dllimport
> lines which 'decorate' the subroutine or function names as I
> understand it. Other external dlls, like the one I'm working on, are
> compiled to be linked to it. The source code I'm trying to use has
> been modified by me for compilation with the g95 compiler, but the !

> DEC$ Attributes DllExport line (directly the main subroutine name

> and some of the function names) is not supported by g95. gcc has, I
> think, a !gcc$ dllexport statement which is in the gcc 4.x.x
> directive. gfortran has implimented this. Will this work in g95? is
> this a simple find and replace? are there alternitives?
>
> I have found some explainations of what the !DEC$ statements do, but
> as I'm not a programmer explanations of how the callee or called
> function pops variable from a stack is pretty Greek to me.
>
> Your experience is sorely needed in lighting my way.
>
> Kind regards,
>
> Jean
>
> Sent from my iPhone
>
> On 27.03.2012, at 19:21, Larry Baker <ba...@usgs.gov> wrote:
>
>> You will have to research what their meaning is and then deduce why
>> they are being used. I think the only time I have ever used them
>> was to force a common alignment on an Alpha processor so that it
>> was exactly the same as on a VAX processor. You will want to
>> search the Internet for a DEC Fortran manual.
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> ba...@usgs.gov
>>
>> On 27 Mar 2012, at 9:53 AM, jeannieboef wrote:
>>
>>> Dear Larry,
>>> Thanks for all the help. Do you know how I deal with the old

>>> style !DEC$ATTRIBUTES to link up other dlls? I find these often in

[jeannieboef]

Dear all,

I have found the following...could this help me? How would I implement it?

dllexport

Found in versions: 2.8-3.4

Description:

     On Microsoft Windows targets the `dllexport' attribute causes the
     compiler to provide a global pointer to a pointer in a dll, so
     that it can be referenced with the `dllimport' attribute. The
     pointer name is formed by combining `_imp__' and the function or
     variable name.

     Currently, the `dllexport'attribute is ignored for inlined
     functions, but export can be forced by using the
     `-fkeep-inline-functions' flag. The attribute is also ignored for
     undefined symbols.

     When applied to C++ classes. the attribute marks defined
     non-inlined member functions and static data members as exports.
     Static consts initialized in-class are not marked unless they are
     also defined out-of-class.

     On cygwin, mingw and arm-pe targets, `__declspec(dllexport)' is
     recognized as a synonym for `__attribute__ ((dllexport))' for
     compatibility with other Microsoft Windows compilers.

     Alternative methods for including the symbol in the dll's export
     table are to use a .def file with an `EXPORTS' section or, with
     GNU ld, using the `--export-all' linker flag.

   You can specify multiple attributes in a declaration by separating

Sent from my iPhone

On 29.03.2012, at 20:47, Larry Baker <ba...@usgs.gov> wrote:

This is beyond my experience with DEC Fortran.  If I had to guess, what you are seeing are instructions to the compiler for performing name mangling of external references so that they are compatible with entry point names created by a different compiler.  I remember something about Microsoft compilers adding the number of bytes in the argument list to the name of an entry point.  Thus, if you wrote a subroutine:

     Subroutine JUNK( intarg )

The actual entry point would be named JUNK@4.

Perhaps this was only for their Fortran PowerStation compiler.

I would guess the code you have is calling C routines and is trying to get the external reference correct.  g95/gfortran do not mangle names like that.  But, they can and may by default (varies with compiler and version) prepend or append extra underscores.  A lot of times you will see makefiles with --no-second-underscore for g95/gfortran to deal with that.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

On 28 Mar 2012, at 11:38 PM, jeannieboef wrote:

dear Larry, dear group,

I have the following situation. There exists a kind of "main" dll called TrnDll.dll which was written and compiled in intell visual fortran. In that compiled code there are !DEC$ Atributes Dllimport lines which 'decorate' the subroutine or function names as I understand it. Other external dlls, like the one I'm working on, are compiled to be linked to it. The source code I'm trying to use has been modified by me for compilation with the g95 compiler, but the !DEC$ Attributes DllExport line (directly the main subroutine name and some of the function names) is not supported by g95. gcc has, I think, a !gcc$ dllexport statement which is in the gcc 4.x.x directive. gfortran has implimented this. Will this work in g95? is this a simple find and replace? are there alternitives?

I have found some explainations of what the !DEC$ statements do, but as I'm not a programmer explanations of how the callee or called function pops variable from a stack is pretty Greek to me.

Your experience is sorely needed in lighting my way.

Kind regards,

Jean

Sent from my iPhone

On 27.03.2012, at 19:21, Larry Baker <ba...@usgs.gov> wrote:

You will have to research what their meaning is and then deduce why they are being used.  I think the only time I have ever used them was to force a common alignment on an Alpha processor so that it was exactly the same as on a VAX processor.  You will want to search the Internet for a DEC Fortran manual.

Larry Baker

US Geological Survey

650-329-5608

ba...@usgs.gov

On 27 Mar 2012, at 9:53 AM, jeannieboef wrote:

Dear Larry,

Thanks for all the help. Do you know how I deal with the old style !DEC$ATTRIBUTES to link up other dlls? I find these often in my Source Code.

Regards,

Jean

Sent from my iPhone

On 13.03.2012, at 20:10, Larry Baker <ba...@usgs.gov> wrote:

Jean,

What you are seeing is more likely DEC Fortran extensions, which predate the Intel compilers.  The DEC Fortran team eventually became the Intel Fortran team.

On 13 Mar 2012, at 2:58 AM, Jeannieboef wrote:

1) JFIX, is an intel library function which converts many types to

INTEGER(4), so I'm using INT instead.

JFIX was a non-standard variant of IFIX (from Fortran-77, one of the specific intrinsic functions for generic intrinsic function INT) from the days when you might tell the compiler to use 16-bits for the default Integer size (non-compliant).

[Tobias Burnus]

On Mar 29, 8:38 am, jeannieboef <jeannieb...@googlemail.com> wrote:
> The source code I'm trying to use has
> been modified by me for compilation with the g95 compiler, but the !DEC
> $ Attributes DllExport line (directly the main subroutine name and
> some of the function names) is not supported by g95. gcc has, I think,
> a !gcc$ dllexport statement which is in the gcc 4.x.x directive.
> gfortran has implimented this. Will this work in g95? is this a simple
> find and replace? are there alternitives?

To my knowledge g95 does not have - and my impression is that g95 is
currently not developed. (Though, the homepage changed to "Watch this
space, returning soon." a while ago.)

If you need "dllexport", I think the easiest would be to use gfortran;
I think you can also create some DEF files for the linker, but I never
quite understood how that works.

You likely need to use the attribute "stdcall" in addition. I don't
know the Visual Fortran compiler, but I could imagine that it used it
by default in the old versions.

Note that with gfortran, in order to have a better compatibility with
calling C, you should use BIND(C). For a description of Bind(C) and
also for gfortran's dllimport/stddecl support ("Directives"), see
http://gcc.gnu.org/onlinedocs/gfortran/Mixed_002dLanguage-Programming.html

On Mar 29, 8:38 am, jeannieboef <jeannieb...@googlemail.com> wrote:
> I have the following situation. There exists a kind of "main" dll
> called TrnDll.dll which was written and compiled in intell visual
> fortran. In that compiled code there are !DEC$ Atributes Dllimport
> lines which 'decorate' the subroutine or function names as I
> understand it.

No, DLLIMPORT does not decorate the names - that's what "stdcall".
With "stdcall", the arguments are popped by the callee and not by the
caller. Thus, to make it safer, the name ends with @<number> where the
"number" is the number of bytes the callee has to pop of the stack.
With cdecl (the default with most newer compilers - and also the
default for 64bit Windows), the caller pops of the stack. Besides the
@<number> there are also other decorations, depending on the calling
method and on the operating system; e.g. an initial or trailing "_".

On Mar 29, 8:47 pm, Larry Baker <ba...@usgs.gov> wrote:
> I would guess the code you have is calling C routines and is trying to
> get the external reference correct. g95/gfortran do not mangle names
> like that.

Well, gfortran does - with the "stdcall" declaration. However, it
simply decorates the default name. Thus for "subroutine foo", one gets
"foo_" when then gets decorated. To have that properly decorated, use
subroutine foo() BIND(C)
which decorates "foo" (not "foo_") and allows one to specify another
binding name (also case sensitive).

> But, they can and may by default (varies with compiler and
> version) prepend or append extra underscores. A lot of times you will
> see makefiles with --no-second-underscore for g95/gfortran to deal
> with that.

Note that "stdcall" - which is used by most (but not all!) of
Microsoft's DLLs - differs by more than the name from the GCC's
default (cdecl): Namely, the way arguments are popped from the stack.
Ignoring that risks to either pop too much from the stack - or to
eventually run out of stack space because to little is popped.

One way out is to use a C wrapper - but also there one needs to be
careful to use the right calling convention. For Window ABI functions,
"windows.h" already has them marked by STDCALL when needed, but if you
access a nonstandard file, you need to be careful.


I additionally want to point out another gotcha: One needs to be
careful with interoperability between different compilers. In
particular, how single-precision variables are passed - and how
complex functions return their value. Many compilers follow f2c, some
the platform ABI. (Gfortran does the latter.) Thus, if you access some
programs compiled with a different Fortran compiler ...

See: http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-ff2c-229

If you use strings: Using BIND(C) only passes the bare string. While
most Fortran programs (including g95 and gfortran) pass additionally
as hidden argument additionally the string length (after all the
normal arguments). Thus, if you use BIND(C), to access some other
Fortran program, you need to manually pass the string length.


Good luck!

Tobias