[gmx-users] pointer errors when compiling parallel mdrun with intel compiler

[Mark Abraham]

Lubos Vrbka wrote:
> hi guys,
> 
> would please anybody suggest how to solve the following problem? i am 
> really hopeless... single processor version compiled without any 
> problems. for both, i use intel compiler version 9.1.

It looks like it is enforcing a more pedantic C dialect. You will be 
able to turn these types of error messages off en masse.

> thank you in advance for any hints. i personally don't see any problem 
> in assigning pointer to void to pointer to some other type, but it seems 
> that this compiler has another attitude :( unfortunately i cannot use 
> anything else and need to get gromacs running.

As you realise, objecting here is just a higher level of pedanticism. 
They appear to be non-fatal errors, as you'd hope.

> interestingly, it doesn't stop here and goes on, where it stops completely:
> 
>  mpiFCC -compiler intel -DHAVE_CONFIG_H -I. -I. -I../../src 
> -I/usr/X11R6/include -I../../include 
> -DGMXLIBDIR=\"/home/users/se7/software/gromacs-3.3.1/share/top\" 
> -I/home/users/se7/software/fftw/include -mp -DANSI 
> -I/usr/local/vni/imsl/cnl600/itanium/include -MT constr.lo -MD -MP -MF 
> .deps/constr.Tpo -c constr.c -o constr.o
> constr.c(154): error: a value of type "void *" cannot be assigned to an 
> entity of type "int *"
>         snew(owptr,nsettle);
>         ^

snew is a macro defined in include/smalloc.h where you'll see the reason 
for the error - (void *) save_calloc is called and the return value 
assigned to the first parameter. A RHS typecast would fix this, but you 
can't make that work in the macro, so again I suggest finding a way to 
turn off this error.

Mark