Issue from IVF 9.0 to IVF 10.1 
Author Message
 Issue from IVF 9.0 to IVF 10.1

I have just updated my fortran compiler from IVF 9.0 to 10.1 and I have my
suite of DLLs, that I can't link successfully because of some LNK2019
unresolved external symbols in my source code. These Fortran files are
correctly compiled, but it is the linker to complain for, while the IVF v9.0
linker linked the same sources without any issue.

I admit that the calling and called functions are badly formatted, because
of the implicit variables definition and the not-so-precise type matching,
but that's the source code I got from my colleagues and I have to run soon.

This is the function being called:

SUBROUTINE
ASSEMBLABLK(NA,NCOL,A,NRIFA,NEQ,NBLOCK,LBLOK,NUMEL,KERR,NEQUAZ,KGEON,KEXIT)

  IMPLICIT REAL*8(A-H,O-Z)
  DIMENSION NA(NEQ),A(LBLOK),NCOL(NBLOCK)
  DIMENSION NRIFA(2*LBLOK)
...

The part of the subroutine calling this is here:

  IMPLICIT REAL*8 (A-H,O-Z)

  ALLOCATABLE A(:)
  ....

  ALLOCATE (A(MTOT))
  CALL
ASSEMBLABLK(A(N1),A(N2),A(N3),A(N3),NEQ,NBLOCK,LBLOK,MAXC,NUMEL,KERR,NEQUAZ,KGEON,KEXIT)

The errors are here:


referenced in function _PUSHOVER Pushover.obj
Error 2  fatal error LNK1120: 1 unresolved externals

What's wrong? Is there a way to activate full parameter passing type
checking between functions with the Intel Visual Fortran compiler?

I posted here, because I'm not able to post on the Intel Visual Fortran
forum, but as soon as I can do it, you may find this issue posted even
there.



Sun, 16 Jan 2011 16:12:54 GMT  
 Issue from IVF 9.0 to IVF 10.1
| I have just updated my Fortran compiler from IVF 9.0 to 10.1 and I have my
| suite of DLLs, that I can't link successfully because of some LNK2019
| unresolved external symbols in my source code. These Fortran files are
| correctly compiled, but it is the linker to complain for, while the IVF v9.0
| linker linked the same sources without any issue.
|
| I admit that the calling and called functions are badly formatted, because
| of the implicit variables definition and the not-so-precise type matching,
| but that's the source code I got from my colleagues and I have to run soon.
|
| This is the function being called:
|
| SUBROUTINE
| ASSEMBLABLK(NA,NCOL,A,NRIFA,NEQ,NBLOCK,LBLOK,NUMEL,KERR,NEQUAZ,KGEON,KEXIT)
<snip>
||  CALL
|
ASSEMBLABLK(A(N1),A(N2),A(N3),A(N3),NEQ,NBLOCK,LBLOK,MAXC,NUMEL,KERR,NEQUAZ,KGEON,KEXIT)
|
| The errors are here:
|

| referenced in function _PUSHOVER Pushover.obj
| Error 2  fatal error LNK1120: 1 unresolved externals
|
| What's wrong? Is there a way to activate full parameter passing type
| checking between functions with the Intel Visual Fortran compiler?

Your calling sequence has 13 arguments, but the actual subroutine has 12.
MAXC actual argument looks like a probable culprit. I'm not sure how it
ever worked...

You seem to have non-default calling convention active
(Project properties/Fortran/External procedures). I guess it's "CVF", i.e.

got activated in your upgrade from 9.0 and 10.1 though?

IVF default convention (cdecl) does not encode routine names in this way.
However, IVF provides far more powerful cross-interface checking across
all source files by means of /gen-interface /check-interface switches.
That's under Diagnostics\"Generate interface blocks" and "Check Routine
Interfaces" in the IDE project settings.

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.



Sun, 16 Jan 2011 18:03:07 GMT  
 Issue from IVF 9.0 to IVF 10.1
Quote:

> I have just updated my Fortran compiler from IVF 9.0 to 10.1 and I have my
> suite of DLLs, that I can't link successfully because of some LNK2019
> unresolved external symbols in my source code. These Fortran files are
> correctly compiled, but it is the linker to complain for, while the IVF v9.0
> linker linked the same sources without any issue.

> I admit that the calling and called functions are badly formatted, because
> of the implicit variables definition and the not-so-precise type matching,
> but that's the source code I got from my colleagues and I have to run soon.

> This is the function being called:

> SUBROUTINE
> ASSEMBLABLK(NA,NCOL,A,NRIFA,NEQ,NBLOCK,LBLOK,NUMEL,KERR,NEQUAZ,KGEON,KEXIT)

>   IMPLICIT REAL*8(A-H,O-Z)
>   DIMENSION NA(NEQ),A(LBLOK),NCOL(NBLOCK)
>   DIMENSION NRIFA(2*LBLOK)
> ...

> The part of the subroutine calling this is here:

>   IMPLICIT REAL*8 (A-H,O-Z)

>   ALLOCATABLE A(:)
>   ....

>   ALLOCATE (A(MTOT))
>   CALL
> ASSEMBLABLK(A(N1),A(N2),A(N3),A(N3),NEQ,NBLOCK,LBLOK,MAXC,NUMEL,KERR,NEQUAZ,KGEON,KEXIT)

> The errors are here:


> referenced in function _PUSHOVER Pushover.obj
> Error 2  fatal error LNK1120: 1 unresolved externals

> What's wrong? Is there a way to activate full parameter passing type
> checking between functions with the Intel Visual Fortran compiler?

> I posted here, because I'm not able to post on the Intel Visual Fortran
> forum, but as soon as I can do it, you may find this issue posted even
> there.

As has been pointed out already, you pass 13 arguments to a subroutine
which has been declared with 12. Real*8 arrays are passed where
Integer*4 variables (possibly, this is scratch pad memory) are expected.
While a compiler following the Cdecl convention may produce an
executable without any complaints, it does not follow that the program
will work correctly and do what is expected.

The variable KEXIT is undefined, since the subroutine does not know that
it is the 13th argument. The same section of array A is used for the 3rd
and 4th arguments. Is that proper?

It is possible, but unlikely, that despite all these dubious practices
the program gave you the correct results. What you have seen are
examples of bugs that can go undetected for years. When, for some
reason, the compiler or compiler options change or the runtime library
changes you may be surprised by failure to work correctly and start
suspecting that the compiler or the runtime have bugs.

-- mecej4



Mon, 17 Jan 2011 01:44:38 GMT  
 Issue from IVF 9.0 to IVF 10.1
"Jugoslav Dujic" ha scritto nel messaggio...

Quote:
> Your calling sequence has 13 arguments, but the actual subroutine has 12.
> MAXC actual argument looks like a probable culprit. I'm not sure how it
> ever worked...


the amount of bytes of the stack.

Quote:
> You seem to have non-default calling convention active
> (Project properties/Fortran/External procedures). I guess it's "CVF", i.e.
> a leftover from CVF days. That's perfectly OK, and it helped catch the
> error

> got activated in your upgrade from 9.0 and 10.1 though?

Well, such non-default calling convention was activated still in the v9.0
project, because it seemed to be the only way to be able to call those
functions from Visual Basic 6 code. And that configuration parameter was
kept from v9.0 to v10.1. Do you know if the default calling convention in
v10.1 is working well with Visual Basic code? I didn't try at all, because I
got IVF v10.1 just yesterday, so I had no time to make tests.

Quote:
> IVF default convention (cdecl) does not encode routine names in this way.
> However, IVF provides far more powerful cross-interface checking across
> all source files by means of /gen-interface /check-interface switches.
> That's under Diagnostics\"Generate interface blocks" and "Check Routine
> Interfaces" in the IDE project settings.

May I use these features even with a non-default calling convention?

Thank you so much for your support.

Marco



Mon, 17 Jan 2011 15:07:21 GMT  
 Issue from IVF 9.0 to IVF 10.1
| "Jugoslav Dujic" ha scritto nel messaggio...
|| You seem to have non-default calling convention active
|| (Project properties/Fortran/External procedures). I guess it's "CVF", i.e.
|| a leftover from CVF days. That's perfectly OK, and it helped catch the
|| error

|| got activated in your upgrade from 9.0 and 10.1 though?
|
| Well, such non-default calling convention was activated still in the v9.0
| project, because it seemed to be the only way to be able to call those
| functions from Visual Basic 6 code. And that configuration parameter was
| kept from v9.0 to v10.1. Do you know if the default calling convention in
| v10.1 is working well with Visual Basic code? I didn't try at all, because I
| got IVF v10.1 just yesterday, so I had no time to make tests.

If you interface with Visual Basic, you do need to use stdcall convention (CVF).
Like I said, it's perfectly fine. What I still don't get is how the error
suddenly popped up in 10.1, but not in 9.0? While 9.0 had its share of bugs,
I don't see how it could possibly ever passed the linking stage, unless
something
in the code changed in the meantime.

|| IVF default convention (cdecl) does not encode routine names in this way.
|| However, IVF provides far more powerful cross-interface checking across
|| all source files by means of /gen-interface /check-interface switches.
|| That's under Diagnostics\"Generate interface blocks" and "Check Routine
|| Interfaces" in the IDE project settings.
|
| May I use these features even with a non-default calling convention?

Yes (supposedly).

Roughly, the option /gen-interface works by "adding" module...end module around
the
source files in the background. /check-interface works by "adding" USE
statements
within calling routines, and then the normal interface checking rules apply. It
should be all on "source" or "preprocessor" level, i.e. be independent of the
calling convention. Steve can probably add more details.

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.



Mon, 17 Jan 2011 16:45:48 GMT  
 Issue from IVF 9.0 to IVF 10.1
"mecej4" ha scritto nel messaggio...

Quote:
> As has been pointed out already, you pass 13 arguments to a subroutine
> which has been declared with 12. Real*8 arrays are passed where Integer*4
> variables (possibly, this is scratch pad memory) are expected. While a
> compiler following the Cdecl convention may produce an executable without
> any complaints, it does not follow that the program will work correctly
> and do what is expected.

> The variable KEXIT is undefined, since the subroutine does not know that
> it is the 13th argument. The same section of array A is used for the 3rd
> and 4th arguments. Is that proper?

> It is possible, but unlikely, that despite all these dubious practices the
> program gave you the correct results. What you have seen are examples of
> bugs that can go undetected for years. When, for some reason, the compiler
> or compiler options change or the runtime library changes you may be
> surprised by failure to work correctly and start suspecting that the
> compiler or the runtime have bugs.

Well, the Fortran source code I'm dealing with has been written more than 15
years ago and it's still being maintained and expanded with those
development practices.
Those functions, which are mixing array and scalar values, and integer with
double ones in the same matrix, are handled in that strange way from more
than a dozen of years. This morning I talked about it with the author of
that code and he stated that such changes - in order to fix the errors
generated of a bit serious type checking - from those practices mean to
trash almost everything.

M



Mon, 17 Jan 2011 21:50:49 GMT  
 Issue from IVF 9.0 to IVF 10.1

Quote:

>| May I use these features even with a non-default calling convention?

>Yes (supposedly).

>Roughly, the option /gen-interface works by "adding" module...end module around
>the
>source files in the background. /check-interface works by "adding" USE
>statements
>within calling routines, and then the normal interface checking rules apply. It
>should be all on "source" or "preprocessor" level, i.e. be independent of the
>calling convention. Steve can probably add more details.

It's not quite like that.  When the compiler sees a non-CONTAINed procedure,
it generates a specially-named module with an interface for that routine. When
the compiler sees a call to a procedure that does not have an explicit
interface visible, it looks to see if one of these generated modules is
present.  If so, it compares the call against the interface.  This is NOT the
same as a USE, as the generated interface does not satisfy the need for an
explicit interface where required (array valued functions, etc.) Indeed, the
compiler will tell you this if you should have had an explicit interface
visible.

It's not a perfect system - in particular, order of compilation can affect it,
but it does catch a lot of problems.

Yes, it works even if you use STDCALL.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://support.intel.com/support/performancetools/fortran
My Fortran blog
  http://www.intel.com/software/drfortran



Mon, 17 Jan 2011 22:59:35 GMT  
 Issue from IVF 9.0 to IVF 10.1

Quote:
> Those functions, which are mixing array and scalar values, and integer with
> double ones in the same matrix, are handled in that strange way from more
> than a dozen of years.

Pfui! Fortran 90 compilers, which made such practices unnecessary, were
available at least by that time.

 > This morning I talked about it with the author of

Quote:
> that code and he stated that such changes - in order to fix the errors
> generated of a bit serious type checking - from those practices mean to
> trash almost everything.

I wouldn't believe a word of that.

        Jan



Sun, 06 Feb 2011 19:22:36 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. IVF 9.0: 3 questions

2. Standard issue or IVF bug?

3. ANN: Open Inventor 3-Day training, with VRML and IVF

4. Steve Lionel - Simple Program Fails with IVF 8.0

5. Stack trace terminated abnormally using IVF and NT-MPICH

6. IVF with MKL 5.1

7. Compatibility between IVF 8.0 and CVF 6.6B

8. Monitoring IVF/CVF program faults

9. IVF vs CVF

10. IVF and IEEE standard intrinsic modules

11. How to Find Memory Used (IVF 9.1, WinXP)

12. function with allocatable type? (IVF 9.1)

 

 
Powered by phpBB® Forum Software