search for: libllomp

...t; sense, awesome. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > Just some bikeshed-painting: if we're expecting each compiler that uses the library to distribute a separate copy as part of that compiler's runtime, t...

...it is running on IBM Power or ARM processors. The people who know about that should contribute… - I suspect we should change the name of the installed library. 'libiomp' is pretty clearly the Intel library. We could continue in the grand tradition of LLVM naming conventions and use 'libllomp'? Of course, we should install symlinks under the name 'libiomp' if needed for existing users to not be broken. Changing the file name (at least when targeting X86 processors) is a more interesting issue, and not as trivial as it seems. The problem here is related to inter-operation...

...t; sense, awesome. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > - Any other changes? > > Is this naming issue so serious that it will be blocker for the current patches to enabled the openmp build from within llvm/proj...

...uple of minutes. > - Clearly updating the readme and such would be appropriate. > - I suspect we should change the name of the installed library. 'libiomp' > is pretty clearly the Intel library. We could continue in the grand > tradition of LLVM naming conventions and use 'libllomp'? Of course, we > should install symlinks under the name 'libiomp' if needed for existing > users to not be broken. > - Any other changes? > Adding openmp-dev list (in retrospect, should have been done at the very start...), Jim Cownie and Andrey Churbanov. > 2) I thin...

...- Clearly updating the readme and such would be appropriate. >>> - I suspect we should change the name of the installed library. >>> 'libiomp' is pretty clearly the Intel library. We could continue in the >>> grand tradition of LLVM naming conventions and use 'libllomp'? Of course, >>> we should install symlinks under the name 'libiomp' if needed for existing >>> users to not be broken. >>> - Any other changes? >>> >>> >> Is this naming issue so serious that it will be blocker for the current >>...

All, I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp. For reference, the previous discussion is accessible there: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461 We are very close to getting *full* OpenMP 3.1 specification supported in clang (only one (!) clause is not

...- Clearly updating the readme and such would be appropriate. >>> - I suspect we should change the name of the installed library. 'libiomp' >>> is pretty clearly the Intel library. We could continue in the grand >>> tradition of LLVM naming conventions and use 'libllomp'? Of course, we >>> should install symlinks under the name 'libiomp' if needed for existing >>> users to not be broken. >>> - Any other changes? >> >> >> Adding openmp-dev list (in retrospect, should have been done at the very >> start....