search for: getsourcerang

Displaying 5 results from an estimated 5 matches for "getsourcerang".

Did you mean: getsourcerange
2019 Mar 04
3
RFC for f18+runtimes in LLVM
...y a complicated language and mixing all of Fortran's concerns (including a completely different object model) will make both of them *worse* than having them stand alone IMO. Could there be a common base class for flang and clang AST nodes? That is, an abstract class that has children()/dump()/getSourceRange()? Michael
2018 May 25
1
MSP430: interrupt vector number out of bounds error in v6/trunk (with patch)
...a/SemaDeclAttr.cpp:5104 unsigned Num = NumParams.getLimitedValue(255); if ((Num & 1) || Num > 30) { S.Diag(AL.getLoc(), diag::err_attribute_argument_out_of_bounds) << AL.getName() << (int)NumParams.getSExtValue() << NumParamsExpr->getSourceRange(); return; } Also, the __isr_ symbol is emitted with the vector number divided by 2. // Step 3: Emit ISR vector alias. unsigned Num = attr->getNumber() / 2; llvm::GlobalAlias::create(llvm::Function::ExternalLinkage, "__isr_" + Tw...
2014 Dec 09
3
[LLVMdev] [cfe-dev][Openmp-dev] Clang Plugin to analyze OpenMP AST
Hi, I am writing a plugin to get information about the OpenMP constructs from the AST. I am basically writing a “RecursiveASTVisitor” and I am trying to find the OpenMP statement and get information like filename and line of code. When I am visiting recursively each statement I have my own switch on the “StmtClass” and for now I am focusing on “OMPParallelForDirectiveClass”. In my understanding,
2018 Dec 31
4
RFC: Modernizing our use of auto
On Dec 16, 2018, at 11:44 AM, Stephen Kelly via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 25/11/2018 14:43, Stephen Kelly via llvm-dev wrote: >> However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. >> Currently the rule on the use of auto is here: > > Hi, > > Thanks for the input on this topic,
2019 Mar 01
6
RFC for f18+runtimes in LLVM
On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote: > This RFC started a good discussion and I’d like to hear responses from its author > to all of the points that have been made so far. > >   > > FWIW, I’m also in favor of reusing as much from Clang as practical.  In fact, with> the combined repo now, it might make sense to factor out some common front end code > that