Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Parameter is unacceptable.

JohnNichols
Valued Contributor III
678 Views

I have been using a library for several years.  It was updated recently.  

There is a call to a routine that creates an array. I have been quite comfortably able to pass it 20100 by 4500 sized arrays.  

The latest update throws an error, parameter is unacceptable, for all subroutine calls.  

I am now stuck with a 10000 by 4500, after a lot of playing to work out the problem.  

Who says old code runs on updated compilers?

Change is not always good?

 

 

0 Kudos
1 Solution
JohnNichols
Valued Contributor III
583 Views

Jim:

Thanks for the comment.  You prompted the thought and I swapped out an old DLL from before the recent updates and it works.  I should have thought of that straight away, some time we get lost in the minutia of fixing problems, we miss that the patient is dead. 

That's what friends are for.  

Warm regards

 

John

View solution in original post

0 Kudos
8 Replies
Steve_Lionel
Honored Contributor III
667 Views

Could we see a minimal example? I suspect something else is wrong here. That said, old CORRECT code should be fine with newer compilers, but it's often the case that incorrect code is newly detected in an update, and that is fine.

0 Kudos
JohnNichols
Valued Contributor III
647 Views

The code is locked in a DLL I do not have access to, I have run a test where I slowly increase the array size one row at a time and it always gives error at same point.  

I am not going to waste my time on it.  

It is not worth the hassle.  All change is not good. 

Thanks

John

0 Kudos
JohnNichols
Valued Contributor III
640 Views

VS2019 does not throw an exception,  VS 2022 does on the same code, must be different DLL's. 

0 Kudos
jimdempseyatthecove
Honored Contributor III
631 Views

>>There is a call to a routine that creates an array.

How?

Allocatable or stack?

>>The code is locked in a DLL I do not have access to...

So, unknown...

If the "locked" code is initializing the array using stack (e.g. array temporaries), then you might get by by increasing the application stack size. Note, if this array is REAL(8), and if the entire array is temporarily allocated to stack this requires 724MB.

 

Jim Dempsey

 

0 Kudos
JohnNichols
Valued Contributor III
578 Views

The "error" is an artificial arithmetic limit included in the subroutine, it now obviously checks if your number is bigger than 10000 and throws an exception.  

Windows does not impose the limit and the old code works fine at 20,100.  

Steve is correct it is not a compiler error.  

We learn by other people's mistakes, this is a coding decision for no good reason that I can see.  

 

0 Kudos
Steve_Lionel
Honored Contributor III
628 Views

So, this is an error message from the application, which you have no sources for, and not the compiler. I didn't recognize the message. The symptom suggests passing wrong datatypes, or data corruption somewhere else.  Or maybe the library you called has some internal limit you exceeded. Why you would suggest that the compiler is at fault, I don't understand. Why even post about it here?

JohnNichols
Valued Contributor III
586 Views

Why even post about it here?

True I suppose.

Frustration at stupid code changes that I have no control over.  Glad that the old timers, like the Prestressed Beam People and Harrison published their Fortran code and we can use it and amend it.  

 

 

0 Kudos
JohnNichols
Valued Contributor III
584 Views

Jim:

Thanks for the comment.  You prompted the thought and I swapped out an old DLL from before the recent updates and it works.  I should have thought of that straight away, some time we get lost in the minutia of fixing problems, we miss that the patient is dead. 

That's what friends are for.  

Warm regards

 

John

0 Kudos
Reply