Le 13/03/2012 18:57, Samuel Thibault a écrit : > Brice Goglin, le Tue 13 Mar 2012 18:55:29 +0100, a écrit : >> Le 13/03/2012 17:04, Hartmut Kaiser a écrit : >>>>> But the problems I was seeing were not MSVC specific. It's a >>>>> proliferation of arcane (non-POSIX) function use (like strcasecmp, >>>>> etc.) missing use of HAVE_UNISTD_H, HAVE_STRINGS_H to wrap >>>>> non-standard headers, unsafe mixing of >>>>> int32<->int64 data types, reliance on int (and other types) having a >>>>> certain bit-size, totally unsafe shift operations, wide use of >>>>> (non-C-standard) gcc extensions, etc. Should I go on? >>> More investigation shows that the code currently assumes group (and >>> processor) masks to be 32 bit, which is not true on 64 bit systems. For >>> instance this (topology-windows.c: line 643): >>> >>> hwloc_bitmap_from_ith_ulong(obj->cpuset, GroupMask[i].Group, >>> GroupMask[i].Mask); >> Try applying something like the patch below. Totally untested obviously, >> but we'll see if that starts improving lstopo. > That won't work on 32bit systems, where the mask is 32bit only
Of course. I am just trying to see if we can get something working better on 64bits or if there are other problems. Brice