Re: Ambiguous interfaces in gfortran -- who's right?
- From: "James Van Buskirk" <not_valid@xxxxxxxxxxx>
- Date: Tue, 6 Nov 2007 11:58:26 -0700
"Jugoslav Dujic" <jdujic@xxxxxxxxx> wrote in message
news:5pau3sFqfv2gU1@xxxxxxxxxxxxxxxxxxxxx
James Van Buskirk wrote:
| I looked at your xeffort stuff and there were a lot of desirable things
| in there but installation with Xeffort_IVF_1221.exe said I didn't have
| IVF 9.0 whereas I had IVF 9.1.
1.2.22 is the last version. The installer is written in InnoSetup, and
its maintenance has been an uphill struggle against Intel and Microsoft
ever-changing registry conventions and abundance of VF/VS versions.
I thought I was getting the latest version last night. Perhaps I was
tired, or perhaps it's just not obvious from your website.
Bug reports are always welcome; the setup should leave a file named
XeffortSetupIVF.log along the installer's exe, for [sort of] debugging
purposes. Checking my CVS history of the installation script, I see
something was changed between 1.2.21 and 1.2.22, but I'm not sure if
it affects the behavior you describe.
Starting setup...
Can't find any VF integration installations
No Intel Fortran installed!
actually, it will complain if the Intel Visual Studio *integration*
is not installed -- is it ? -- and the version numbers are bad (it
supports
all the way from 8.1 to 10.0).
Looking under start->control panel->add or remove programs, it says I
have Intel(R) Visual Fortran Compiler 9.1 Integrations in Microsoft
Visual Studio* installed
| Also some files such as xftapity.f90
| have issues. Do you have a program that generates these out of C header
| files (that could possibly be fixed) or is everything done by hand?
It's done by hand; [often blatantly violating copyright by copying from
DFWIN*.f90 files :-D ]. What issues?
Well, pointers and handles should be typed as INTEGER(INT_PTR_KIND) in
CVF and early versions of ifort. In the latest versions of ifort and
gfortran, enough f03 is available that the transportable INTEGER(C_INTPTR_T)
is the right thing to do. A concise reference:
http://www.jorgon.freeserve.co.uk/GoasmHelp/64bits.htm#datat
Also functions that return a BOOL should be typed as returning a
default INTEGER, because BOOL is an alias for int in the Windows
headers somewhere. A while back I posted an example where I showed
that some compilers, including the version of ifort I an using now,
could violate truth tables if given LOGICAL values that weren't
set via literals or intrinsic operators. I was going to post the
whole thing again, but it occurred to me that it is better to
simply reference the message:
http://groups.google.com/group/comp.lang.fortran/msg/87afb6ac1ff0509e
Now, I was criticized for expecting that truth tables should still
be valid for LOGICAL values that were set other than through literals
or intrinsic operators but in the meantime, perhaps Intel has fixed this:
http://softwarecommunity.intel.com/isn/Community/en-US/forums/post/30239918.aspx
But the issue is that setting LOGICAL variables to arbitrary values can
create situations where truth tables don't work any more, at least on
some compilers including an old version of ifort. Since C programs
routinely set variables to arbitrary values and then use the results
in logical contexts such as if statements, it's quite dangerous for
Fortran programs to accept anything C returns as a LOGICAL value. A
classic example in C++ is if(ins && ins.good()) ... where ins is an
instance of a complicated class. A more portable way to handle these
return values is
if(transfer(MessageBox(hWnd,lpText,lpCaption,uType),1) /= 0) then...
portable in the sense that even if the interfaces you're using specify
LOGICAL return values, they can be treated properly as INTEGERs. Oh
well, enough ranting about Windows interfacing issues. Have you seen
my example http://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin.f90
that works in gfortran? I think it should work in ifort, too, but
there may be a bug preventing it from working in *32 mode, at least
that's my take on another thread from Intel's website. It would
be nice to have a more portable BINC(C) version of xeffort, but I
think that even then gfortran would need significant upgrading to
do Windows: I think it can't do STDCALL so for now only x64 works,
and it seems there is no way to create a /subsystem:windows program,
only /subsystem:console. Maybe g95 can do better but I haven't looked
at it since I went x64.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
.
- References:
- Ambiguous interfaces in gfortran -- who's right?
- From: Rich Townsend
- Re: Ambiguous interfaces in gfortran -- who's right?
- From: Tobias Burnus
- Re: Ambiguous interfaces in gfortran -- who's right?
- From: Jugoslav Dujic
- Re: Ambiguous interfaces in gfortran -- who's right?
- From: James Van Buskirk
- Re: Ambiguous interfaces in gfortran -- who's right?
- From: Jugoslav Dujic
- Ambiguous interfaces in gfortran -- who's right?
- Prev by Date: Re: Procedure-ness in Generic Resolution
- Next by Date: Re: How to set my own program startup in f77 programs other than MAIN__
- Previous by thread: Re: Ambiguous interfaces in gfortran -- who's right?
- Next by thread: Re: Ambiguous interfaces in gfortran -- who's right?
- Index(es):
Relevant Pages
|
Loading
