[Openmp-commits] [PATCH] LLVM OpenMP CMake Overhaul

[cbergstrom at pathscale.com]

An end user would almost certainly never do this. It would be provided with their Fortran compiler. It's like saying a c++ user has to build his own STL.

  Original Message  
From: Chandler Carruth
Sent: Friday, June 26, 2015 16:04
To: jonathan.l.peyton at intel.com
Reply To: reviews+D10656+public+dda1fdcafb4c32bf at reviews.llvm.org
Cc: james.h.cownie at intel.com; emaste at freebsd.org; howarth.mailing.lists at apple.com; cbergstrom at pathscale.com; openmp-commits at dcs-maillist2.engr.illinois.edu; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] LLVM OpenMP CMake Overhaul

In http://reviews.llvm.org/D10656#195299, @jcownie wrote:

> Chandler, the issue here is with providing a Fortran module that contains the OpenMP interfaces. Unfortunately, Fortran module files are a binary format file which has no standard specification. therefore to produce a module file for a specific compiler you have to compile the module with that compiler. 
> The OpenMP standard wants it to be possible for Fortran users to "use omp_lib", that requires that an appropriate Fortran module file exists.
>
> So, the issue is not with the Fortran interface to C functions (the implementation of the Fortran module can use those interfaces if it wants to), but with the fact that Fortran compilers store modules in compiler dependent binary formats. Therefore you need the appropriate Fortran compiler to build the module file.
>
> If a distributor is building the runtime they need to either build the module file on the user's machine at install time (when they can see which Fortran compilers the user has to hand), to maintain a (small) Fortran compiler zoo to build appropriate modules, or explain to the user how to build the module when they install (almost the same as my first solution, but less automatic).


Wow, thanks for the detailed explanation. I had no idea. =]

So, it seems like this is only of minimal utility to even have in the CMake build, and sadly it brings a reasonable amount of complexity. Is there a reasonable way to separate it (and maybe to make it a script or something that users can easily run to, as you say, build the module for a particular install? Maybe that's the right balance between automatic and usable in different scenarios?

I'm not sure at all, this is a nasty problem relative to the "normal" problems in our runtime libraries.


REPOSITORY
rL LLVM

http://reviews.llvm.org/D10656

EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/