On 2/8/2012 1:10 PM, Paul H. Hargrove wrote:
> On 2/8/2012 8:58 AM, Jeff Squyres wrote:
>> * Detect when a compiler such as xlc may not report compile errors
>> properly, causing some configure checks to be wrong. Thanks to
>> Paul H. Hargrove for reporting the problem and providing a patch.
> Looks like I botched this one!
> I have added two Linux/ppc64 machines the xlc-7.0, xlc-8.0 and xlc-9.0
> to my testing.
> These are NOT running on the odd virtual node that caused assertion
> failures when testing xlc-11.1.
I've applied the patches I included, and tested on the xlc-11.1 system
where auto tools are new enough.
Everything looked fine.
Now I've had a chance to retest earlier xlc (8 and 9, which are on 2
different machines), with the explict CFLAGS=-qhalt=e.
The result was NOT good.
It seems that xlc dislikes some wchar constants (see below).
In a build w/ default CFLAGS they produce an "(E)" level message, but
compilation continues to completion.
With the recommended CFLAGS=-qhalt=e these become fatal:
> CC lstopo-lstopo-text.o
> line 1203.34: 1506-1385 (W) The attribute "pure" is not a valid type
> line 450.12: 1506-077 (E) The wchar_t value 0x250c is not valid.
> line 451.12: 1506-077 (E) The wchar_t value 0x2510 is not valid.
> line 452.12: 1506-077 (E) The wchar_t value 0x2514 is not valid.
[followed by another error for each case in the switch statement].
So, now I am not sure what to recommend. Options include:
+ Don't worry about old xlc (which OMPI doesn't support since they can't
build the opal atomics).
+ Rig things to use -qhalt=e ONLY for configure, but not for make?
+ Punt on 1.3 and revisit later
By the way:
xlc-11.1 on Linux doesn't make these complaints on lstopo-lstopo-text.
Nor does xlc-6.0 on MacOS-10.3 (honest, I am not making this up).
[And, YES, both platforms define HAVE_PUTWC]
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900