This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Nov 8, 2011, at 17:56 , Paul H. Hargrove wrote:
> In theory, might a sufficiently smart compiler and linker eliminate some MPIR_* variables after optimization?
Even if a compiler can optimize out symbols from an application, I doubt they are allowed to apply the same optimization on libraries. As our MPIR_ symbols are defined as externally visible in libopen-rte.so (and some in libmpi.so), so I guess we're safe.
However, this might be an issue when we compile statically
It is not an absolute proof, but I quickly checked with a static build and the MPIR_* symbols are still there with both gcc and icc.
> If that could potentially be true, then perhaps the volatile qualifier would prevent such a removal, which would break the existence check(s) by the debugger? Just a thought.
If we really want to have a clear answer to this, I guess we should ask a hard-core compiler guru about
> On 11/8/2011 2:46 PM, George Bosilca wrote:
>> This value is not even read by the debugger. It only check for it's existence in the startup process, so I guess we're safe here as well.
> 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
> devel mailing list