Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] last API possible changes
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-09-21 12:31:41


On Sep 21, 2009, at 10:42 AM, Samuel Thibault wrote:

> It's part of the language starting from C99 only. An application could
> enable non-C99 mode where it becomes undefined, you can never know.
>

That is a decade old, no? ;-)

> > Alternatively, this whole block in cpuset-bits.h could be wrapped in
> > an "#ifndef restrict", right?:
>
> That will work only if libraries possibly defining restrict and
> included
> after hwloc do the same. You may argue that then it's their matter.
> The only library I see defining restrict in my /usr/include does it
> without #ifndef restrict, I'm not sure we want to fight this.
>

Ok, fair enough.

(Sorry -- I wasn't trying to be a jerk; just trying to be thorough...)

> You may not be able to resolve the difference: depending on the kind
> of
> detection of the compiler etc. etc. you may end up with restrict
> defined
> to __restrict or to something else. And as soon as one improves its
> detection of the compiler, the other(s!) will have to harmonize, etc.
> Not really sustainable.
>

Also fair enough. Is it possible that our use of restrict in cpuset-
bits.h could come to a conclusion that is different than the
underlying compiler (e.g., the underlying compiler needs __restrict)?
I'm somewhat dubious of that this could happen, though -- don't all
modern compilers support "restrict"? (I have not looked into this
recently myself; all that data has been swapped out of my brain...)

Alternatively, is the restrict optimization really worth it here? If
there are potential incompatibilities, perhaps the easiest answer is
just to remove its use...?

-- 
Jeff Squyres
jsquyres_at_[hidden]