similar to: [LLVMdev] Duplicating routine/class name in documentation comment.

Hi Eli, Attached zipped file, named, "fopenmp_option_support.tar.gz" contains the first patch, along with relevant *test case*. This patch is to support the option "-fopenmp" option in Clang. Following files are changed in this patch. Please start going through this patch, and let me know comments. Meanwhile, I will prepare next patch.

On Sat, Oct 13, 2012 at 2:33 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > On Sat, Oct 13, 2012 at 1:31 PM, Tobias Grosser <tobias at grosser.es> wrote: >> On 10/13/2012 04:38 AM, Mahesha HS wrote: >>> >>> On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> >>> wrote: >>>> >>>> On Wed, Oct 10,

I'm seeing this too. CC'ing the author ubsan stuff. Richard, I know you were OK with only supporting Clang-bootstraps, but I don't think that's terribly viable here. We should be able to build ubsan's runtime with standards conforming code unless there is some fairly extreme reason not to... On Fri, Oct 12, 2012 at 7:19 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote:

On Sat, Oct 13, 2012 at 1:31 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 10/13/2012 04:38 AM, Mahesha HS wrote: >> >> On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> >> wrote: >>> >>> On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> >>> wrote: >>>>

On 10/13/2012 04:38 AM, Mahesha HS wrote: > On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: >>> Hi Eli and Others >>> >>> In response to your feedback, I have taken care of all your review comments >>> - I removed clangOMP.a

I use latest cmake+ninja which are built from latest sources. ================================= > cmake --version cmake version 2.8.9.20121011-g2876 ================================= -- mahesha On Fri, Oct 12, 2012 at 7:35 PM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > Hi All, > > I am first time trying build CLANG+LLVM using cmake+ninja build > system. I updated all

Hi All, I am first time trying build CLANG+LLVM using cmake+ninja build system. I updated all my CLANG+LLVM sources to current trunk, and I successfully built it using classic *make* build system. But, trying to build the same with cmake+ninja build system resulting in following build failures for compiler-rt sources. Am I missing something basics here? ==================== cmake command used:

On Fri, Oct 12, 2012 at 6:14 PM, Chandler Carruth <chandlerc at google.com> wrote: > I'm seeing this too. CC'ing the author ubsan stuff. > > Richard, I know you were OK with only supporting Clang-bootstraps, but I > don't think that's terribly viable here. Just out of curiosity - why isn't that viable? I'd sort of hope to treat optional sanitizer runtimes

On Sat, Oct 13, 2012 at 1:09 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 12, 2012 at 6:14 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > I'm seeing this too. CC'ing the author ubsan stuff. > > > > Richard, I know you were OK with only supporting Clang-bootstraps, but I > > don't think that's terribly viable

On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > Hi Eli and Others > > In response to your feedback, I have taken care of all your review comments > - I removed clangOMP.a > and moved the implementation of "class OmpPragmaHandler" to "clangLex.a". > > The attached zipped file - namely -

On Sat, Oct 13, 2012 at 5:14 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Oct 10, 2012 at 6:15 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: >> Hi Eli and Others >> >> In response to your feedback, I have taken care of all your review comments >> - I removed clangOMP.a >> and moved the implementation of "class

On Wed, Oct 10, 2012 at 5:40 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Tue, Oct 9, 2012 at 4:37 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > > Hello All, > > > > We would like to make a proposal to support OpenMP in CLANG. The goal of > > this effort is to provide support for syntax > > > > analysis (parsing), semantic

Hi Eli, Attached is the next patch in the line. This patch (class_pragma_omp_handler_support.patch) contains the implementation of the class "class PragmaOmpHandler". I also attached the test case (openmp_syntax_test.c). This test case is actually to test the syntactically legal simple OpenMP constructs. However, we can *really* test it only after submitting the next two patches - one

Hello Duncan Sands, >From your reply, what I can understand is that there is no any new OPENMP specific instructions introduced into LLVM IR as a part of DragonEgg project since GCC has already done the job of lowering OpenMP directives into GOMP runtime library calls at LOW GIMPLE IR level. Now, it throws up following questions. 1. Am I correct that DragoEgg should logically supports

On Tue, Oct 9, 2012 at 4:37 AM, Mahesha HS <mahesha.llvm at gmail.com> wrote: > Hello All, > > We would like to make a proposal to support OpenMP in CLANG. The goal of > this effort is to provide support for syntax > > analysis (parsing), semantic analysis and AST implementation for OpenMP > constructs in CLANG. > > > > We would like to defer the design for

Hello All, We would like to make a proposal to support OpenMP in CLANG. The goal of this effort is to provide support for syntax analysis (parsing), semantic analysis and AST implementation for OpenMP constructs in CLANG. We would like to defer the design for *lowering* based on the outcome of the discussion happening in the LLVM dev list. Our design is aimed at implementing the necessary

Let's forget about my malformed IR if it is adding additional confusion here. I mentioned it here to ease the conversation, but if it is causing confusion rather than making the discussion flow easier, then we better ignore it. The whole triggering point for this email initiative is - one of the applications is crashing with the stack trace that I mentioned earlier. The crash is during the

I am bit confused - `unit` must be present for definitions, and `optimized ` is also a `definition`, so, `unit` must be present for `optimized ` too. Am I right? Mahesha On Sun, May 31, 2020 at 10:14 PM David Blaikie <dblaikie at gmail.com> wrote: > definition and optimized are orthogonal (a function could be both, or > neither) - one says this DISubprogram describes a function

Hi Eli and Others In response to your feedback, I have taken care of all your review comments - I removed clangOMP.a and moved the implementation of "class OmpPragmaHandler" to "clangLex.a". The attached zipped file - namely - 'OpenMP_support_in_Clang.tar.gz' contains all the implemented "patches" along with *newly* added source files. Another attached text

Hi David If you look at line https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160 there is IR verification which asserts that only in case of `spFlags = DISPFlagDefinition`, the compilation unit (`unit` field) should be present. Otherwise, it should *not* be present. In the crash case, `spFlags = DISPFlagOptimized`. So, I guess, `unit` field should *not* be present,