[thread display] [new arrival display] [word search] [past log] [管理用]
| Subject | ： Re: SAD Update. V1.0.10.2.3b. g95 compatible. |
| Date | ： 2008/02/16(Sat) 22:47:16 |
| Contributor | ： Akio Morita |
ソース側の変更は精読していませんが、make framework側の変更関連で
意図がよく分からな点とか問題に成りそうなところを幾つか...
# commit logからも分りません(笑)
o SYS_FOPT/SYS_COPTの定義を ifndefを囲むのははぜ？
SYS_*OPT系は、ユーザーが定義すべきものでないオプション類を羅列するところなので
上書きを許す必要は無いと思います
# SYS_COPTの -pedantic-errorsで問題が出る場合は、ソースに問題があります
# SYS_FOPTの -ff90 -pedantic/-std=gnuで問題が出るならソースのスタイルが統一されてないためです
o config/GCC.specに _USE_G95が追加されていますが、_USE_*系変数(_で始まる変数)は
config/*.spec内部利用を意図してるので、ユーザーに公開するなら USE_G95=versionの形を推奨します
本格的に g95サポートを入れるなら mk/sad.compiler.mkにも手を入れるべきかと
o mk/sad.osdep,mkに追加された ifeq ($(HAVE_F_FGTEC),YES)はきちんと動きますか？
GNU make の conditional構文は制約が多く
if
if
else
endif
else
endif
の形式は分岐によっては、うまく動かなかったケースがあった気がするのですが...
o src/sim/fgetc_Dummy.fは、 fgetc実装前の gfortranで無理矢理 SADを動かす際に
作ったもので、改行記号までの入力行が長い場合や、他の read文との相互作用があった
場合に意図道理の動作をしない不完全な fgetcですが、実用に耐えられますか？
o SYS_DEPOBJ_FSEEKに sim/fgetc_Dummy.oを入れるのは邪道
fgetc_Dummy.oの必要性が version依存でないなら SYS_DEPOBJに直接書く
version依存なら _USE_*に g95の version番号を入れて SYS_DEPOBJ_FGETC変数を
version依存に定義して SYS_DEPOBJ+=$(SYS_DEPOBJ_FGETC)することを推奨します
o CVS repository内の oldsad/src/itfgetbuf_.c,vの アクセス権が正しく設定されていません
o Cによる itfgetbufの実装(src/itfgetbuf_.c)は read文と競合がある場合、一般には正しく
動かないと思われます。(Fortran I/O側の bufferingがあるため)
逆に、src/itfgetbuf_.cで問題ないなら、Fortran I/Oを捨てられるのでは？