similar to: [LLVMdev] Tablegen bug???

If the source being scanned has "llvm.AMDIL.barrier.global, it will match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global. On Nov 29, 2012, at 7:19 PM, Chris Lattner <clattner at apple.com> wrote: > Out of curiosity, what is wrong about that? It looks ok to me. > > -Chris > > On Nov 29, 2012, at 6:52 PM, "Relph, Richard"

Out of curiosity, what is wrong about that? It looks ok to me. -Chris On Nov 29, 2012, at 6:52 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed? > > In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparing

Was a fix for this ever applied to trunk? On Fri, Nov 30, 2012 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: > Yes that definitely sounds like a bug, no intrinsically in mainline are a > prefix if another one, or we are getting lucky. > > -Chris > > On Nov 29, 2012, at 7:24 PM, "Relph, Richard" <Richard.Relph at amd.com> > wrote: > >

Yes that definitely sounds like a bug, no intrinsically in mainline are a prefix if another one, or we are getting lucky. -Chris On Nov 29, 2012, at 7:24 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > If the source being scanned has "llvm.AMDIL.barrier.global, it will match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global. > >

Hi, I am trying to assign values to records based conditionally on other records within a dataframe. For example, in the following dataframe the "NA" value in dat$age would be replaced if the age status for that individual and specific year can be found in another record. Ideally this would then also assign the same age status if the individual is recorded in a later year.

Hi, The behavior of ``` SEXP R_ParseVector(SEXP, int, ParseStatus *, SEXP); ``` defined in `src/include/R_ext/Parse.h` appears to be inconsistent depending on the string to be parsed. Trying to parse a string such as `"list(''=1+"` sets the `ParseStatus` to incomplete parsing error but trying to parse `"list(''=123"` will result in R sending a message to the

I have intrinsic with no return value and I need to match them to machine instructions. If the instruction has a return value I am able to correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted. Here is my profile/node/pattern. Profile: def SDTIL_BinAtomNoRet : SDTypeProfile<0, 3, [ SDTCisPtrTy<0>, SDTCisVT<1, i32>,

On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote: > I have intrinsic with no return value and I need to match them to machine instructions. If the instruction has a return value I am able to correctly match it, but if I try to create some tablegen code that has no return value, the instruction gets deleted. Hi Micah, >From your description it sounds like machine dead code elimination is

Hi again, Beside R_ParseVector()'s possible inconsistent behavior, R's handling of zero-length named elements does not seem consistent either: ``` > lst <- list() > lst[[""]] <- 1 > names(lst) [1] "" > list("" = 1) Error: attempt to use zero-length variable name ``` Should the parser be made to accept as valid what is otherwise possible

> -----Original Message----- > From: Jim Grosbach [mailto:grosbach at apple.com] > Sent: Monday, November 08, 2010 10:41 AM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Creating tablegen patterns for intrinsics with > no return value. > > > On Nov 8, 2010, at 10:32 AM, Villmow, Micah wrote: > > > I have intrinsic with no

Thanks for the quick response Tomas. The same error is indeed happening when trying to have a zero-length variable name in an environment. The surprising bit is then "why is this happening during parsing" (that is why are variables assigned to an environment) ? We are otherwise aware that the error is not occurring in the R console, but can be traced to a call to R_ParseVector() in

Full_Name: Roger Bivand Version: 0.99.0 OS: RH Linux 6.1 Submission from: (NULL) (158.37.60.152) I am working on an interface between R and the GRASS geographical information system, written in R, with no dynamically loaded code. I have written full examples, and tested then under R 0.90.1, both by entering example() for each function and R CMD check, both of which worked without problem. Under

Le lun. 9 d?c. 2019 ? 09:57, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/9/19 2:54 PM, Laurent Gautier wrote: > > > > Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a > ?crit : > >> On 12/7/19 10:32 PM, Laurent Gautier wrote: >> >> Thanks for the quick response Tomas. >> >> The same error

Le lun. 9 d?c. 2019 ? 05:43, Tomas Kalibera <tomas.kalibera at gmail.com> a ?crit : > On 12/7/19 10:32 PM, Laurent Gautier wrote: > > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is this > happening during parsing" (that is why

I found the following code comment in `src/main/gram.c`: ``` /* Memory leak yyparse(), as generated by bison, allocates extra space for the parser stack using malloc(). Unfortunately this means that there is a memory leak in case of an R error (long-jump). In principle, we could define yyoverflow() to relocate the parser stacks for bison and allocate say on the R heap, but yyoverflow() is

Dear Laurent, could you please provide a complete reproducible example where parsing results in a crash of R? Calling parse(text="list(''=123") from R works fine for me (gives Error: attempt to use zero-length variable name). I don't think the problem you observed could be related to the memory leak. The leak is on the heap, not stack. Zero-length names of elements in a

Hi Simon, Widespread errors would have caught my earlier as the way that code is using only one initialization of the embedded R, is used quite a bit, and is covered by quite a few unit tests. This is the only situation I am aware of in which an error occurs. What is a "correct context", or initial context, the code should from ? Searching for "context" in the R-exts manual

Hi John, %4 is not returned, because it's a temp register value and not a named variable. But you can implement something like the code below to get this value. (Not the most elegant, but more or less working solution). static std::string getName(Instruction* i) { if(i->getOpcode() == Instruction::Store) { return

Hi. I found that, in all the LLVM IR I get from the source C file. the unnamed values all created by the "load" instruction. eg: ; Function Attrs: nounwind uwtable define i32 @add(i32 %x, i32 %y) #0 { entry: %x.addr = alloca i32, align 4 %y.addr = alloca i32, align 4 %c = alloca i32, align 4 store i32 %x, i32* %x.addr, align 4 store i32 %y, i32* %y.addr, align 4 * %0 =

On 12/7/19 10:32 PM, Laurent Gautier wrote: > Thanks for the quick response Tomas. > > The same error is indeed happening when trying to have a zero-length > variable name in an environment. The surprising bit is then "why is > this happening during parsing" (that is why are variables assigned to > an environment) ? The emitted R error (in the R console) is not a