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
New Contributor I
1,500 Views
I'm noticing segfaults related to the presence of

call flush()

in my code. Can someone explain me why?
0 Kudos
1 Solution
TimP
Honored Contributor III
1,500 Views
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.

View solution in original post

0 Kudos
5 Replies
rreis
New Contributor I
1,500 Views
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...
0 Kudos
jimdempseyatthecove
Honored Contributor III
1,500 Views

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
0 Kudos
rreis
New Contributor I
1,500 Views
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.
0 Kudos
TimP
Honored Contributor III
1,501 Views
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.
0 Kudos
rreis
New Contributor I
1,500 Views
Oh, didn't knew about that. Thanks for explaining.
0 Kudos
Reply