Hello,
Thanks for the logs.
Pavan Balaji, le Thu 22 Oct 2009 09:57:30 -0500, a écrit :
> topology.c(74): remark #869: parameter "objs" was never referenced
> topology.c(452): remark #981: operands are evaluated in unspecified order
Such remarks are ok. (Google says 981 is really pedantism)
> topology-linux.c(839): (col. 7) remark: LOOP WAS VECTORIZED.
Such remarks are really ok :)
> traversal.c(24): warning #188: enumerated type mixed with another type
This is because we do not include HWLOC_OBJ_TYPE_MAX and UNKNOWN in
the enumeration. One problem with adding them (MAX, in particular) is
that then the compiler will warn if one doesn't handle these cases in a
switch, even if we know they can never happen. From the application
point of view there should always be a default: case anyway since we may
introduce other types of objects, so maybe we should include them and
add cases that just assert(false);
> topology-linux.c(787): remark #593: variable "proc_oscoreids" was set but
> never used
> unsigned proc_oscoreids[] = { [0 ... HWLOC_NBMAXCPUS-1] = -1 };
Heh, good catch. We indeed do not need it any more to manage the
computation. Brice, do you think we could just get rid of it?
> PGC-W-0095-Type cast required for this conversion (topology.c: 627)
> PGC-W-0155-Pointer value created from a nonlong integral type (topology.c:
> 627)
Should be fixed now.
> PGC-W-0155-Long value is passed to a nonprototyped function - argument #1
> (cpuset.c: 453)
I hope r1235/1236 will fix it.
> PGC-W-0006-Empty translation unit (lstopo-cairo.c: 6)
> PGC-W-0006-Empty translation unit (lstopo-xml.c: 6)
These are expected.
> PGC-W-0221-Redefinition of symbol CPU_SET
> (/radix-homes/software/com/packages/pgi-9.0-4/linux86-64/9.0-4/include-gcc40/sched.h:
> 20)
This is the probable culprit of the final link failure. It's odd that
pgcc provides its own copy of sched.h, isn't it supposed to just use
glibc's? I'm not surprised bugs may appear, I'd tend to think that the
bug is rather in pgcc.
Samuel
