Le 13/03/2012 19:08, Hartmut Kaiser 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,
>> Try applying something like the patch below. Totally untested obviously,
>> but we'll see if that starts improving lstopo.
> Partially better, but mostly just differently wrong :-P (see attached debug
> output and straight console output of lstopo)
Thanks. The remaining problems don't look obvious. Something strange
seems to happen right after the windows backend added all objects. I
wonder if we have some problems in the bitmap management code. Can you
try to run some tests ? Maybe not all of make check, but at least those
that have "bitmap" in their name.