Does Cray fix such bugs quickly usually? If so, no need to change hwloc. If not, I'll need somebody to test the change on other cray platforms and compiler versions.
Brice



Jeff Hammond <jhammond@alcf.anl.gov> a écrit :
This is a bug in the Cray compiler.  They cannot and should not set
the __GNUC__ flag unless they are fully compatible with GCC. There
are many ways to define "fully compatible" but at a minimum, code that
compiles with GCC needs to compile with any compiler that elects to
define __GNUC__. It is prudent to impose a higher standard in some
cases but that's not pertinent to this discussion.

Lots of vendor compilers pretend to be __GNUC__ for any number of
reasons. I believe that they are all wrong for doing it.

Regarding this specific issue, there is nothing wrong with hwloc and I
don't know why anyone should bother trying to fix Cray's problem, but
I suspect that pragmatism will prevail, as it appears to have in the
case of Boost (http://www.boost.org/doc/libs/1_52_0/boost/config/select_platform_config.hpp).

I'll reproduce this locally and contact Cray directly about fixing
this on their end.

Best,

Jeff

On Thu, Jan 17, 2013 at 12:19 PM, Erik Schnetter <schnetter@gmail.com> wrote:
hwloc-1.6.1rc2 fails to build with the Cray compiler

Cray C : Version 8.1.2 Thu Jan 17, 2013 12:18:54

The error message is

CC bitmap.lo
CC-147 craycc: ERROR
Declaration is incompatible with "int ffsl(long)" (declared at line 526 of
"/opt/cray/xe-sysroot/4.1.20/usr/include/string.h").

(Yes, there is no line number with the error message.)

This seems to be caused by the fact that the Cray compiler sets __GNUC__,
but is not quite compatible. A work-around is to change line 56 of
include/private/misc.h from

#elif defined(__GNUC__)

to

#elif defined(__GNUC__) && !defined(_CRAYC)

-erik

--
Erik Schnetter <schnetter@gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/



hwloc-users mailing list
hwloc-users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-users