[Users] PGI configuration on trestles (maxwell release)

Bruno C. Mundim bcmsma at astro.rit.edu
Sun Apr 15 16:03:58 CDT 2012


Hi,

I am trying to put together a configuration file using PGI compilers
(10.5) on trestles and I am facing a few problems. I am using the
Maxwell release as code base and currently my configuration is quitting
with an error when compiling  Cactus/arrangements/LSUThorns/Vectors
/src/test.cc. The error message is the following:

~/Cactus/arrangements/LSUThorns/Vectors/src/test.cc", line 172: error:
           no suitable user-defined conversion from "const __m128d" to 
"__m128i"
           exists
     VECTEST("kifpos positive",
     ^
I am using the following vector options:

VECTORISE                = yes
VECTORISE_ALIGNED_ARRAYS = no
VECTORISE_INLINE         = no

Does anyone have any idea on how to avoid/fix this? Actually, was this
already fixed in the development branch? I would like to avoid using
the development branch until I have a working configuration though.

Also, when putting together this configuration file I looked into
several ones at simfactory/mdb/optionlists that would use pgi10
compilers. Inspecting in more detail the one for hopper,
hopper2-pgi10.cfg, I got puzzled by several options adopted there.
I understand that the system there is a Cray one while trestles
uses linux Centos5, so some options are really system dependent, but
others I found quite intriguing and couldn't justify for.
I hope someone with more experience with the pgi compilers could shed
some light on the issues I found below. Here they are:

1) FPPFLAGS = -traditional: This is a flag for the fortran preprocessor
that seems to be widely used in several config files. Virtually every
config file uses cpp as preprocessor and I believe most of them if not
all uses the GNU cpp. The trouble is that there is no such a flag for
the most recent GNU cpp. What I could find was -traditional-cpp. So
my question is: is this flag actually relevant? isn't already being
ignored by the preprocessor?

2) CXXFLAGS = -g -DCRAY_XT --exceptions -D_ISOC99_SOURCE -D_BSD_SOURCE
Here I see three issues:
  2.1) I would use -g option only for debugging, otherwise optimization
could be affected with PGI compilers. The manual suggests to use -gopt
for optimization. This way the symbols would still be present without
impacting optimization.
  2.2) PGI optimization manual suggests that the user code do not handle
exceptions in order to produce faster codes. I was wondering if it would
be ok to move the --exceptions flag to CXX_DEBUG_FLAGS and add
--noexceptions to  CXX_OPTIMISE_FLAGS. Would Carpet/AHFinderDirect
work properly with these changes? What is your opinion on it?
  2.3) Why is the -D_ISOC99_SOURCE -D_BSD_SOURCE feature macros for
GNU C Library needed here? I checked Cactus code and codes in
arrangements and none of them use these macros. Also the counterpart
intel config file doesn't use them either. So it doesn't seem to be
system dependent options. Could anyone explain their need here?

3) F90FLAGS = -g -Mx,125,0x200 with the explanation: "allow calling C
varargs functions from Fortran". Anyone could point to a PGI manual that
mention this option? I couldn't find any so far.

4) LDFLAGS = -Wl,--allow-multiple-definition -Bstatic: Isn't the linker
option --allow-multiple-definition a little bit dangerous? Right now
I can't build GSL 1.14 since it quits with multiple definition of
symbols kind of error if I don't use this flag. I would be tempted to
build GSL with that flag, but not all the other code base. In any
case, your opinion is appreciated here.

Thanks,
Bruno.









More information about the Users mailing list