我已經編寫了一個fortran例程，它使用一些傳統fortran 77代碼來處理有限元素。但是，對於特定的網格，當啓用-O優化標誌時，即使Fortran被認爲禁止了此操作，重要的do循環迭代器也會以某種方式被修改。我已經使用gfortran4.5編譯了這個代碼，啓用了-fcheck = do運行時檢查，並驗證了我上面提到的內容。運行時錯誤僅在開啓優化並直接指向do-iterator時發生。gfortran優化會導致fortran在運行期間出現變量循環錯誤
在優化過的代碼上使用gdb似乎（儘管看起來不穩定 - 線條來回跳動）似乎清楚地表明do-iterator以某種方式被設置回零，並且基本上會導致一個很好的無限循環。
任何有關如何尋找並修復造成此錯誤的建議都將不勝感激，因爲我想確保整個項目可以使用相同的標誌一致編譯。
你說你用fcheck = do;爲什麼不能一路走下去並使用fcheck = all？你所看到的聽起來像是由於數組邊界違例而導致的典型內存損壞情況，在某些情況下，fcheck = all可以捕獲。數組邊界檢查無法正常工作的地方在於傳遞了隱式接口和不正確的邊界;這裏的解決方案是將你的過程放入模塊中，允許編譯器檢查接口。
而且，就像Jonathan Dursi說的那樣，考慮使用像valgrind這樣的工具。
我想暫時我會在調試模式下運行它。我正在連接的Fortran代碼使用C進行動態內存分配，最初是在f77中編寫的。使用valgrind和fcheck = all，程序錯誤出現在我的問題之前（可能會強調代碼的其他問題）。我選擇了fcheck = do，因爲do-loop變量正在修改，導致無限循環（重置j = 1到j = 0）。奇怪的事情是相同的代碼，當優化與四面體有限元素（可能不同的佈局）一起運行良好時，與六面體磚塊有限元素失敗時運行良好。 – Jon 2011-04-08 04:31:43
如果程序導致valgrind和fcheck = all的錯誤，我當然不會相信結果。 – janneb 2011-04-08 08:32:42
沒有一些代碼就不能提供很多見解，最好是一個能夠再現問題的小型測試用例。然而，一個明顯的問題是 - 你是否通過valgrind或類似的東西來運行，看看是否有內存覆蓋？這可能是因爲你（比如說）超過了數組的末尾，並且在未優化的代碼中，你踩了一些無害的代碼，但是改變了內存佈局，你現在正在踩着do-loop迭代器。 – 2011-04-07 19:12:53
有問題的do循環的來源？ – steabert 2011-04-08 05:53:09