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 II
365 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 II
270 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

8 Replies
Steve_Lionel
Black Belt Retired Employee
354 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.

JohnNichols
Valued Contributor II
334 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

JohnNichols
Valued Contributor II
327 Views

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

jimdempseyatthecove
Black Belt
318 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

 

JohnNichols
Valued Contributor II
265 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.  

 

Steve_Lionel
Black Belt Retired Employee
315 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 II
273 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.  

 

 

JohnNichols
Valued Contributor II
271 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

Reply