Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646

Name and date of exe at runtime?


I would like to print the name and compile date of the running exe near the start of the program outpu; ie. so the output is tagged with the actual version of the program exe that generated the output.

Is it possible to 'access' the name and compile date during runtime?  

Or is the only way to use a separate wrapper program?

The former option is strongly preferred

0 Kudos
9 Replies
Black Belt

Here is a partial solution:  Note that the date and time in LOCDATE is packed, and needs UNPACKTIMEQQ to convert to normal date values.


type (FILE$INFO) :: FileInfo

integer (ULONG_PTR) :: hFileInfo

integer (DWORD) :: ret

CALL GETARG(0, exe_pname)

hFileInfo = FILE$FIRST

ret = GETFILEINFOQQ (exe_pname, FileInfo, hFileInfo)

IF (ret.NE.0) LOCDATE = FileInfo%Lastwrite


Black Belt

The first (name) is possible within the confines of the standard and current ifort.  Use GET_COMMAND_ARGUMENT with a NUMBER of zero to retrieve the name by which the program was invoked.  (Whether this is really the name that you actually want to reported is a different matter.)

The compile date (and perhaps the program name, depending on what you want) more than likely need the use of some sort of extension.

I tend to compile the source file that hosts my main programs with the /fpp flag, and then reference in a character constant or similar the predefined preprocessor symbols __DATE__ and __TIME__.  Module dependencies typically mean that a main program will often be recompiled when a different source file in the project is compiled (though if the modules referenced are in a separate static library project that isn't the case - you may just get the existing object code for the main program linked in - not sure whether this is by design or an oversight in the Intel Fortran VS integration).

But "actual version" can mean a few different things.

I tend to pop my source code control systems file version identifier into a character parameter in each significant source file, and reference all those parameters when detailed version information is requested by the user.  I use subversion - so I have something like

[fortran]CHARACTER(*), PARAMETER, PUBLIC :: source_file_version = '$Id:$'[/fortran]

in the specification part of relevant modules (and also in the main program too).  I've not done this in Fortran builds, but when using other languages I've had pre-build steps that extract and stash the current tree revision into the executable.

Specific to Windows there are fields in the executable itself that you can query with the appropriate API, and there's also the VERSION resource that you can play with as well.  I used to have a non-fortran VS build setup that used to construct the relevant .rc fragment automatically (or perhaps it was stuff for the .msi version), bumping build numbers, etc whenever a Release build was attempted.  I think that was done using VS's macro support. 

(If the GET_COMMAND_ARGUMENT description of the program doesn't suit then perhaps the Win32 GetModuleFileName(NULL, ...) API might help.)

F2008 has added some extra stuff to the ISO_FORTRAN_ENV intrinsic module that could also be relevant for detailed description of how the program was built (COMPILER_OPTIONS, etal), but I don't think that's in current ifort.


Ian is correct that COMPILER_OPTIONS isn't yet supported, though that wasn't what was asked for.

The compiler does define preprocessor variables __INTEL_COMPILER and __INTEL_COMPILER_BUILD_DATE that can help in identifying the compiler version used. David lists the ones for date and time. In response to David's question about what these represent, it is the compile date of the source in which the reference appears, so if you put these in a module, it will be when the module was compiled.


Thanks to all for the information. I am (initially?) after the name and date of the exe that is running.

GET_COMMAND_ARGUMENT / GETARG sorts the name of the exe and at least for now will use GETFILEINFOQQ to get the date of last modification for the exe.

I had not thought about the issue of different compile dates for each source file.  Does make sense but there are rather a lot of those.  For now the date of last modification for the exe will be sufficient.

Unfortunately I encountered another problem (separate topic), so have not tested the above yet.

Again, thanks


A quick update:  Implemented as

    CALL GET_COMMAND_ARGUMENT (0, exe_name, var_len)
    hFileInfo = FILE$FIRST
    ret = GETFILEINFOQQ (TRIM(exe_name), FileInfo, hFileInfo)
    if (ret /= 0) CALL UNPACKTIMEQQ (FileInfo%Lastwrite,iyr,imon,iday,ihr,imin,isec)

Seems to work fine, apart from one oddity: the creation time (Lastwrite) extracted by UNPACKTIMEQQ is 1 hr later than actual; eg:

I compiled @ 11:52am (5 April 2013) and ran 'immediately'.  Reported date & time values extracted from FileInfo%Lastwrite were as follows:

  iyr  = 2013
  imon = 4
  iday = 5
  ihr = 12  <<<<<<<< = 1 hr in the future!
  imin = 52
  isec = 15
  (values from debug window - had set a break point just beyond the above statements)

Since it was still 11:52(am), the reported time was 1 hr in the future (& 1 hr in advance of my PC time).  And since I am in New Zealand & still on daylight saving time (just), there is nowhere in the world that is 1 hr later; ie. it is not as if it is reporting the time for some other location.

(the "Date created" time reported in File Explorer was correct; ie showed as "5/04/2013 11:52am")

Do others get a time that is 1 hour later than the actual value?

Black Belt


I'm in Western Australia, but we do not have Daylight Saving - I have enever noticed a problem like this.

Bu this topic also addresses this issue:

Black Belt

I see the same as you.  I am also just in a daylight savings zone - I suspect something is getting confused/double counting a daylight savings correction - set the TZ environment variable to a non daylight savings value (regardless of timezone) and things come good.  Some confusion is understandable when you read the section on daylight savings time in the context of file times on Windows here.

My dairy cows are always similarly confused around this time of year. At least next week my curtains will stop fading.


Slight aside : DATE_AND_TIME does generate the correct time. 

Now that I am printing the program exe creation date & time below the runtime, it does look a bit odd with the exe file creation time being 1 hour after than the runtime.

New Contributor I

Just to be sure: Did I understand correctly that the lowest time resolution you can get on a Windows system is 10 msec, regardless of the function called?