similar to: [LLVMdev] Linking with OpenMP support

Hi; Both -fplugin-arg-dragonegg-emit-ir and -flto works for creating llvm bitcode that can be run with lli. Thanks to Nick for the suggestion. Now, trying to run an OpenMP hello world program. llvm-gcc -fopenmp p_hello.c -flto -S -o p_hello.ll lli p_hello.ll output: LLVM ERROR: Program used external function 'GOMP_parallel_start' which could not be resolved! I am guessing that I have

Hello! Currently, when a program built without OpenMP (-fopenmp) is trying to dlopen a library, built with the feature, the result is a crash from "bad system call": #0 0x00000008009a223c in ksem_init () from /lib/libc.so.7 #1 0x0000000800998a8f in sem_init () from /lib/libc.so.7 #2 0x00000008011a6537 in omp_get_nested () from /usr/lib/libgomp.so.1 #3

On Mon, 2012-01-16 at 17:14 +0100, Tobias Grosser wrote: > On 01/16/2012 03:04 AM, Vlad Krylov wrote: > > I am interested. I would be grateful for your hints. > > Great. ;-) > > > So OpenMP has various constructs such as parallel, barrier, single, > > for, etc. And there is at least two libraries to generate OpenMP code: > > libgomp and mpc. We want to be

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

Hi, In the beginning I'd like to say I am not very familiar with (llvm-)gcc internals, so some of my assumptions and guesses may be wrong. Please, correct me, then. Anton Korobeynikov wrote: > Internally OpenMP lowering in gcc is split into two phases. Funny, but > llvm converter is run between these phases :) It looks like second phase > uses some gcc analysis passes (like

The PTX back-end is robust (it's based on the sources used by nvcc), but I'm not sure about the OpenMP representation in LLVM IR. I believe the OpenMP constructs are already lowered into libgomp calls before leaving DragonEgg. It's been awhile since I've loooked at it though. If you use the PTX back-end and have any issues, please don't hesitate to post to the list and cc:

On 01/16/2012 03:04 AM, Vlad Krylov wrote: > I am interested. I would be grateful for your hints. Great. ;-) > So OpenMP has various constructs such as parallel, barrier, single, > for, etc. And there is at least two libraries to generate OpenMP code: > libgomp and mpc. We want to be independent of specific library. True. > We should create an interface with methods which

No, just changing defaults -- subject to code reviewers approval. As I said before, I prefer to leave library naming to library pros. Andrey On Fri, May 8, 2015 at 7:21 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > So you plan on switching and enabling the openmp library defaults as > well as changing the openmp library name at the same time? > Jack >

> Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal > to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup > as an LLVM subproject is sustainable going forward without some form of testing support, automated > or otherwise. > The motivation: It's difficult to make changes to the

Hi all, I'd like to put in some effort into this too -- perhaps I can write an backend for libgomp while someone else works on a libmpc one. As far as the architecture is concerned, I concur with what has already been discussed: mapping OpenMP constructs to LLVM intrinsics. I think it would make sense to leave out intrinsics for things like "parallel for", "parallel

I was modifying a source to add OpenMP capabilities. I knew that gcc supports OpenMP since version 4.2, so I've compiled a recent (4.3.2) gcc and installed in my home directory, this because gcc shipped with CentOS 5.2 is 4.1. I've then noticed that my executable links /usr/lib64/libgomp.so, installed with gcc 4.1 from CentOS rpms... Is CentOS default compiler OpenMP ready? Does

Hi Bill, This is probably due to the llvm-gcc merge. Please take a look. Thanks, Evan On Jul 30, 2008, at 10:04 AM, Duncan Sands wrote: > x86-64 linux, during stage3: > > xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/ > gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/ > x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-

x86-64 linux, during stage3: xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects/./gcc/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/bin/ -B/usr/local/gnat-llvm/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/include -isystem /usr/local/gnat-llvm/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2.llvm/libgomp -I.

On Jul 30, 2008, at 11:17 AM, Julien Lerouge wrote: > Not sure if that's related, but we had two failures last night as > well: > > MacOS/Universal build failed on rev 54197, when building the x86->ppc > cross: > > cc1: warnings being treated as errors > /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: > no > previous prototype for

Not sure if that's related, but we had two failures last night as well: MacOS/Universal build failed on rev 54197, when building the x86->ppc cross: cc1: warnings being treated as errors /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: no previous prototype for 'outermost_tinst_level' make[2]: *** [cp/pt.o] Error 1 MingW failed on rev 54208:

Jack, Alexey [Bataev] promised to send it for review in a day or 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

Hi, Sorry for breakage, I'll look into this right now. I guess llvm-gcc doesn't use llvm tablegen results to help create intrinsic names. -- Mon Ping On Jul 30, 2008, at 1:51 PM, Duncan Sands wrote: > Hi, I see this when building llvm-gcc on x86-32 linux: > > xgcc -Bgcc/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/bin/ -B/usr/ > local/gnat-llvm/i686-pc-linux-gnu/lib/

Hi, > if /bin/sh ./libtool --mode=compile /s/llvm/obj.gcc42/./gcc/xgcc -B/s/llvm/obj.gcc42/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/s/llvm/svn.gcc42/libgomp -I. -I/s/llvm/svn.gcc42/libgomp/config/linux/x86

On Jul 30, 2008, at 2:03 PMPDT, Mon P Wang wrote: > Hi, > > Sorry for breakage, I'll look into this right now. I guess llvm-gcc > doesn't use llvm tablegen results to help create intrinsic names. > > -- Mon Ping It calls Intrinsic::getDeclaration. > On Jul 30, 2008, at 1:51 PM, Duncan Sands wrote: > >> Hi, I see this when building llvm-gcc on x86-32

Hi, I see this when building llvm-gcc on x86-32 linux: xgcc -Bgcc/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/bin/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/lib/ -isystem /usr/local/gnat-llvm/i686-pc-linux-gnu/include -isystem /usr/local/gnat-llvm/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.2.llvm/libgomp -I. -I../../../gcc-4.2.llvm/libgomp/config/linux/x86