Parameter with a single value

[E]

As asked by George Bosilca, I create an issue for this specific problem. Here's the link to the topic : https://groups.google.com/a/icl.utk.edu/forum/#!topic/dplasma-users/RtFeeHryipQ

[George Bosilca]

Merged in herault/parsec/issue-153 (pull request #156)

Addresses Issue #153 (and typo in key generation function)

• Typo in key generation function

• Compute __start, __end, __min and __max even if a parameter is not a range, to allow definition of function class parameters that are of range 1, without forcing the user to define it as V .. V

• Need to increment nesting as this is a parameter and the remote dep allocation must happen inside

Approved-by: Thomas Herault [e-mail] Approved-by: George Bosilca [e-mail]

→ <<cset 1c9e435962d4>>

[George Bosilca]

A fix is now available on the master branch. It fixes all problems on Linux, but some lingering issues persist on OS X.

[George Bosilca]

pull request #157 is an optimization for this particular case.

[George Bosilca]

Resolved with the merge of pull request #157.

[George Bosilca]

Long story short: fix issue #153

Long story long: - dague_options.h was not including any compiler / machine-specific #ifdef after it was installed. This is a desirable goal, however... - the consequence was that for lifo.h, the access to parsec_lifo_pop was not following the same implementation if included from an external code than the implementation used inside the parsec source. - If 128 bit atomics was detected to be used, then the lifo.h used internally was using 128 bit atomics (and logic) to update the file, but since the external version was not using them, two pitfalls could happen: - A) the fields could not be 128 bit aligned, and offset of fields could be inconsistent between external and internal codes - B) the fields update logic was broken, but triggering a deadlock/ segfault/wrong computation only rarely.

The current code introduces a new step in the CMake process:

• CMake does the machine-specific logic.
• It creates the parsec_config.h / parsec_options.h files.
• It then compiles and run a test program that exposes (to CMake) what options are on (e.g. if CMake didn't know because that logic was in the .h files, and not in the CMake files, like for 128 Bits atomic logic).
• Using that feedback information, CMake re-generates parsec_options.h to expose what we really need (128 CAS in that case).

This idea should be complemented by a test program that checks the size and alignment of all exposed structures when compiling an external program. An issue will be created to follow that step up.

→ <<cset 090ed801db38>>

[George Bosilca]

Merged in herault/parsec/issue-153-fix (pull request #169)

Long story short: fix issue #153

Approved-by: Thomas Herault [e-mail] Approved-by: George Bosilca [e-mail]

→ <<cset 43543fadef4e>>