On 2/20/2012 1:26 PM, Brice Goglin wrote:
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
Tests on the virtual node I have access to where that problem report
originated is still not quite right.
There is now a different assertion failing than I had seen before:
lt-linux-libnuma:
/users/phh1/
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
> Tests on the virtual node I have access to where that problem report
> originated is still not quite right.
> There is now a different assertion failing than I had seen before:
>> lt-linux-libnuma:
>> /users/phh1/OMPI/hwloc-1.3.2rc1-linux-ppc64-gcc/
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
>
>
> On 2/8/2012 8:58 AM, Jeff Squyres wrote:
>> * Fix conversion from/to Linux libnuma when some NUMA nodes have no
>> memory.
>
> Tests on the virtual node I have access to where that problem report
> originated is still not quite right.
> There is
Coolio. Thanks.
On Feb 10, 2012, at 2:16 PM, Paul H. Hargrove wrote:
>
>
> On 2/10/2012 11:00 AM, Jeff Squyres wrote:
>> Here's the final logic -- is it what you intended?
>
> Yes, that works for me.
> I pasted you version into config/hwloc.m4 on 1.3.2rc1 and faked the
> $hwloc_c_vendor sett
On 2/10/2012 11:00 AM, Jeff Squyres wrote:
Here's the final logic -- is it what you intended?
Yes, that works for me.
I pasted you version into config/hwloc.m4 on 1.3.2rc1 and faked the
$hwloc_c_vendor setting.
The results were the same as with my version.
(Yes, I did autoreconf to make sur
On Feb 9, 2012, at 5:38 PM, Paul H. Hargrove wrote:
>> We then test if *either* set the variable.
>> Sort of a double-negative.
>
> One of De Morgan's Laws:
>NOT (A AND B) = (NOT A) OR (NOT B)
>
> Applied to give:
>NOT (TEST1_FAIL AND TEST2_FAIL)
> = (NOT TEST1_FAIL) OR (NOT TEST2
On 2/9/2012 2:26 PM, Paul H. Hargrove wrote:
We then test if *either* set the variable.
Sort of a double-negative.
One of De Morgan's Laws:
NOT (A AND B) = (NOT A) OR (NOT B)
Applied to give:
NOT (TEST1_FAIL AND TEST2_FAIL)
= (NOT TEST1_FAIL) OR (NOT TEST2_FAIL)
= TEST1_PA
On 2/9/2012 2:07 PM, Jeff Squyres wrote:
On Feb 9, 2012, at 2:27 PM, Paul H. Hargrove wrote:
What you have for the "Make sure..." is wrong in the same way as the one that
was in rc1.
The problem is that the AC_COMPILE_IFELSE code tests too-few and too-many args
together.
Since xlc makes too
On Feb 9, 2012, at 2:27 PM, Paul H. Hargrove wrote:
> What you have for the "Make sure..." is wrong in the same way as the one that
> was in rc1.
> The problem is that the AC_COMPILE_IFELSE code tests too-few and too-many
> args together.
> Since xlc makes too many an error by default, we don't
Jeff,
What you have for the "Make sure..." is wrong in the same way as the one
that was in rc1.
The problem is that the AC_COMPILE_IFELSE code tests too-few and
too-many args together.
Since xlc makes too many an error by default, we don't notice its
MISbehavior when given too few.
So, one nee
On 2/9/2012 4:43 AM, Jeff Squyres wrote:
On Feb 8, 2012, at 4:44 PM, Brice Goglin wrote:
Jeff, can you fix everything reported in this thread locally and prepare
a new tarball for Paul?
Yes, just catching up on this thread now...
FWIW:
The system w/ xlc-11.1 also has up-to-date autotools.
On 2/9/2012 4:48 AM, Jeff Squyres wrote:
On Feb 8, 2012, at 6:02 PM, Paul H. Hargrove wrote:
The file config/hwloc_check_vendor.m4 that is present in trunk, is ABSENT in
the 1.3.2rc1 tarball.
There is, correspondingly, no call to _HWLOC_C_COMPILER_VENDOR in hwloc.m4.
Correct -- we hadn't us
How's this patch (against v1.3, assuming
https://svn.open-mpi.org/trac/hwloc/changeset/4285)?
Is the test that checks to see if compilers error when the wrong number of
params are passed now mooot?
Index: config/hwloc.m4
===
--- co
On Feb 8, 2012, at 6:02 PM, Paul H. Hargrove wrote:
> The file config/hwloc_check_vendor.m4 that is present in trunk, is ABSENT in
> the 1.3.2rc1 tarball.
> There is, correspondingly, no call to _HWLOC_C_COMPILER_VENDOR in hwloc.m4.
Correct -- we hadn't used $hwloc_c_vendor anywhere else in the
On Feb 8, 2012, at 4:44 PM, Brice Goglin wrote:
> Jeff, can you fix everything reported in this thread locally and prepare
> a new tarball for Paul?
Yes, just catching up on this thread now...
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/abo
On 2/8/2012 4:47 PM, Paul H. Hargrove wrote:
On 2/8/2012 4:41 PM, Paul H. Hargrove wrote:
I do agree w/ Samuel that the BEST solution is to apply "-qhalt=e"
ONLY to the test(s) where one expects the compiler to through errors
(rather than warnings) for function calls with argument counts
On 2/8/2012 4:41 PM, Paul H. Hargrove wrote:
I do agree w/ Samuel that the BEST solution is to apply "-qhalt=e"
ONLY to the test(s) where one expects the compiler to through errors
(rather than warnings) for function calls with argument counts which
don't match the prototypes. At the momen
On 2/8/2012 4:43 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit :
On 2/8/2012 4:31 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
Option #4:
CFLAGS='-qhalt=e -qsuppress=1506-077'
Appears to work for me fo
Samuel Thibault, le Thu 09 Feb 2012 01:43:56 +0100, a écrit :
> Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit :
> > On 2/8/2012 4:31 PM, Samuel Thibault wrote:
> > >Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
> > >>Option #4:
> > >>CFLAGS='-qhalt=e -qsuppress=1
Paul H. Hargrove, le Thu 09 Feb 2012 01:41:47 +0100, a écrit :
> On 2/8/2012 4:31 PM, Samuel Thibault wrote:
> >Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
> >>Option #4:
> >>CFLAGS='-qhalt=e -qsuppress=1506-077'
> >>Appears to work for me for xlc-8.0 and xlc-9.0.
> >That sti
On 2/8/2012 4:31 PM, Samuel Thibault wrote:
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
Option #4:
CFLAGS='-qhalt=e -qsuppress=1506-077'
Appears to work for me for xlc-8.0 and xlc-9.0.
That still looks dangerous to me: we don't know whatever warning
might be added in th
Paul H. Hargrove, le Thu 09 Feb 2012 01:28:53 +0100, a écrit :
> Option #4:
>CFLAGS='-qhalt=e -qsuppress=1506-077'
> Appears to work for me for xlc-8.0 and xlc-9.0.
That still looks dangerous to me: we don't know whatever warning
might be added in the future. I'd rather add -qhalt=e only for t
On 2/8/2012 2:08 PM, Paul H. Hargrove wrote:
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
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
Please test!
http://www.open-mpi.org/software/hwloc/v1.3/
I have access to BG/L, BG/P, Cray-XT and Cray-XE systems.
Are there any tests I could/should consider running on those?
-Paul
--
Paul H. Hargrove phhargr...@lbl.
On 2/8/2012 1:44 PM, Brice Goglin wrote:
Ah, we need to use $hwloc_c_vendor instead. That's where's
$hwloc_check_compiler_vendor_result ends up before being cleared.
It looks like something is very wrong here:
Examining the 1.3.2rc1 tarball I seem to see $hwloc_c_vendor is read but
NOT wri
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.
Lo
On 2/8/2012 1:37 PM, Brice Goglin wrote:
Let's ignore this for 1.3.2. libnuma sucks, we're wasting way too much
time trying to make it sane. I'll look later if I find an easy way to
reproduce.
OK, fine by me.
I've verified that if I "disarm" that test, then the remaining tests PASS.
-Paul
-
On 2/8/2012 1:44 PM, Brice Goglin wrote:
By the way, do we need -qhalt=E or -qhalt=e ? Your mail uses both.
They are equivalent according to my testing.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
HPC Research Department T
Le 08/02/2012 22:10, Paul H. Hargrove a écrit :
>> configure: WARNING: Please report this failure, and configure using a
>> different C compiler if possible.
>> configure: error: Cannot continue.
> configure: WARNING: Your C compiler does not consider incorrect
> argument counts to be a fatal error
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
>
>
> On 2/8/2012 8:58 AM, Jeff Squyres wrote:
>> * Fix conversion from/to Linux libnuma when some NUMA nodes have no
>> memory.
>
> Tests on the virtual node I have access to where that problem report
> originated is still not quite right.
> There is
On 2/8/2012 8:58 AM, Jeff Squyres wrote:
* Fix conversion from/to Linux libnuma when some NUMA nodes have no memory.
Tests on the virtual node I have access to where that problem report
originated is still not quite right.
There is now a different assertion failing than I had seen before:
l
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 L
On 2/8/2012 9:18 AM, Samuel Thibault wrote:
Jeff Squyres, le Wed 08 Feb 2012 17:59:04 +0100, a écrit :
Please test!
http://www.open-mpi.org/software/hwloc/v1.3/
Could somebody test it on AIX, and with xlc?
Thanks,
Samuel
No AIX, but I will hit xlc on Linux again today.
Do we care abo
Jeff Squyres, le Wed 08 Feb 2012 17:59:04 +0100, a écrit :
> Please test!
>
> http://www.open-mpi.org/software/hwloc/v1.3/
Could somebody test it on AIX, and with xlc?
Thanks,
Samuel
Please test!
http://www.open-mpi.org/software/hwloc/v1.3/
Here's the changes since 1.3.1:
* Fix missing last bit in hwloc_linux_get_thread_cpubind().
Thanks to Carolina Gómez-Tostón Gutiérrez for reporting the issue.
* Fix build with -mcmodel=medium. Thanks to Devendar Bureddy for reportin
35 matches
Mail list logo
