Compiler Options

[Neal Kruis]

For the sake of consistency between builds of EPx and EnergyPlus, it would be helpful to standardize the compiler options used to build the executables.

For EPx, we are currently compiling using gfortran with the following options (a.k.a. flags):

Release Flags: -O -static-libgcc -static-libstdc++ -static-libgfortran

Debug Flags: -g

Both: -cpp -ffree-line-length-none -fimplicit-none

These flags can be modified by editing the CMakeLists.txt file in the EPx source directory (currently only on the epx_dev branch).

EnergyPlus releases are compiled using Intel Fortran, which has different (though similar) compiler options. However the compiler options are not included with the distributed source code. Can anyone share what flags are used for the official releases?

Also, if you have any experience building EPx/EnergyPlus using other flags that you think are useful, please share those with the group. Hopefully together, we can come to a consensus for a set a flags that can be used for releases and debugging on either compiler.

Thanks!

Neal Kruis

[Stuart Mentzer]

Standardizing the switches is a good idea but there are situations where you may want to use variations, such as when building new code when you should enable more diagnostic options to find problems.

Here are some notes on additional gfortran switches.

All Builds:
 -pipe  Faster builds
 -std=f2008 (or f2003) -pedantic -fall-intrinsics   To find standard compliance issues. The -fall-intrinsics gives you non-standard intrinsics (like ERF with f2003 and ISNAN because gfortran doesn't yet have IEEE_IS_NAN)
 -DWINDOWS or -DLINUX or -DMAC   To signal the platform for DataStringGlobals.f90
 -m64 or -m32  Build as 64 or 32 bit (override default of host OS)
 -march or -mtune  Can improve performance (usually slightly) on newer CPUs

Debug:
 -Wall -Wextra -Wconversion-extra   Show potential problems with the code: Recommend -Wall always and the others for new code
 -Wno-unused -Wno-unused-parameter -Wno-unused-dummy-argument   Suppress unused item warnings: EP has a lot of unused items: Recommend not using these for new code
 -Og   For faster runs than -O0 that are still debuggable
 -ggdb   More compatible with gdb debugging than -g

Release:
 -O2 or -O3 or -Ofast   Based on experiments to see which is fastest (-Ofast results should be validated)
 -DNDEBUG   So we can start using assertion tests (add-on tool)
 -s   Strip debugging information for smaller executables

I'll add some notes on Intel Fortran options separately.

Stuart

[Stuart Mentzer]

For Intel Fortran the first thing to note is that the options are different between the Windows and Linux compilers. The Linux compiler has some GCC/gfortran options and the Windows compiler has some Visual C++ options and then there are some that are the same on Linux and Windows and some where the Windows version of an options is of the form /Qoption where the Linux version is -option. In short, confusing. Just looking at Intel Fortran on Windows here are the options I'm using so far:

All Builds:
 /nologo   Just to suppress the banner display
 /fpp   Turn on preprocessing for the #ifdef blocks in the code and to allow assertion macros
 /stand:f03   Check Fortran 2003 compliance: Could use f08 if F2008 is preferred standard now
 /Qdiag-disable:5268   Suppress silly warnings about lines longer than 132 characters that the /stand option turns on: I have checked the EnergyPlus code and only end of line comments exceed 132 after a few line wrap fixups
 /fpscomp:none   Disable all Microsoft Fortran PowerStation compatibility extensions for max standard compliance
 /DWINDOWS   Define the platform for DataStringGlobals.f90 #ifdef blocks (would be /DLINUX or /DMAC on those platforms)
 /nogen-interfaces   Disable atuo-generation of interface source code: EnergyPlus defines the interfaces that it needs. There may be a value to using /gen-interfaces for catching errors in CALLs but I haven't explored that yet.

Debug:
 /warn:declarations,interfaces   Warn about undeclared variables (shouldn't be any since EP code mandates IMPLICIT NONE), and check routine calls against any interfaces.
 /Od   Optimization level for debugging
 /Z7   Generate full debugging information in the object files (/Zi or /debug will cause .pdb files to be created with the debugging info)
 /traceback   Add traceback info to object files to tell you the call stack when a runtime error occurs
 /check:all   Check for a few kinds of errors at run time
 /Gs0   Full stack checking
 /Qfp-stack-check   Floating point stack checking
 /Qtrapuv   Help catch uninitialized variables by setting local variables without initializers to special values

Release:
 /O2   Optimize for performance: We should try /O3 to see if it gives improvement worth the extra compile time
 /Qx and /arch  Setting these for the target platform may improve performance and should be tried
 /DNDEBUG   So we can start using assertions

I hope this is helpful. I'm sure that there are other options that may be useful.

I have also done builds for Intel SSA (static testing) if anyone wants to see options for that. (SSA is in Parallel Studio but is not included with the basic compiler packages.)

Stuart

[Stuart Mentzer]

I found a test case that gave a stack overflow using a Intel Fortran Windows debug build so I am amending my suggestions to add a larger stack. The default on Windows is 1 MB and EnergyPlus has some RECURSIVE routines that exhaust this stack size. I found that an 8 MB stack worked for the case that failed and, until I find a case that overflows that I'll be sticking with it (unless someone else has more information on this). Info to set an 8 MB stack...

Intel Fortran
 Add /F8388608 to the ifort compile options
 Add /STACK:8388608 to the linker options (if you use xilink or link to do linking instead of ifort)

MinGW GFortran
 Add -Wl,--stack,8388608 to the linking options (assuming you use gfortran to link and don't call ld directly)