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

Segfault, call flush

rreis
Novo colaborador I
1.860 Visualizações
I'm noticing segfaults related to the presence of

call flush()

in my code. Can someone explain me why?
0 Kudos
1 Solução
TimP
Colaborador honorário III
1.860 Visualizações
According to textbooks, the standard FLUSH requires a UNIT specification. call flush() is a non-standard extension, and, if supported, would require an appropropriate USE declaration to deal with an empty argument. There would be no guarantee of the meaning of the empty argument; note that there is an open gfortran bug about accepting the empty argument. So, you were using a compiler-dependent extension, and hitting a known bug in the compiler which accepted it.

Ver solução na publicação original

5 Respostas
rreis
Novo colaborador I
1.860 Visualizações
Quoting - rreis
I'm noticing segfaults related to the presence of

call flush()

in my code. Can someone explain me why?

Answering myself (remembered to try this), I was lacking which buffer should be flushed...

call flush(6) solved my problem (I was flushing stdout)

anyway I was caught off guard because gfortran eats flush() wihtout problem...
jimdempseyatthecove
Colaborador honorário III
1.860 Visualizações

If the call itself is causing the problem, then put a break point on the call, at break, open a dissassembly window, and step into the routine. Assembly is not all that hard to interpret, at least it should not be for someone in a PhD program. Verify your interface is correct.

If the presence of the call statement, but not the call itself causes the problem (i.e. problem occures before the call) then suspect that you have a programming problem where the program corrupts itself but is not observed until the call statement is inserted (or perhapse any other call would suffice to expose the error). In this case you may have a problem with uninitialized variables or wrong variable types. Use IMPLICIT NONE and try a debug session with check for uninitialized variables enabled as well as check for subscript errors. Also using /gen-interfaces and /warn:interfaces (note, the Linux option switched may be different from the Windows option switches)

Jim Dempsey
rreis
Novo colaborador I
1.860 Visualizações
I hadn't gone so far has to dessemble the code. Has I said, ifort seems to do not like call flush() alone, you seem to have to tell him wich buffer you want to flush. I haven't gone through the documentation yet to see if this is a desired behaviour or not. Thanks for the compiler flags sugestions but I was using them already. This was not an interface problem, I was using it on the main program directly to output some print to the console to monitor some variables.

I got used to combine print + call flush() to debug parallel code in MPI. Anyway thanks for the sugestions.
TimP
Colaborador honorário III
1.861 Visualizações
According to textbooks, the standard FLUSH requires a UNIT specification. call flush() is a non-standard extension, and, if supported, would require an appropropriate USE declaration to deal with an empty argument. There would be no guarantee of the meaning of the empty argument; note that there is an open gfortran bug about accepting the empty argument. So, you were using a compiler-dependent extension, and hitting a known bug in the compiler which accepted it.
rreis
Novo colaborador I
1.860 Visualizações
Oh, didn't knew about that. Thanks for explaining.
Responder