 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
RagD
Joined: 01 Mar 2016
Posts: 2
|
 Posted: Thu Mar 03, 2016 12:20 pm Post subject: error 112 while I did initialize integer with -2139062144 |
 |
|
Hi all,
'm not terribly experienced at fortran-coding (3~4 weeks under my belt for fortran; i've done more matlab-scripting before this) but I have the feeling I encountered an error that shouldn't be there (i.e. rather a source-code error or similair)
at a specific integer number, i get an 112 error (which said I did not initialize the variable), while I did initialize that specific number. The following code contains this problem (very simplified). I tried updating silverfrost but that didn't help ("PLATO version 4.7.0"). I'm on a windows 8.1 machine (64-bits) if anyone wants to know
| Code: | program why_doesnt_it_work
implicit none
integer::i
i=-2139062143
print*,i
i=-2139062145
print*,i
i=-2139062144
print*,i
!the previous two integers got printed, but at this point, I initialize the variable "i" with the new number, but when called upon in line 10 it says: !"error112,reference to undefined variable, array element of function result (/UNDEF)" - " main - in file mfd.f95 at line 10 [+0151]"
end program why_doesnt_it_work |
I encountered the problem while I did a loop over all integers [do i=-huge(i),huge(i)] to check if a function worked properly for all integers. In this do-loop, I entered the integers one-by-one into a function, and the error occured only in the function (and not in the main program that contained the do-loop). Only for a specific integer, value -2139062144 did the problem occur (as shown in code above; the other two integers work just fine)*
However, the problem does seem a bit hit-and-miss, as in different codes that error did not always appear (although the code shown above consistently hits that error on my computer)
I hope you could give me some guidance/assistance/insight with respect to that weird error
RagD
*note, since the do-loop couldn't get past -2139062144, I did not check if this problem also occurred at higher values |
|
| Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006
Posts: 2554
Location: Sydney
|
| Posted: Thu Mar 03, 2016 1:26 pm Post subject: |
|
|
As you are using Plato, try using different compile options:
Release Win32
Debug Win32
CheckMate Win32
You will find only the last fails, as -2139062144 is used to indicate an undefined value. The last opting includes /undef
That's the way it works !
John |
|
| Back to top |
|
|
RagD
Joined: 01 Mar 2016
Posts: 2
|
| Posted: Thu Mar 03, 2016 1:46 pm Post subject: |
|
|
oh, wow, thanks, that works.
just wondering; how do those other compiling options reference to an undefined number? With an external bit that defines the variable to be set?
And/or are there any other unexpected traps I can expect when doing a loop over all the integers or reals?
RagD |
|
| Back to top |
|
|
wahorger
Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA
|
| Posted: Fri Mar 04, 2016 12:37 am Post subject: |
|
|
In general, the 80 (hex) pattern is used for ANYTHING to indicate it is "undefined". Including real/doubles/etc. When encountered, if /CHECKMATE is being used, you'll get the trap. But, if you compile and run as /RELEASE, no problem.
I have code that creates these patterns nearly every time it runs, so I cannot run in /CHECKMATE if I'm doing anything other than a quick run to check out a change.
C*1, I*1, L*1 = 80
I*2, L*2 = 8080
I*4,R*4,L*4 = 80808080
..... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
