Hi,
I still get warnings for unused parameters from the hwloc/helper.h
header. The code to check this attribute is this:
int square(int arg1 __attribute__ ((__unused__)), int arg2);
int square(int arg1, int arg2) { return arg2; }
But this results in this conflig.log output:
c
There is also a problem, that these __hwloc_attributes defines don't
get through after install:
$ gcc -DHAVE_CONFIG_H -I.
-DSYSCONFDIR=\"/home/wesarg/opt/htop-dev/etc\"
-I/home/wesarg/opt/hwloc-dev/include -W -Wunused-parameter -Wall
-std=gnu99 -D_XOPEN_SOURCE_EXTENDED -g -O2 -MT htop-AffinityPa
Bert Wesarg wrote:
> There is also a problem, that these __hwloc_attributes defines don't
> get through after install:
>
Are you using the embedding stuff ? Or only including our headers ?
There's no guarantee that your external application will use the same
compiler, so unless the embedding s
On Fri, Mar 26, 2010 at 11:57, Brice Goglin wrote:
> Bert Wesarg wrote:
>> There is also a problem, that these __hwloc_attributes defines don't
>> get through after install:
>>
>
> Are you using the embedding stuff ? Or only including our headers ?
>
> There's no guarantee that your external appli
FYI: I don't know if this is hwloc or autotools specific, but there is
no build dependency on
include/hwloc/config.h.in.
Regards,
Bert
I think once we fix up this attribute stuff that Bert raised we should make rc1.
On Mar 25, 2010, at 6:13 PM, Brice Goglin wrote:
> Bert Wesarg wrote:
> > On Mon, Mar 22, 2010 at 21:29, Brice Goglin wrote:
> >
> >> Brice Goglin wrote:
> >>
> >>> Are we doing a 1.0-rc1 soon ?
> >>>
> >>>
Jeff Squyres, le Fri 26 Mar 2010 07:50:34 -0400, a écrit :
> I think once we fix up this attribute stuff that Bert raised we should make
> rc1.
We still haven't decided what to do for printing logical vs physical
numbers in lstopo.
Samuel
Samuel Thibault wrote:
> Jeff Squyres, le Fri 26 Mar 2010 07:50:34 -0400, a écrit :
>
>> I think once we fix up this attribute stuff that Bert raised we should make
>> rc1.
>>
>
> We still haven't decided what to do for printing logical vs physical
> numbers in lstopo.
>
We already pri
Brice Goglin, le Fri 26 Mar 2010 14:19:35 +0100, a écrit :
> Samuel Thibault wrote:
> > Jeff Squyres, le Fri 26 Mar 2010 07:50:34 -0400, a écrit :
> >
> >> I think once we fix up this attribute stuff that Bert raised we should
> >> make rc1.
> >>
> >
> > We still haven't decided what to do
On Mar 26, 2010, at 9:47 AM, Samuel Thibault wrote:
> Maybe for more coherency the latter should be
>
> L1 #0(32KB) + Core #0 + P #0 (phys=0)
I like the space separation -- it might be slightly easier to parse in some
cases (e.g., where you don't have strong regexp support).
How about "Proc"
The output of "lstopo -l" is different than "lstopo -l -v" -- is that
intentional?
This is in RHEL5.4, trunk HEAD (r1851).
-
[7:45] svbu-mpi:~/svn/hwloc % ./utils/lstopo -l
Machine (3945MB)
Socket #0
L2 #0 (2048KB) + L1 #0 (16KB) + Core #0
P #0 (phys=0)
P #1 (phys=4)
L
Bert Wesarg, le Fri 26 Mar 2010 11:09:05 +0100, a écrit :
> AFAIK the correct usage would be:
>
> int square(int __attribute__ ((__unused__)) arg1, int arg2) {
> return arg2; }
>
> I.e. the attribute is between type and name.
Do you have a reference on this? For variables, the gcc manu
Jeff Squyres wrote:
> The output of "lstopo -l" is different than "lstopo -l -v" -- is that
> intentional?
>
Yes. The non-verbose mode groups on the same line all objects that are
identical (e.g. a socket that contains a single L3 cache). In verbose
mode, we separate them on different lines to
Jeff Squyres, le Fri 26 Mar 2010 10:47:15 -0400, a écrit :
> The output of "lstopo -l" is different than "lstopo -l -v" -- is that
> intentional?
Well, yes, it is supposed to display less information :)
Which precise difference are you referring to?
Samuel
> -
> [7:45] svbu-mpi:~/svn/hwloc
Samuel Thibault, le Fri 26 Mar 2010 15:49:36 +0100, a écrit :
> All these don't have any problem with the above.
I mean, with putting the attributes after the variable name.
Samuel
Thanks for the idea.
Bert Wesarg, le Fri 26 Mar 2010 12:33:00 +0100, a écrit :
> +#define HWLOC_HAVE(what) (defined(HWLOC_HAVE_##what) && HWLOC_HAVE_##what)
Unfortunately some compilers (such as gcc 2.95) do not accept this.
Samuel
Bert Wesarg, le Fri 26 Mar 2010 12:43:33 +0100, a écrit :
> FYI: I don't know if this is hwloc or autotools specific, but there is
> no build dependency on
> include/hwloc/config.h.in.
It'd tend to say that it is autotools-specific. For instance, we do not
put anything special for utils/test-hwloc
Does this work with compilers that (pseudo) impersonate gcc (e.g., icc)?
On Mar 26, 2010, at 12:01 PM, wrote:
> Author: sthibaul
> Date: 2010-03-26 12:01:17 EDT (Fri, 26 Mar 2010)
> New Revision: 1853
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/1853
>
> Log:
> Automatically enable some
Jeff Squyres, le Fri 26 Mar 2010 12:51:53 -0400, a écrit :
> Does this work with compilers that (pseudo) impersonate gcc (e.g., icc)?
Yes.
Samuel
On Mar 26, 2010, at 11:33 AM, Samuel Thibault wrote:
> Well, yes, it is supposed to display less information :)
> Which precise difference are you referring to?
The first section of both -- obviously, not the 2nd section of the -v output.
:-)
The first section of both displays roughly the same
Jeff Squyres wrote:
> On Mar 26, 2010, at 11:33 AM, Samuel Thibault wrote:
>
>
>> Well, yes, it is supposed to display less information :)
>> Which precise difference are you referring to?
>>
>
> The first section of both -- obviously, not the 2nd section of the -v output.
> :-)
>
> The f
On Mar 26, 2010, at 1:25 PM, Brice Goglin wrote:
> The reason was that the "phys" attribute is mostly useless for anything
> but Proc and NUMANode.
>
> Current other differences when adding -v are:
> * "Proc" if -v instead of "P"
I like "Proc" instead of "P" even for the non-v output. :-)
> *
Jeff Squyres wrote:
> On Mar 26, 2010, at 1:25 PM, Brice Goglin wrote:
>
>
>> The reason was that the "phys" attribute is mostly useless for anything
>> but Proc and NUMANode.
>>
>> Current other differences when adding -v are:
>> * "Proc" if -v instead of "P"
>>
>
> I like "Proc" instead o
On Fri, Mar 26, 2010 at 15:49, Samuel Thibault wrote:
> Bert Wesarg, le Fri 26 Mar 2010 11:09:05 +0100, a écrit :
>> AFAIK the correct usage would be:
>>
>> int square(int __attribute__ ((__unused__)) arg1, int arg2) {
>> return arg2; }
>>
>> I.e. the attribute is between type and name.
>
On Mar 26, 2010, at 2:01 PM, Brice Goglin wrote:
> > I like "Proc" instead of "P" even for the non-v output. :-)
>
> I am not against it, but I don't remember the reason for the initial
> change. Maybe because "processor" is confusing for some people (logical
> vs physical socket) ?
Oh crap. I
On Fri, Mar 26, 2010 at 17:51, Jeff Squyres wrote:
> Does this work with compilers that (pseudo) impersonate gcc (e.g., icc)?
Wouldn't that be a bug of the impersonater?
Bert
>
> On Mar 26, 2010, at 12:01 PM, wrote:
>
>> Author: sthibaul
>> Date: 2010-03-26 12:01:17 EDT (Fri, 26 Mar 2010)
>> N
On Fri, Mar 26, 2010 at 17:01, Samuel Thibault wrote:
> Thanks for the idea.
>
> Bert Wesarg, le Fri 26 Mar 2010 12:33:00 +0100, a écrit :
>> +#define HWLOC_HAVE(what) (defined(HWLOC_HAVE_##what) && HWLOC_HAVE_##what)
>
> Unfortunately some compilers (such as gcc 2.95) do not accept this
What top
On Mar 26, 2010, at 2:34 PM, Bert Wesarg wrote:
> > Does this work with compilers that (pseudo) impersonate gcc (e.g., icc)?
>
> Wouldn't that be a bug of the impersonater?
Yes, but we really can't change/fix those. There are many such bugs (which is
why I said "(pseudo) impersonate), but we p
Jeff Squyres, le Fri 26 Mar 2010 14:15:50 -0400, a écrit :
> On Mar 26, 2010, at 2:01 PM, Brice Goglin wrote:
>
> > > I like "Proc" instead of "P" even for the non-v output. :-)
> >
> > I am not against it, but I don't remember the reason for the initial
> > change. Maybe because "processor" is
Bert Wesarg, le Fri 26 Mar 2010 19:39:51 +0100, a écrit :
> On Fri, Mar 26, 2010 at 17:01, Samuel Thibault
> wrote:
> > Thanks for the idea.
> >
> > Bert Wesarg, le Fri 26 Mar 2010 12:33:00 +0100, a écrit :
> >> +#define HWLOC_HAVE(what) (defined(HWLOC_HAVE_##what) && HWLOC_HAVE_##what)
> >
> > U
On Mar 26, 2010, at 4:16 PM, Samuel Thibault wrote:
> > Is it a crime to use the full word "Processor"? At least on my machine,
> > the output width is still far less than 80 characters, so the full word
> > should be no problem. But I don't know if there are other strange
> > topologies out
On Fri, Mar 26, 2010 at 22:05, Jeff Squyres wrote:
> On Mar 26, 2010, at 4:16 PM, Samuel Thibault wrote:
>
>> > Is it a crime to use the full word "Processor"? At least on my machine,
>> > the output width is still far less than 80 characters, so the full word
>> > should be no problem. But I
Jeff Squyres, le Fri 26 Mar 2010 17:05:39 -0400, a écrit :
> On Mar 26, 2010, at 4:16 PM, Samuel Thibault wrote:
>
> > > Is it a crime to use the full word "Processor"? At least on my machine,
> > > the output width is still far less than 80 characters, so the full word
> > > should be no probl
On Mar 26, 2010, at 5:09 PM, Bert Wesarg wrote:
> For htop I use just "CPU".
I think that we need to differentiate between the different meanings of "CPU"
here -- CPU could also mean "socket", for example...
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.c
On Mar 26, 2010, at 5:20 PM, Samuel Thibault wrote:
> That's still very large. We are going toward dozens of cores on each
> sockets, we really need to keep them small :)
Fair enough. How about still just keeping "P" in the graphic output, then?
But "processor" in the prettyprint?
--
Jeff Sq
Jeff Squyres wrote:
> On Mar 26, 2010, at 5:20 PM, Samuel Thibault wrote:
>
>
>> That's still very large. We are going toward dozens of cores on each
>> sockets, we really need to keep them small :)
>>
>
> Fair enough. How about still just keeping "P" in the graphic output, then?
> But "
On Mar 26, 2010, at 5:35 PM, Brice Goglin wrote:
> > Fair enough. How about still just keeping "P" in the graphic output, then?
> > But "processor" in the prettyprint?
>
> IIRC, somebody said "PU" (for "processing unit") could be a good
> solution. Otherwise, I am ok with "Proc" or "Processor"
ERROR: Command returned a non-zero exist status (trunk):
make distcheck
Start time: Fri Mar 26 21:01:02 EDT 2010
End time: Fri Mar 26 21:01:48 EDT 2010
===
[... previous lines snipped ...]
Generating docs for file openf
38 matches
Mail list logo
