KMP_GOMP_COMPAT now required?

Hello,

I've noticed that KMP_GOMP_COMPAT is now required? Is this the intended behavior?

Specifically, because of this in kmp_ftn_entry.h:

/*
* For compatibility with the Gnu/MS Open MP codegen, omp_set_num_threads(),
* omp_set_nested(), and omp_set_dynamic() [in lowercase on MS, and w/o
* a trailing underscore on Linux* OS] take call by value integer arguments.
* + omp_set_max_active_levels()
* + omp_set_schedule()

KMP_GOMP_COMPAT has always been required. That is the intent.
If KMP_GOMP_COMPAT is not being set automatically by the build system then that has got broken somewhere. (Maybe one of Alp's recent changes broke this unintentionally?)

-- Jim

James Cownie <james.h.cownie@intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

Curious, wouldn't it make more sense to default to sensible behavior
and require macro definitions for the exceptional cases? In what
circumstances would you not want KMP_GOMP_COMPAT set?

wouldn't it make more sense to default to sensible behavior and require macro definitions for the exceptional cases?

Probably now. It didn’t when the libgomp compatibility was new and in the process of being introduced and was,
therefore, the exceptional case.
As time goes on it has become the normal case, but since everything works just fine, no-one ever has a reason
to go back and change something that works.

-- Jim

James Cownie <james.h.cownie@intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

I think that the build system is okay, I was just experimenting, trying to understand what the various preprocessor macros do.

Thanks again,
Hal

Sent from my Verizon Wireless 4G LTE DROID

I think that the build system is okay.

OK. Glad to hear it!

If you felt like crystallizing your new found knowledge into a section in the manual, that would be useful.

The manual is generated using doxygen, so it shouldn’t be anything odd…