search for: fopenmp

...... (cached) 4 checking whether we can compute C Make dependencies... yes, using x86_64-alpine-linux-uclibc-gcc -std=gnu99 -MM checking whether x86_64-alpine-linux-uclibc-gcc -std=gnu99 supports -c -o FILE.lo... yes checking for x86_64-alpine-linux-uclibc-gcc -std=gnu99 option to support OpenMP... -fopenmp checking how to get verbose linking output from x86_64-alpine-linux-uclibc-gfortran... -v checking for Fortran 77 libraries of x86_64-alpine-linux-uclibc-gfortran... -L/usr/lib/gcc/x86_64-alpine-linux-uclibc/4.6.3 -L/usr/lib/gcc/x86_64-alpine-linux-uclibc/4.6.3/../../../../x86_64-alpine-linux-ucli...

...ieve that libiomp is not a proper name anymore and > should be changed. I'm not a library expert, so really don't know. > However, this means that we should flip default library setting ASAP. > Why? Because now "libiomp5" is a user-visible name (one has to use > "-fopenmp=libiomp5" to enable OpenMP in clang) and the sooner it will > become non user-visible, the better. Any objections here? Switch the library name together with the default value for clang. That seems like to the way forward. It doesn't break existing users, since they would still be usin...

Hi all, I'm trying to get the llvm's IR from the source code of Polybench (OMP) https://github.com/cavazos-lab/PolyBench-ACC/tree/master/OpenMP. I noticed a considerable difference between the IR generated using clang -emit-llvm -fopenmp and clang -emit-llvm: * using the -fopenmp flag I get a simplified IR in which I read a single basic block where I can highlight a llvm.memcpy function * without -fopenmp flag I get the expected IR in which I find a large number of basic blocks (e.g. for loop --> for.begin, for.end ...)...

Hello, I am getting the following error while trying to build a benchmark with a custom function pass: clang -Xclang -fopenmp=libomp -Xclang -load -Xclang my_lib.so file.c error: unknown argument: '-fopenmp=libomp' If I use this instead: clang -Xclang -fopenmp=libomp -Xclang -load -Xclang my_lib.so file.c I get the error: fatal error: 'omp.h' file not found I am not sure where the problem is, espe...

...y implement generation of >> GNU API calls as well, but this is a separate big task that, IMHO, doesn't >> serve any real purpose -- and potentially introduces nasty GPL-related legal >> issues. >> >> There is an option to choose what library clang links >> (-fopenmp={libiomp|libgomp}), though. >> >>> >>> I totally agree, I think things are way better now. I generally support >>> the direction. I think there are a few things I'd suggest we do as part of >>> the process, but I think these are really small and just ab...

...Inc. build 5490)) worked well. But for the llvm-gcc I get the following error message (during the make): > .... > Making all in vtfilter > llvm-g++ -DHAVE_CONFIG_H -I. -I../.. -I../../extlib/otf/otflib - > I../../extlib/otf/otflib -I../../vtlib/ -I../../vtlib -D_REENTRANT - > fopenmp -DVT_OMP -O2 -MT vtfilter-vt_filter.o -MD -MP -MF .deps/ > vtfilter-vt_filter.Tpo -c -o vtfilter-vt_filter.o `test -f > 'vt_filter.cc' || echo './'`vt_filter.cc > mv -f .deps/vtfilter-vt_filter.Tpo .deps/vtfilter-vt_filter.Po > llvm-g++ -DHAVE_CONFIG_H -I. -I../.. -I....

...two. Then it should be approved by code reviewers, which might take some time. andrey Отправлено с iPad > 12 мая 2015 г., в 21:22, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): > > Andrey, > Any idea when the patch to enable openmp as the default for > -fopenmp will be posted to cfe-commits? > Jack > > On Fri, May 8, 2015 at 4:10 PM, Andrey Bokhanko > <andreybokhanko at gmail.com> wrote: >> No, just changing defaults -- subject to code reviewers approval. >> >> As I said before, I prefer to leave librar...

...C Bergström" <cbergstrom at pathscale.com>, "Michael Wong" >> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com> >> Sent: Thursday, April 30, 2015 8:49:30 AM >> Subject: libiomp, not libgomp as default library linked with -fopenmp >> >> >> 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: >>...

...ere is one issue with the proposed patch at > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150511/129075.html > with regard to finding the installed libiomp5.dylib for linkage. If > the cmake build of llvm/clang/opemmp uses > -DCMAKE_INSTALL_PREFIX=/sw/opt/llvm-3.7, the -fopenmp option fails to > find the libiomp5.dylib installed in /sw/opt/llvm-3.7/lib for > linkage... > > % clang-3.7 -fopenmp -o omp_getEnvInfo omp_getEnvInfo.c -v > clang version 3.7.0 (trunk) > Target: x86_64-apple-darwin14.4.0 > Thread model: posix > "/sw/opt/llvm-3.7.0/bi...

...;d like to give a chance to everyone to raise their objections first. >> >> Yours, >> Andrey >> >>> 8 мая 2015 г., в 18:30, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): >>> >>> Is there a proposed patch yet for switching the -fopenmp support over >>> to the openmp library instead of libgomp? I realize the call to rename >>> the library may be complicating this process. Perhaps the switch of >>> the default library should be done first under the current libiomp5 >>> name and that tested for a...

...*** libs* *g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -I/usr/local/include -fpermissive -I../inst/include -I. -DBOOST_NO_AUTO_PTR -fopenmp -fpic -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c RcppExports.cpp -o RcppExports.o* *g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG -I"/usr/local/lib/R/site-library/Rcpp/include" -g -O2 -fstack-protector-strong -Wformat -Wer...

It will come on next week. I'd like to give a chance to everyone to raise their objections first. Yours, Andrey > 8 мая 2015 г., в 18:30, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): > > Is there a proposed patch yet for switching the -fopenmp support over > to the openmp library instead of libgomp? I realize the call to rename > the library may be complicating this process. Perhaps the switch of > the default library should be done first under the current libiomp5 > name and that tested for a few days first before using foll...

Yes I think I can. The original compile line was: llvm-g++ -DHAVE_CONFIG_H -I. -I../.. -I../../extlib/otf/otflib -I../../ extlib/otf/otflib -I../../vtlib/ -I../../vtlib -D_REENTRANT -fopenmp - DVT_OMP -O2 -MT vtfilter-vt_tracefilter.o -MD -MP -MF .deps/vtfilter- vt_tracefilter.Tpo -c -o vtfilter-vt_tracefilter.o `test -f 'vt_tracefilter.cc' || echo './'`vt_tracefilter.cc I preprocessed the file using the llvm-cpp as follows: llvm-cpp -DHAVE_CONFIG_H -I. -I../.. -I....

Why is this thread still going? Isn't the most pragmatic choice to just make it a build configuration option and be done? Then whoever is actually packaging it can make the most sensible choice for their needs.. Should I send a patch so this bikeshed thread can die?

...td=gnu++11 -I/usr/share/R/include -DNDEBUG > -I"/usr/local/lib/R/site-library/Rcpp/include" -g -O2 > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -g -I/usr/local/include -fpermissive -I../inst/include > -I. -DBOOST_NO_AUTO_PTR -fopenmp -fpic -g -O2 -fstack-protector-strong > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c > RcppExports.cpp -o RcppExports.o* > > *g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG > -I"/usr/local/lib/R/site-library/Rcpp/include" -g -O2 > -fstack-p...

Hi Jack, On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > Hans, > Do we intend to leave -fopenmp defaulted to the no-op libgomp > support for 3.7.0 or do the sensible thing by applying... > > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 242425) > +++ CMakeLists.txt (working copy) > @@ -182,7 +182...

...ors: * Installing *source* package 'pnmath' ... ** libs ** arch - i386 gcc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx- version-min=10.4 -std=gnu99 -I/Library/Frameworks/R.framework/ Resources/include -I/Library/Frameworks/R.framework/Resources/include/ i386 -msse3 -fopenmp -fPIC -g -O2 -march=nocona -c bd0.c -o bd0.o cc1: error: unrecognized command line option "-fopenmp" make: *** [bd0.o] Error 1 ** arch - ppc chmod: /Library/Frameworks/R.framework/Resources/library/pnmath/libs/ i386/*: No such file or directory gcc -arch ppc -isysroot /Developer/SDKs/Ma...

...I calls only -- as simple as that. Someday someone may implement generation of GNU API calls as well, but this is a separate big task that, IMHO, doesn't serve any real purpose -- and potentially introduces nasty GPL-related legal issues. There is an option to choose what library clang links (-fopenmp={libiomp|libgomp}), though. > I totally agree, I think things are way better now. I generally support > the direction. I think there are a few things I'd suggest we do as part of > the process, but I think these are really small and just about "how" we > switch. > &gt...

On 30 April 2015 at 10:06, Hal Finkel <hfinkel at anl.gov> wrote: >> >> 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...

...015 at 6:52 AM Andrey Bokhanko < >>> andreybokhanko at gmail.com> wrote: >>> >>>> All, >>>> >>>> I'd like to resurrect the discussion on replacing libgomp with libiomp >>>> as the default OpenMP runtime library linked with -fopenmp. >>>> >>> >>> Just for the record, I'm really excited to see this. =] >>> >>> >>>> We are very close to getting *full* OpenMP 3.1 specification supported >>>> in clang (only one (!) clause is not implemented yet, and the pa...