similar to: [LLVMdev] OpenMP - C source files which are really c++

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 source without some

Yeah, I remember encountering that error before when getting it to pass the libomp test suite. If you have a struct named "ident_t" somewhere the compiler will rename it because of the conflict with the runtime declaration. This should be solved by casting the usage to the function type found in the definition (i.e. bitcasting a struct.ident_t.21 to struct.ident_t) which solved the

Yep, it happens three times, then crashes afterwards, since I removed the assert... arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @0 = private unnamed_addr global %struct.ident_t.21 { i32 0, i32 514, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* @.str, i32 0, i32 0) }, align 8 arg 0: expected %struct.ident_t* got %struct.ident_t.21* value @1 = private

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: >>

On 26/02/2014 09:03, David Chisnall wrote: > On 25 Feb 2014, at 23:13, Alp Toker <alp at nuanti.com> wrote: > >> 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

Hello everybody! To continue the original (http://article.gmane.org/gmane.comp.compilers.llvm.devel/75674) discussion of offload infrastructure I have an updated document with more details for your attention. The document is a consensus of the contributors representing a number of institutions: ANL, AMD, IBM, Intel and Texas Instruments. Our intent is to have a discussion and an approval from

Hi Sergey, Thanks for putting the new version of the document together! I don't see any other issues. I strongly believe the approach described in the document is a nice way to get OpenMP offloading support in clang. I plan to start actively contributing code for this component of the OpenMP implementation soon. Thanks again, Samuel 2015-04-29 11:47 GMT-04:00 Sergey Ostanevich

The new cmake 3.7.0-rc1 release produces a stage2 bootstrap failure in openmp project build on OS X 10.11 under Xcode 8.... In file included from /sw/src/fink.build/llvm40-4.0.0-1/llvm-4.0.0.src/projects/openmp/runtime/src/kmp_alloc.c:16: In file included from /sw/src/fink.build/llvm40-4.0.0-1/llvm-4.0.0.src/projects/openmp/runtime/src/kmp.h:98:

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

----- Original Message ----- > From: "Simone Atzeni" <simone.at at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, cfe-dev at cs.uiuc.edu, openmp-dev at dcs-maillist2.engr.illinois.edu > Sent: Tuesday, October 21, 2014 3:52:38 PM > Subject: Re: [LLVMdev] [cfe-dev][Openmp-dev] Provide LLVM IR and OpenMP LLVM IR as input

On Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> wrote: > Congratulations! Would you like to add a blurb to the release notes > for the next release? Sure! Will do. Yours, Andrey

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

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 >

We have noticed that although we have active development in the OpenMP runtime, there is no formal code-owner. I would therefore like to nominate Andrey Churbanov who is a major committer and has deep experience with the runtime code since before it was the LLVM runtime. -- Jim James Cownie <james.h.cownie at intel.com> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes) Tel: +44

Hearing no opinions to the contrary, let's say Banger's 6pm (tomorrow). Address and web site below. I submitted online for a reservation early this morning, and I'll try to get an updated head count on Sunday morning. -Hal Sent from my Verizon Wireless 4G LTE DROID On Nov 14, 2015 11:21 AM, Chandler Carruth <chandlerc at google.com> wrote: Did this ever get settled? On Fri,

> I'd support some of Jame's comments if liboffload wasn't glued to OMP as it is now. I certainly have no objection to moving liboffload elsewhere if that makes it more useful to people. There is no real "glue" holding it there; it simply ended up in the OpenMP directory structure because that was an easy place to put it, not because that's the optimal place for it.

----- Original Message ----- > From: "Sebastian Pop" <spop at codeaurora.org> > To: "James H Cownie" <james.h.cownie at intel.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "John Leidel (jleidel)" <jleidel at micron.com>, "LLVM Dev" > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at

CALL FOR PAPERS ================================================================= LLVM-HPC: The LLVM Compiler Infrastructure in HPC http://llvm-hpc-workshop.github.io/ November 17th, 2014, New Orleans In conjunction with the 2014 ACM/IEEE Supercomputing Conference (SC'14)

I think it would be great if StreamExecutor could use liboffload to perform its offloading under the hood. Right now offloading is handled in StreamExecutor using platform plugins, so I think it could be very natural for us to write a plugin which basically forwards to liboffload. If that worked out, we could delete our current plugins and depend only on those based on liboffload, and then all the

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