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: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2009-09-21 13:33:11


Jeff Squyres, le Mon 21 Sep 2009 12:31:41 -0400, a écrit :
> 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? ;-)

Yes, but existing software tends to still not evolve. I'm still seeing
software using the old termio interface while it dates at least back
1988.

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

No problem. Actually, I had followed your reasoning at the time I wrote
that part of the code, I'm just repeating what I've thought in my head
at the time :)

> 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 not sure to understand what you mean. What could happen
is that gcc stops understanding __restrict while it has been
understanding it since 2.95; I doubt that will ever happen. Another
very low-probability possibility to get something wrong is if a
compiler defines __STDC_VERSION__ to a value greater than 199901L but
doesn't accept restrict; that would really be a compiler bug. The
last possibility is restrict being #defined to something not being the
standard restrict qualifier. I've just dropped the #if defined restrict
part to avoid it, that's not a big loss.

> Alternatively, is the restrict optimization really worth it here?

Re-reading what we use it for at the moment, there is not many
optimizations to be done, but now that I've removed the only case that
could be problematic, it shouldn't be a problem.

Samuel