Bug report about compiling the USER-MISC package

Dear LAMMPS developers,

When I compile the USER-MISC package in the latest stable version of LAMMPS (lammps-10Aug15), encounters the following error:

Dear LAMMPS developers,

When I compile the USER-MISC package in the latest stable version of
LAMMPS (lammps-10Aug15), encounters the following error:

​what OS/Hardware/Compiler are you using​?

this code compiles without a problem using GCC.
i am frequently building binary RPMs and windows installers with various
settings and Linux versions as well as running continuous integration
testing and this never failed because of the error message below.

--------------------------------------------------------------------------------------------------------------------------------------
../pair_list.cpp(88): error: expected a ";"
     const dbl3_t * _noalias const x = (dbl3_t *) atom->x[0];
                             ^

../pair_list.cpp(89): error: "restrict" has already been declared in the
current scope
     dbl3_t * _noalias const f = (dbl3_t *) atom->f[0];
              ^

../pair_list.cpp(89): error: expected a ";"
     dbl3_t * _noalias const f = (dbl3_t *) atom->f[0];
                       ^

../pair_list.cpp(114): error: identifier "x" is undefined
       const double dx = x[i].x - x[j].x;
                         ^

../pair_list.cpp(160): error: identifier "f" is undefined
         f[i].x += dx*fpair;
         ^

../pair_list.cpp(166): error: identifier "f" is undefined
         f[j].x -= dx*fpair;
         ^
compilation aborted for ../pair_list.cpp (code 2)
make[1]: *** [pair_list.o] Error 2
make: *** [mpi] Error 2

--------------------------------------------------------------------------------------------------------------------------------------

And then I find that the error is due to the following codes in
pair_list.cpp:

   const dbl3_t * _noalias const x = (dbl3_t *) atom->x[0];
   dbl3_t * _noalias const f = (dbl3_t *) atom->f[0];

And it's interesting that it can be compiled successfully using the
pair_list.cpp with also these two lines.

After reading the pair_list.cpp carefully, I realize that:

(1) For the old version of LAMMPS, there exists the following definition:

#if defined(__GNUC__)
#define _noalias __restrict
#else
#define _noalias
#endif

which is related to _noalias.

(2) But for the latest version, no the above definition, so the
compiling error occurs.

​that macro has been moved to lmptype.h​

(3) And then I change the two lines in the pair_list.cpp to be

   const dbl3_t * const x = (dbl3_t *) atom->x[0];
   dbl3_t * const f = (dbl3_t *) atom->f[0];

Then the compiling error disappears !

But I'm not sure if we should delete the word "_noalias", and please fix
this bug for compiling USER-MISC.

​it is more likely a bug in the compiler you are using.

axel.​

Dear axel.

OS: Linux
Hardware: The HPC-Cluster consists of Intel Xeon-based 8- to 128-way SMP nodes. (Read from HPC User's Guide </pages/viewpage.action?pageId=3473705>)
Compiler: Intel
mpicxx -g -O3 -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX=1 -M ../write_restart.cpp > write_restart.d
.....

It can works if I delete the word "_noalias", but will it influence the simulations results?

If it has an effect on the simulation results, I will change the compiler to be gcc, as you suggested.

Thanks.

Best regards,
Xiaoliang

Dear axel.

OS: Linux
Hardware: The HPC-Cluster consists of Intel Xeon-based 8- to 128-way SMP
nodes. (Read from HPC User's Guide
<http:///pages/viewpage.action?pageId=3473705>)
Compiler: Intel
mpicxx -g -O3 -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX=1
-M ../write_restart.cpp > write_restart.d
.....

It can works if I delete the word "_noalias", but will it influence the
simulations results?

​no. it will only affect how well the compiler can optimize the affected
subroutine(s). any impact on simulations would be equivalent to turning
other optimizations on or off. ​the purpose of this macros is to tell the
compiler that pointer variables point to address space that no other
pointers will be pointing to. by default a C/C++ compiler has to assume
they do and thus cannot do particular optimizations.

axel.