openmp v19.1.0

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• Dependencies have been updated if changed: see upstream
• Tests have passed
• Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name	Upstream Version	Current Version
compiler-rt	19.1.0
llvmdev	19.1.0

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by - please use this URL for debugging.}

[h-vetinari]

Windows builds here will need flang 19 to be built (exceptionally, as we're adding the fortran bits now, c.f. #134; for LLVM 20+ we shouldn't need the newest flang to build openmp)

[h-vetinari]

@conda-forge/openmp, aside from waiting for the flang builds on windows, this is ready, PTAL! :)

[h-vetinari]

@conda-forge/openmp, this is ready now, PTAL! :)

[h-vetinari]

Kind ping @conda-forge/openmp, PTAL.

[h-vetinari]

Ping @conda-forge/openmp. Given that #134 (for the meat of the change here) received no comments in >2 months, I'm going to merge this in roughly 24h, unless there are other comments.

[isuruf]

Commented at #134 (comment)

[h-vetinari]

Commented at #134 (comment)

Thanks. I'm answering here because based on the comments I don't think we want to backport this feature to 18.x

@isuruf: Can we move the .mod file to a different output? The cycles are also there in linux if we switch _openmp_mutex.

I can try - currently assuming this can be done in a separate output here. How would you like to name this output? openmp-fortran?

[isuruf]

llvm-openmp-fortran? Also I'm not sure how this omp_lib.mod is going to be used with gfortran in Linux given that gfortran has it's own omp_lib.mod for libgomp.

[h-vetinari]

llvm-openmp-fortran? Also I'm not sure how this omp_lib.mod is going to be used with gfortran in Linux given that gfortran has it's own omp_lib.mod for libgomp.

Should we move GCC's omp_lib.mod into libgomp or create a similar libgomp-fortran output that's under the same mutex as the current openmp implementations?

Edit: had some leftover text in my phone's editor, sorry

[h-vetinari]

Should we move GCC's omp_lib.mod into libgomp or create a similar libgomp-fortran output that's under the same mutex as the current openmp implementations?

Ping @isuruf

[isuruf]

Should we move GCC's omp_lib.mod into libgomp or create a similar libgomp-fortran output that's under the same mutex as the current openmp implementations?

Can you give an example of how omp_lib.mod here is going to be used with gfortran?

[h-vetinari]

Should we move GCC's omp_lib.mod into libgomp or create a similar libgomp-fortran output that's under the same mutex as the current openmp implementations?

Can you give an example of how omp_lib.mod here is going to be used with gfortran?

Building openblas with openmp support (conda-forge/openblas-feedstock#115) failed without the omp_lib.mod files. Presumably the ones for gfortran already get picked up from libgomp

[isuruf]

Can you be more specific? The PR is green

[h-vetinari]

Can you be more specific? The PR is green

That PR doesn't build the llvm variant for openmp on linux. But it's green on windows because of the changes in this PR (as present in the dev/rc builds). I'm happy to descope the Fortran bits on Unix, but we need them on windows.

[isuruf]

Okay, then. Please remove the Unix parts.

[h-vetinari]

Okay, then. Please remove the Unix parts.

OK, sounds good. Do we still need to have the separation into separate outputs then?

[isuruf]

Do we still need to have the separation into separate outputs then?

Yep, to avoid having to do that in the future if/when unix builds get added.

[h-vetinari]

do that in the future if/when unix builds get added.

Could we defer the separate output until such time when unix builds get added, or at least after the 19.1.0 release (I'd be willing to open a PR)?

[isuruf]

Can we drop the .mod files all ogether, get the 19 release out and deal with it later?

[h-vetinari]

Can we drop the .mod files all ogether, get the 19 release out and deal with it later?

OK. The flang migration on windows still needs them, but that's yet another separate milestone before the mod files ever become relevant on unix.

[h-vetinari]

As this is now a vanilla version update (and we discussed "get the 19 release out" without the .mod files), I'm merging this. I'll bring back the changes in an updated #134