similar to: [LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'

Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'"

2011 Feb 13
2
[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'
Hi Duncan Many many thanks, it works now! But there are still some details I must be missing. I'm getting an assertion when I try the following assignment in my script: global c = cos(1); Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!", file c:/llvm-source-2.7/include/llvm/Support/Casting.h, line 200 However, running for example
2011 Feb 12
0
[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'
Hi Anton, > I'm getting the following error > > error: invalid conversion from `const llvm::Value*' to `llvm::Constant*' > > How may I make this conversion? Any help would be much appreciated! cast<Constant>(whatever) Ciao, Duncan.
2011 Feb 13
3
[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'
Oh, I thought that after "codegening" cos(0) would get me double 1.0 (assigment is working for anything like: global a = 1/3 + 2 /3 for example) What would be the best way to make assigments involving functions, like global a = cos(0); without getting the assertion arising from InitVal = cast<Constant>(Init->Codegen()); ? I made some changes and now my code basically works,
2011 Feb 13
0
[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'
Hi Anton, > But there are still some details I must be missing. I'm getting an assertion > when I try the following assignment in my script: > global c = cos(1); > Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!", I think this is telling you that cos(1) is not a constant. Ciao, Duncan.
2012 Nov 10
2
[LLVMdev] Forward references of globals in .ll files
I'm experiencing a weird issue during .ll file parsing, and I'm not sure if it's a bug in the .ll parser, or if I'm just not understanding the IR. Take the following IR: @a = addrspace(1) global i8 0 @a2 = global i8 addrspace(1)* @a This parses fine. But if I rearrange the statements to: @a2 = global i8 addrspace(1)* @a @a = addrspace(1) global i8 0 then I get an ugly
2012 Nov 10
0
[LLVMdev] Forward references of globals in .ll files
On Fri, Nov 9, 2012 at 5:01 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > I'm experiencing a weird issue during .ll file parsing, and I'm not sure if > it's a bug in the .ll parser, or if I'm just not understanding the IR. > > Take the following IR: > > @a = addrspace(1) global i8 0 > @a2 = global i8 addrspace(1)* @a > > This
2023 Dec 05
3
[Bug 1726] New: invalid json generated by ipset list -output json
https://bugzilla.netfilter.org/show_bug.cgi?id=1726 Bug ID: 1726 Summary: invalid json generated by ipset list -output json Product: ipset Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: trivial Priority: P5 Component: default Assignee:
2011 Feb 13
0
[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'
Hi Anton, > Oh, I thought that after "codegening" cos(0) would get me double 1.0 > (assigment is working for anything like: global a = 1/3 + 2 /3 for > example) What would be the best way to make assigments involving > functions, like global a = cos(0); > without getting the assertion arising from InitVal = > cast<Constant>(Init->Codegen()); ? the problem
2011 Feb 13
1
[LLVMdev] conversion from 'const llvm::Value*' to 'llvm::Constant*'
Hi Duncan and Reid, Thanks for your comments and suggestions. I was puzzled because assigning to a local variable in the tutorial example works. For example: var a = cos(1) in ( 2 * a ); emits declare double @cos(double) define double @0() { entry: ret double 0x3FF14A280FB5068C } and we get the right answer 1.08060461. On Sun, Feb 13, 2011 at 5:09 PM, Duncan Sands <baldrick at
2018 Nov 01
0
AD GlobalNames zone
Hi, MS AD feature the GlobalNames DNS zone. Is there the same feature in Samba AD (with bind9 DLZ)? ifeher Ez az e-mail és bármely melléklete kizárólag a címzettnek szól. A címzett személyes adatait a küldő fél a www.e77.hu oldalon ITT elérhető adatkezelési tájékoztatóban foglaltak szerint kezeli. Az ott leírtak szerint ön jogosult tiltakozni személyes adatainak kezelése ellen. A jelen
2012 Mar 08
3
rpanel / list error
Hi All, I have created a simulation that works perfect and I have the results been returned in a list as I have multiple values. I then decided to include some user interaction by using the package rpanel, I now get the error: object of type 'builtin' is not subsettable when I attempted to have the return my list with the results . Any help needed. I can also upload code if needs be.
2017 Aug 04
2
Bug or incorrect use of inline asm?
On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org>: > > The error is gone after removing (or reducing) the alignment of `%a`. > This > > makes me believe that our inline asm syntax is correct to add an offset > to a > > pointer: "
2012 Nov 10
2
[LLVMdev] Forward references of globals in .ll files
Does not work and same error even on old r157485 build. - D. 2012/11/10 Eli Friedman <eli.friedman at gmail.com>: > On Fri, Nov 9, 2012 at 5:01 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: >> I'm experiencing a weird issue during .ll file parsing, and I'm not sure if >> it's a bug in the .ll parser, or if I'm just not understanding
2013 Mar 26
0
[LLVMdev] Fwd: Extending Kaleidoscope to support Strings
I hope this is the right place to ask this question. If not, please let me know where I can ask for help. We are using Kaleidoscope as the base framework to write a source to source compiler. Our source language has Strings with supported operations such as concatenation, upper case, and substrings. I am following the patterns set forth in Kaleidoscope, and need to represent my std::string as
2012 Sep 09
1
Error msg in rpanel
I am working on the r panel package. Now if i have a function that uses a radiogroup button, and if i attempt to run the function from inside the rpanel menu, i get this error: Error in panel$intname : $ operator is invalid for atomic vectors However if i run the function per se i.e. not from inside the rpanel menu, but by calling it independently, the above error doesn't appear. Here is a
2014 May 05
2
[LLVMdev] [RFC] Section Declarations in LLVM IR
Just a heads up, I'm planning on sending patches for this soon. -- David Majnemer On Tue, Apr 1, 2014 at 2:23 PM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > > I like this proposal. Any reason to use an explicit offset rather than > > allow GEPs into aliases? > > Part of pr10367. A contant gep is more generic than whan an alias can > actually
2003 Dec 14
1
compile error with C code and standalone R math C library
Dear People, I just went back to an old piece of C code. On trying to compile it with the R math standalone C library I got the following error. Can anyone enlighten me what I am doing wrong, if anything? C file (rr-sa.c) follows. I'm on Debian sarge. I'm running R version 1.8.1. Gcc is version 3.3.1. Thanks in advance. Faheem.
2010 Oct 13
2
How to fix error in the package 'rgenoud'
Dear R user fellows, I would like to ask you about the package 'rgenoud' which is a genetic optimization tool. I ran the function 'genoud' with two variables to be minimized by the following command. result<-genoud(fn,nvars=2,starting.values=c(0.5,0), pop.size=1000, max.generations=10, wait.generations=3) Then, I had the following error message. Error in
2011 Feb 08
1
[LLVMdev] Question about linker error
Hello all, When extending the tutorial to support global variables I'm getting the following linker error: glob.o:glob.cpp:(.text+0x12241): undefined reference to `vtable for GlobalExprAST' collect2: ld returned 1 exit status GlobalExprAST class is: /// GlobalExprAST - Expression class for globals class GlobalExprAST : public ExprAST { std::string Name; ExprAST *Init; public:
2013 Mar 15
22
[PATCH 00/09] arm: tools: build for arm64 and enable cross-compiling for both arm32 and arm64
The following patches shave some rough edges off the tools build system to allow cross compiling for at least arm32 and arm64 based on the Debian/Ubuntu multiarch infrastructure. They also add the necessary fixes to build for arm64 (which I have only tried cross, not native). I have posted some instructions on how to compile with these patches on the wiki: