similar to: OpenMP Error in Clang

Hello, I am building the SPEC 2006 Benchmark with Clang as the compiler. I have written a function pass in LLVM and I am trying to run that for SPEC by invoking the pass in the build options of SPEC. The build options of SPEC are in a *.cfg config file, which allows us to specify the choice of compiler while building SPEC. (https://www.spec.org/cpu2006/Docs/install-guide-unix.html) The pass

Hi, I am using LLVM 3.6.1 to test the following code: #include <omp.h> #include <stdio.h> #include <stdlib.h> int main() { int tid, nthreads; #pragma omp parallel sections private(nthreads, tid) { #pragma omp section { tid = omp_get_thread_num(); printf("Hello, tid = %d\n ", tid); } #pragma omp section { tid = omp_get_thread_num();

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)

Jack, Could you, please, submit a bug report? -- including steps to reproduce (where you got imageMagick sources, how exactly you compiled them, etc) Andrey On Fri, May 1, 2015 at 3:56 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > > On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: >> >> Chandler,

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

Seems on OpenSUSE x86, it's called i586, not i686 :-( +Alexey: do you think we can handle this in the compiler-rt cmake files somehow? Maybe try targeting both i686 and i586 unless that would break something else? On Fri, Jul 17, 2015 at 1:31 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): > Cannot

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 >

Building phase 2 fails on i686 Fedora 22 CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): Cannot compile for i686: CMakeError.log attached On Wed, Jul 22, 2015 at 8:20 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > The problem is we "guess" that the host architecture is i686, and fail > when we find out that we can't target it (__i686__

On Mar 22, 2012, at 12:28 AM, Bill Wendling wrote: > On Mar 20, 2012, at 7:38 PM, Paul J. Lucas wrote: > >> I've read the docs on LLVM exceptions, but I don't see any examples. A little help? > > I don't think this has anything to do with LLVM's IR-level exception system. It sounds to me like you just need a way to handle C++ exceptions inside of the C++ code

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

On 06/05/2018 10:47 AM, Dimitry Andric wrote: > On 4 Jun 2018, at 18:01, Tom Stellard via Release-testers <release-testers at lists.llvm.org> wrote: >> >> The 6.0.1-rc2 release has been tagged. Testers may begin testing and >> reporting results. > > Built for FreeBSD 10, tested and uploaded: > > SHA256 (clang+llvm-6.0.1-rc2-amd64-unknown-freebsd10.tar.xz)

Chandler, Thanks for the reply -- I always included you in libiomp supporters camp; it is good to see I wasn't mistaken! ;-) On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at google.com> wrote: > Is there no way to support libgomp here as well? I don't say this to hold > up changing the defaults in any way, just curious. =] > No, sorry. libgomp doesn't

Dear all, I'm trying to get openmp to work with llvm, either with static compiler or with jit, however with no success. I've followed this: http://blog.llvm.org/2015/05/openmp-support_22.html [http://llvm.org/img/DragonSmall.png]<http://blog.llvm.org/2015/05/openmp-support_22.html> LLVM Project Blog: OpenMP Support OpenMP support in Clang compiler is completed! Every pragma and

Hi I''m building a small library to use in my Rails app which interacts with a 3rd party API. It fetches artists and tracks. So I have: lib/my_lib.rb lib/my_lib/artist.rb lib/my_lib/track.rb To get an artist I do artist = MyLib::Artist.find("Oasis") Which returns an instance of Artist if it finds (via 3rd party API) it or nil otherwise. Then I can call artist.tracks which

Hi lists, I am encountering a large number of check-clang failures after building Clang/LLVM with -DLLVM_USE_SANITIZER=Address. I have reported the issue on Bugzilla (https://bugs.llvm.org/show_bug.cgi?id=47678). I cannot even compile helloworld.c with the resulting clang tool without a lot of false positives from ASan. Is it because I am not supposed to use GCC's AddressSanitizer when

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

Jack, this is not a problem of this patch, this a problem of your configuration. This patch uses standard clang machinery for locating libiomp5 library. Best regards, Alexey Bataev ============= Software Engineer Intel Compiler Team 13.05.2015 15:59, Jack Howarth пишет: > On Tue, May 12, 2015 at 3:58 PM, <andreybokhanko at gmail.com> wrote: >> Jack, >> >> Alexey

Wouldn’t it it be possible to add a flag like the one used in the OpenMP subproject? There they default to linking to the non-functional libgomp (as far as I understand it), and if people want to use the actual libomp runtime, they have to specify -fopenmp=libomp when compiling/linking a program. At the same time, it is possible to use the libomp runtime library by default by specifying

On 28 July 2015 at 14:44, Martell Malone <martellmalone at gmail.com> wrote: > Adding a little to the topic what criteria would we need to make a target > use compiler-rt and libc++ as the default in the clang driver. > I have successfully built a standalone clang toolchain with mingw-w64 > without using gcc or binutils. There was another discussion with David Chisnall, where he

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