Now this thread is starting to read like an episode of The Big Bang Theory.
One possible guess as to how/why MPICH has managed w/o "volatile" would
be that they may pass less aggressive optimization flags to the
compilers. It is a then a question of which MPI implementation is
supporting a cho
On Nov 8, 2011, at 18:32 , Ralph Castain wrote:
> That was the experience - after thrashing for quite some time, we finally
> found that the volatile qualifiers fixed the problem. Hence my request that
> people check to see if anything is broken.
I will therefore propose to forever ban all com
On Nov 8, 2011, at 3:56 PM, Paul H. Hargrove wrote:
> In theory, might a sufficiently smart compiler and linker eliminate some
> MPIR_* variables after optimization? If that could potentially be true, then
> perhaps the volatile qualifier would prevent such a removal, which would
> break the
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 librar
In theory, might a sufficiently smart compiler and linker eliminate some
MPIR_* variables after optimization? 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.
-Paul
I guess people should check the commit before …
No way the volatile will do any good here:
-ORTE_DECLSPEC extern volatile char MPIR_executable_path[MPIR_MAX_PATH_LENGTH];
-ORTE_DECLSPEC extern volatile char MPIR_server_arguments[MPIR_MAX_ARG_LENGTH];
+ORTE_DECLSPEC extern char MPIR_executable_path
I think the volatiles are there to ensure the compiler doesn't optimise away
reads or function calls which has been a problem with this interface in the
past.
On 8 Nov 2011, at 22:18, George Bosilca wrote:
> MPIR_Breakpoint, as the name indicates, it is just a breakpoint used by the
> startup
MPIR_Breakpoint, as the name indicates, it is just a breakpoint used by the
startup process or the MPI application to signal changes to the debugger. No
return value, nothing more than a breakpoint.
I wonder how the volatile got there, there is no such requirement on variables
that cannot be ch
I think the only possible controversial change in this commit is changing
MPIR_Breakpoint() to return (void) instead of (void*). Oddly, I see that
MPICH2 has 2 different prototypes for MPIR_Breakpoint -- one returns (void*),
another returns (int). Assuming that MPICH2 works fine with the debug
