Minor bugs (?) found in 20Oct11 version

LAMMPS LAMMPS Mailing List Mirror
1

Hi.
One of our users has found a couple of minor bugs in the 20Oct11
version. Nothing earth shattering.
We tried compiling with the Sun compiler and it complained about these lines:

angle_cosine_periodic.cpp:
Lines 141, 142, 289
Ambiguous calling of std::pow (it expects a float or double, not an int)
Fixed by changing "pow(-1, ...)" to "pow(-1., ...)"

min_hftn.cpp:
Lines 280, 1151
Ambiguous calling of std::sqrt (expects a flaot or double, not an int)
Fixed by changing "sqrt(...)" to "sqrt(static_cast<double>(...)"

Cheers.
Duncan

2

I'm unclear why this is a problem. LAMMPS should be
calling the original C versions of math.h routines, not std::sqrt(),
and I believe those routines cast all their args to double,
which is in fact the C standard.

Is the Sun compiler doing something different and non-standard?
Does the Sun C compiler (not C++) complain about sqrt(1)?

Are there no other calls to math.h functions in the code (all packages)
that complain?

Steve

3

Hi Steve.
Sorry for not getting back to you sooner, I was off on a training
course for most of last week.

It appears to be an issue for the Sun C++ compiler. The C compiler
only provides one implementation of sqrt and pow (using a double), but
the C++ compiler also provides a float version in the std namespace
(though you are not explicitly using it, so I'm not sure why the
compiler is trying to). We've found a few other places with all of the
packages installed where this occurs:

These are all ambiguities between fabs(double) and std::fabs(float)
compute_ke_atom_eff.cpp: 99
compute_ke_eff.cpp: 74
compute_temp_deform_eff.cpp: 111,162,213
compute_temp_eff.cpp: 82, 116, 155
compute_temp_region_eff.cpp: 118,131,177
fix_nh_eff.cpp: 61, 88, 109
fix_nve_eff.cpp: 100, 135
fix_nvt_sllod_eff.cpp: 124

The example below compiles fine with the suncc compiler but complains
with the sunCC (C++) compiler as shown below.

#include "math.h"
#include "stdio.h"

int main()
{
   printf("sqrt(2) = %f\n", sqrt(2));
   printf("pow(2, 2) = %f\n", pow(2, 2));
}

compiles fine with suncc but fails to compile with sunCC

Same errors:
"lammps-sun.c", line 7: Error: Overloading ambiguity between
"sqrt(double)" and "std::sqrt(float)".
"lammps-sun.c", line 8: Error: Overloading ambiguity between
"std::pow(double, int)" and "std::pow(long double, int)".
2 Error(s) detected.

4

hi duncan,

please have a look at the compiler manpage.
there has to be some flag that controls this
behavior. most likely it will be a setting relating
to standards conformance. it looks that the
compiler is overly eager to enforce strict conformance
with how its writers perceive the latest c++
standards. perhaps there is a way to have
it revert to a more relaxed behavior.

another thing worth trying would be to try using

#include <cmath>

instead of

#include "math.h"

since the former is supposed to imply
c semantics for math library functionality.
using math.h has been discouraged for
quite a while now.

thanks,
    axel.

5

Hi Axel.
No joy with <cmath> or finding a flag to turn it off. I've had a
google for the problem and found that Sun have introduced some extra
overloads for common maths functions, and this is causing the
ambiguity. It seems to be a fairly common problem. In each case they
recommend explicitly casting the types.

Cheers,
Duncan