URGENT HELP

Folks, Can you please compile this program ASAP? I have to stop using this compiler, or stop programming completely, this damn devils joke will kill me, now it crashes not only the code but the compiler even if i comment almost everything and i do not see the error. Just do FTN95 aaa.f95 and it immediately crashes on or just after module. I commented the Caller part to try to find the bad place, removed subs but FTN95 still crashes. Code still has many errors but i even do not see the damn error report. Somewhere possible German, French or Russian ASCII symbol from the hell was somehow produced like a poison and the English compiler is almost dead

module All_subs_Bremms
  use clrwin
  parameter (idim=50)
  real*8 x(idim), y1(idim), y2(idim), y3(idim)

  character*320 chParForSimplePlot_f_E
  integer kPlot1, kPlot2, kPlot3
  integer k32bit, k64bit, kSave_f_E_to_File
  integer lxWin, lyWin, iRunning_El_f_E_Fit
  real*8  TextSizeSmplpl_r8, LineWidthSmplpl_r8
  integer iRunning_El_f_E_Fit 
contains
end module

!.....................................................
!
!Program Caller
!use All_subs_Bremms
!integer, external:: Plot
!
!     lxWin = 800
!     lyWin = 600
!     TextSizeSmplpl_r8  = 3
!     LineWidthSmplpl_r8 = 2
!
!     chParForSimplePlot_f_E = '%pv%pl[x_axis='E [keV]',y_axis='f(E) (arb.un.)',title='Electron f(E) - blue,  Ion f(E) - black',& 
!     &colour=blue, colour=black, colour=red, colour=#339900, colour=green, x_array, scale=log_linear, N_GRAPHS=6, Y_MIN=1.] %ff&'
!
!     x (:)   = 0
!     y1(:)   = 0
!     y2(:)   = 0
!     y3(:)   = 0 
!
!     k_Plot1 = 0
!     k_Plot2 = 0
!     k_Plot3 = 0
!
!     k32bit  = 0
!     k64bit  = 1  
!
!   do i=1,  idim
!     X (i) = i
!     Y1(i) = sin(i/10.)
!     Y2(i) = sin(i/20.)
!     Y3(i) = sin(i/30.)
!   enddo
!
!i=winio@('%ww&')
!i=winio@('In 32bits - Old and New, in 64 only New PL%ff%rb[OldPL]%rb[NewPl]%ff&', k32bit, k64bit)
!i=winio@('%2`ga%ff%cn%^bt[Start]%es', k32bit, k64bit, Plot)
!
!end program


!................................................................

!................................................................

  integer function Plot ()

   use All_subs_Bremms
   integer, external ::  cb_Plot
   character chLineWid*16

   do i=1,  idim
     X (i) = i
     Y1(i) = sin(i/10.)
     Y2(i) = sin(i/20.)
     Y3(i) = sin(i/30.)
   enddo

       i = winio@('%1`tl&', 32.d0)
        i=winio@('%ww%ca[Distribution Functions]&')

        i=winio@('%1.3ob[scored]&')	

        i=winio@(' Max energy [eV] for f(E)%ta%df%10rf %ff&', &
                  aStepIncrE0*MaxEnergyFor_f_E, MaxEnergyFor_f_E)

        i=winio@('%cb&')

         i=winio@('%^rb[Plot El. ]%ff&', kPlot1, cb_plot)
         i=winio@('%^rb[Plot Ion1]%ff&', kPlot2, cb_plot)
         i=winio@('%^rb[Plot Ion2]%ff&', kPlot3, cb_plot)
         i=winio@('%^rb[Save to File f_E dat]%ff&', kSave_f_E_to_File, cb_plot)

        i=winio@('%cb&')


         i=winio@('%80rs%ff&', chParForSimplePlot_f_E)


        TextSizeSmplpl  = TextSizeSmplpl_r8
	LineWidthSmplpl = LineWidthSmplpl_r8


!	if(k64bit.eq.1) CALL winop@('%pl[y_sigfigs=5]')  
        if(k64bit.eq.1) CALL winop@('%pl[native]')
        if(k64bit.eq.1) call winop@('%pl[framed]')

        i=winio@('%sf&') 
        i=winio@('%ts&', TextSizeSmplpl_r8) 
        i=winio@('%bf&') 

!       if(k64bit.eq.1) CALL winop@('%pl[etched]') 
        if(k64bit.eq.1) CALL winop@('%pl[margin=92]') 
        if(k64bit.eq.1) CALL winop@('%pl[tick_len=8]') 
	if(k64bit.eq.1) CALL winop@('%pl[axes_pen=3]') 

	chLineWid='%pl[width= 3]'
	write(chLineWid(11:12),'(i2)') nint(LineWidthSmplpl)
        if(k64bit.eq.1) CALL winop@(chLineWid) 

!..........
   do i=1,  idim
     X (i) = i
     Y1(i) = sin(i/10.)
     Y2(i) = sin(i/20.)
     Y3(i) = sin(i/30.)
   enddo

                                                        

         i=winio@(chParForSimplePlot_f_E, &
         lxWin, lyWin, nfEMax4, XfEplLog, YfEplLog, &
         TfESumplLog, TfE1_OnOffplLog, TfE2_OnOffplLog, Ei1fEplLog, Ei2fEplLog)


         i=winio@(' Text Size (0.1-1.0)%ta%df%8rf%ff&',  0.01d0, TextSizeSmplpl_r8)
         i=winio@(' Line width (1-10)%ta%df%8rf%ff&', 0.2d0, LineWidthSmplpl_r8)

      i=winio@('%cb&')

      i=winio@('%ff&')


         i=winio@('%ac[esc]&','exit')
         i=winio@('%ac[Alt+X]&','exit')
         i=winio@('%ff%cn%^bt[OK]&','exit')
         i=winio@('%lw',ilwww2) 

10000  Plot =2
  end function Plot

!---------------------------------------------------------
  integer function cb_plot ()
     use All_subs_Bremms

   IF(iRunning_El_f_E_Fit.eq.1) goto 10000
      iRunning_El_f_E_Fit = 1

   do i=1,  idim
     X (i) = i
     Y1(i) = sin(i/10.)*(1e-30+kPlot1)
     Y2(i) = sin(i/20.)*(1e-30+kPlot2)
     Y3(i) = sin(i/30.)*(1e-30+kPlot3)
   enddo

     call simpleplot_redraw@


9999     iRunning_El_f_E_Fit = 0

10000  cb_plot = 2
  end function cb_plot

This code reveals a bug in FTN95 which will be fixed for the next release.

It can be avoided by providing an explicit type for IDIM.

  integer,parameter::idim=50 

Dan,

compiling the complete code results in a runtime error producing error report

Runtime error from program:c:\win32app\silverfrost_8.30\ftn95\ftn95.exe
Access Violation
The instruction at address 00456e9a attempted to read from location 00000000

 0045606a process_module_attribute_bits(<ptr>struct&#9472;scoped_entity,<ref>enum&#9472;logical,<ref> [+0e30]
 004580f5 read_module_entity(enum&#9472;logical)#1D [+0bae]
 00459a8e process_binary_module(int,enum&#9472;logical)#1D [+02da]
 0045ace4 process_use_stmt(<ptr>char,<ref>int) [+026a]
 0040b2cd parse_declaration_statement(<ptr>char,int,int,<ref>int) [+2af5]
 0041315b handle_token(<ptr>char,int,int,int,int,<ref>int) [+0e04]
 004056b3 ProcessEntireLine(void) [+06cf]
 00406697 compile(<ptr>char) [+0165]

eax=03d4f144   ebx=00000000   ecx=0000000d
edx=0568d9bc   esi=00000000   edi=03d4f144
ebp=03d4f1a0   esp=03d4ca1c   IOPL=3
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00210206 [NC EP NZ SN DN NV]

 00456e9a  rep       
 00456e9b  movs      
 00456e9c  orb      [ebp-0x5b],0x4 

on my machine. Compiling only the first page (using the module definition only) is ok.

Regards, Dietmar

Dan,

I got a stack of errors compiling this code. I used 'ftn95 aaa.f95 /-imp'

first, I needed ' integer, parameter :: idim=50' (I have always thought your parameter statement was not supported by FTN95)

then duplicate iRunning_El_f_E_Fit in module

then [FTN95/Win32 Ver. 8.30.0 Copyright (c) Silverfrost Ltd 1993-2018]

PROCESSING MODULE  [<ALL_SUBS_BREMMS> FTN95/Win32 v8.30.0]
NO ERRORS  [<ALL_SUBS_BREMMS> FTN95 v8.30.0]

84.      i=winio@(' Max energy [eV] for f(E)%ta%df%10rf %ff&', & 
    

85.                aStepIncrE0*MaxEnergyFor_f_E, MaxEnergyFor_f_E) 
    

*** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) 0118) write(chLineWid(11:12),'(i2)') nint(LineWidthSmplpl) *** Error 328: The first argument (A) to the intrinsic NINT must be of REAL type, not INTEGER(KIND=3) 0131) i=winio@(chParForSimplePlot_f_E, & 0132) lxWin, lyWin, nfEMax4, XfEplLog, YfEplLog, & 0133) TfESumplLog, TfE1_OnOffplLog, TfE2_OnOffplLog, Ei1fEplLog, Ei2fEplLog) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) *** Error 140: WINIO@ cannot process REAL(KIND=1) arguments, only CHARACTER, INTEGER(3) or REAL(2) 0149) 10000 Plot =2 WARNING - 21: Label 10000 is declared, but not used 9 ERRORS, 1 WARNING [<PLOT> FTN95 v8.30.0] 0169) 9999 iRunning_El_f_E_Fit = 0 WARNING - 21: Label 9999 is declared, but not used NO ERRORS, 1 WARNING [<CB_PLOT> FTN95 v8.30.0] *** Compilation failed

You should try 'ftn95 aaa.f95 /imp'

Damn, I have to blame myself that time ago I did not ask the question why this Parameter claim did not work. Instead, I fixed it and forgot. Today I got for that laziness the anger, yell and swearing level that no one with finishing school would survive to stay nearby my room. After a week of crashes of simple code, I decided to make a small reproducer. Can you imagine that at the end if the day I got even worse situation when I couldn't even compile?!! Thanks all.

Please report anything you find in your programs, do not delay, the smaller users base means everyone has actively participate in the product quality improvement. If you are not sure, then don't hesitate posting like a discussion. Anything we did not make perfect kicks us later in the back.

Thanks, John,

The code above was not worth considering beyond the reason for the crash. You all found that there is a bug in FTN95 with 'Parameter (idim=50)' settings like I used above while it goes OK using a bit different syntax 'integer parameter:: idim=50' and I thank all for that.

But this also tells me about the unimaginable and totally unbelievable other side of the medal, truly the life story about human nature that

NO ONE REPORTS ANY BUGS!

This relates to everything in life, not just FTN95, literally everything. Negligible amount of people really care. And that the

FTN95 DEVELOPERS DO NOT USE THEIR OWN COMPILER FOR ANY JOB (teaching, consultancy, writing contract programs, comparing with other compilers, even code validation). Again the use is negligible, probably.

Tell me I'm wrong and I will ask: FTN95 is 20 years old and no one had parameter set this very common way?

This code intended to make smaller demo out of larger code crashing on simpleplot_update@ and was just the start for longer source text which never came even first cleaning due to FTN95 crash so it had uncountable not related bugs and typos. A bit cleaner but also still not the one I intended to do source text which revealed two other problems with FTN95 and Clearwin+ I also posted in other place for Paul and Robert to look.

https://forums.silverfrost.com/Forum/Topic/3370

I am still fighting to find what causes crash with simpleplot_update@ while all goes OK on other very similar places and on all my smaller demos.

Dan, WINIO@ is the name of a privileged FTN95 intrinsic. The compiler knows this function, and ignores any type and interface declarations for WINIO@ in user code. Furthermore, the actual external name that is referenced is not WINIO@, but WINDOW_PRINTF@@ (for the calls that I saw; for instances where WINIO@ requires input, perhaps there is a similar WINDOW_SCANF@@ ?)

In fact, I don't think that it is possible to write a proper interface for it in Fortran. There has to be a perfect match in the %xx specifiers in the first argument and the types of the second, etc., arguments to WINIO@, as with the C printf() function.

Unfortunately, at present there is also a bug in the implementation of WINIO@ in 32-bit mode; see http://forums.silverfrost.com/posting.php?mode=quote&p=24788 . Fortunately, if your code does not contain many WINIO@calls, especially such calls inside DO loops, you may not even notice the bug and your code will probably work correctly.

Given the current assignments of functionality between the compiler and the FTN95 DLLs, allowing checking for undefined arguments to WINIO@ will probably have a negative effect on performance of user code, and there may be other reasons why checking is impossible for undefined arguments that are passed to WINIO@ in calls from code that was not compiled with /undef .

Quoted from DanRRight You all found that there is a bug in FTN95 with 'Parameter (idim=50)' settings like I used above while it goes OK using a bit different syntax 'integer parameter:: idim=50' ... Tell me I'm wrong and I will ask: FTN95 is 20 years old and no one had parameter set this very common way?

Dan, the compiler crash is seen only for the specific code that you posted and not with every declaration with the old F77-style PARAMETER (var1=cnst1, ...) declaration. I took the code for just the module All_subs_Bremms in your first post in this thread, removed the superfluous CONTAINS line, and put the remaining lines into a source file. Compiling it with no options gave

s:\FTN95\BW>ftn95 danm.f90
[FTN95/Win32 Ver. 8.30.0 Copyright (c) Silverfrost Ltd 1993-2018]
    PROCESSING MODULE  [<ALL_SUBS_BREMMS> FTN95/Win32 v8.30.0]
0011)   integer iRunning_El_f_E_Fit
WARNING - ALL_SUBS_BREMMS!IRUNNING_EL_F_E_FIT has been declared more than once with the same type (see line 9)
    NO ERRORS, 1 WARNING  [<ALL_SUBS_BREMMS> FTN95 v8.30.0]

and compiling the same source file with /imp gave

s:\FTN95\BW>ftn95 danm.f90 /imp
[FTN95/Win32 Ver. 8.30.0 Copyright (c) Silverfrost Ltd 1993-2018]
    PROCESSING MODULE  [<ALL_SUBS_BREMMS> FTN95/Win32 v8.30.0]
0011)   integer iRunning_El_f_E_Fit
WARNING - ALL_SUBS_BREMMS!IRUNNING_EL_F_E_FIT has been declared more than once with the same type (see line 9)
0003)   parameter (idim=50)
*** IDIM must appear in a type declaration because IMPLICIT NONE has been used
    1 ERROR, 1 WARNING  [<ALL_SUBS_BREMMS> FTN95 v8.30.0]
*** Compilation failed

As you can see, the compiler performed as expected when it was given code containing the F77 style PARAMETER declaration.

Quoted from mecej4 Dan, Fortunately, if your code does not contain many WINIO@calls, especially such calls inside DO loops, you may not even notice the bug and your code will probably work correctly.

Given the current assignments of functionality between the compiler and the FTN95 DLLs, allowing checking for undefined arguments to WINIO@ will probably have a negative effect on performance of user code, and there may be other reasons why checking is impossible for undefined arguments that are passed to WINIO@ in calls from code that was not compiled with /undef .

Mecej4,

Alas, the codes have a lot of winio@ calls, many thousands. But may be good is that i almost moved all of them 64bit. Hopefully with all the details from the users we will pesticide most annoying bugs. Also hope that Paul will be able to add for Clearwin+_ checking of input for for undefinied variables. There will be zero impact on performance for most of them. Sometimes probably there will be even positive impact (i had in the past posted here couple cases when i was forced to add the delay 0.01-0.1 seconds for GUI to work reliably. Seriously, LOG(-1.) or SQRT(-2.) get us error report even with /NOCHECK while Clearwin+ prefers to crash with access violation! This is huge design defect, i agree with John-S, totally unacceptable for CWP to be broadly used in future by fortraners.

Quoted from mecej4 Dan, the compiler crash is seen only for the specific code that you posted and not with every declaration with the old style PARAMETER (var1=cnst1, ...)

Interesting. I have other cases crashing, simple like 2x2. Was lazy to report this 10 years ago and damn thing resurfaced now. What this program, for example ( which is doing nothing just showing how SQRT(-negNumb) is reported ) produces in your computer, isn't it crashing too?

module A
parameter (idim=100)
real*8 AA(idim)
end module 

program AAA
use A
AAAA=sin(4.)
AAAAA=sqrt(AAAA)
end

When a computer program -- your program, the compiler or the OS kernel -- malfunctions or reports an error, that is not necessarily a crash. Ideally, programs should have no bugs, but we know what happens in real life. Finding a bug does not imply anything regarding poor design, etc. Often, when a compiler fails, it can be because of an error made by the compiler user that the compiler did not anticipate, and so the compiler is unprepared to deal with the error.

With a little help and understanding from us, plus good bug reports and a responsive compiler vendor such as Silverfrost, we can make steady progress.

Take the code that you just gave, for example. Inspection shows three things:

(i) look carefully at the Access Violation pop up that the compiler gave. Look at the traceback, and observe that the abort occurred in 'process_module_attribute_bits'. Look at the console and observe that the compiler reported 'NO ERRORS' after it processed the module code. That is a hint that the compiler abort was caused by the main program, not the module.

(ii) the module is really not needed or used by the program, so we can remove the USE statement. Doing so (or commenting that line out) makes the compiler bug stay away.

(iii) take out the module part and put it into a separate file. The module gets compiled with no problems. Now compile the program part (after the module has been removed) with and without the USE statement. It is the irrelevant USE statement that causes the compiler to fail.

After seeing all this, do you still wish to attribute the compiler bug to the presence of a F77-style PARAMETER statement in an unrelated module?

Mecej Let's check that differently, double sht's possible. This code crashes

module A 
parameter (idim=10) 
real*4 AA(idim) 
end module 

program AAA 
use A 
AA(:)=-1
AAAAA=sqrt(AA(1)) 
end 

this one has more relevant module crashes too

module A 
parameter (idim=10) 
real*4 AA(idim) 
contains
  subroutine AAA
  AA(:)=-1
  end subroutine
end module 

program AAA 
use A 
CALL AAA
AAAA=sqrt(AA(1)) 
end 

while this one with removed line Parameter inside the module does not. What you will say now?

module A 
!!!!! parameter (idim=10) 
real*4 AA(10) 
end module 

program AAA 
use A 
AA(:)=-1
AAAAA=sqrt(AA(1)) 
end 

The code

program AAA 
CALL AAA 
end

is not correct Fortran - the subroutine should not have the same name as the main program.

I will see if the error report can be made more specific.

For the next release of FTN95, the code...

module A 
integer,parameter::idim=10 
real*4 AA(idim) 
contains 
  subroutine AAA 
  AA(:)=-1 
  end subroutine 
end module 

program AAA 
use A 
CALL AAA 
AAAA=sqrt(AA(1)) 
end

will result in the compilation error..

error 647 - AAA is a PROGRAM name, so cannot be called

Quoted from DanRRight

module A 
parameter (idim=10) 
real*4 AA(idim) 
contains
  subroutine AAA
  AA(:)=-1
  end subroutine
end module 

program AAA 
use A 
CALL AAA
AAAA=sqrt(AA(1)) 
end 

Dan, the compiler fails to process the PARAMETER declaration correctly, as Paul has already acknowledged, so let us put that aside, and assume that the compiler has processed the whole module correctly, and is now compiling the main program. When it sees use A, it may scan all the public entities of the module A, find AAA defined in the module and, as Paul pointed out, in conflict with the program name, which is also AAA. At this point, the compiler may see the conflict but postpone giving error messages because, although AAA is accessible by 'use association', it has not yet been actually used. After it scans the next line, CALL AAA, the compiler has to decide what error message to give, and it needs to resolve the ambiguity about AAA to do that. The choice that it makes in doing so may not agree with the choice that a human reader would make.

Here is what Gfortran 7.1 says:

$gfortran -std=f95 *.f95 -o main
main.f95:11:4:

 use A
    1
Error: ‘aaa’ of module ‘a’, imported at (1), is also the name of the current program unit
main.f95:12:8:

 CALL AAA
        1
Error: Name ‘aaa’ at (1) is an ambiguous reference to ‘aaa’ from current program unit

Mecej4, Paul, Okay, forget AAA, rename one of it to BBB. Otherwise all look like kind of tripple witching 😃 -- all damn devilry here, parameters conflict, dysfunctional modules conflict, program names conflict. Does ftn95 still crash with my third example?

Meantime thanks for program-subs name conflict fix

To put things on end, and make sure correct bug will be fixed, do now we have any doubts that the parameters syntax caused this access violation?

No. No doubts and it has already been fixed.

Thanks, Paul.