similar to: [LLVMdev] numeric limits of llvm Types?

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] numeric limits of llvm Types?"

2015 Jan 22
2
[LLVMdev] access IntegerType::getSignBit from Type *
Hi, I have a Type * which may come from an IntegerType as shown below: Type.getIntegerBitWidth() tells me numBits. But how to extract the IntegerType.getSignBit? If pType isIntegerType, I need to know if it is signed or unsigned... How to achieve this? Thx Alex llvm::Type * getRandomValid_IntegerType(llvm::LLVMContext &C) { using namespace llvm; //--- determine num of bits
2007 Sep 05
2
[LLVMdev] Seeing a crash with ConstantFP::get
Hola LLVMers, I'm getting a crash when using ConstantFP::get. I can repro it by adding one line to the Fibonacci example program: int main(int argc, char **argv) { int n = argc > 1 ? atol(argv[1]) : 24; // Create some module to put our function into it. Module *M = new Module("test"); // We are about to create the "fib" function: Function
2007 Sep 05
2
[LLVMdev] Seeing a crash with ConstantFP::get
It's in debug. I'm having a look at the assembler it's producing right now and it's definitely a little odd for what should be a simple assignment in zeroSignificand. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Dale Johannesen Sent: Wednesday, September 05, 2007 2:39 PM To: LLVM Developers Mailing
2004 May 04
0
[LLVMdev] Plea for help
On Tue, 4 May 2004, Finn S Andersen wrote: > Chris wrote in a followup: > > > Can you send the output of 'llc -o - foo.bc -debug -print-machineinstrs'? > > > Attached as "linscan". (But added the "-regalloc=linearscan" to provoke > the error). Yes, that's exactly what I meant... thanks for reading my mind! :) It looks like this is where
2004 May 05
2
[LLVMdev] Plea for help
Chris Lattner wrote: >Could you try compiling and running this program: > >--- >#include <limits> >#include <iostream> >int main() { > std::cerr << std::numeric_limits<float>::infinity() << "\n"; >} >--- > > Sure thing. It prints "0". Calling that inifinity is somewhat of a stretch, isn't it ? What on earth
2004 May 06
0
[LLVMdev] Plea for help
On Thu, May 06, 2004 at 04:06:27PM +0200, Finn S Andersen wrote: > Chris Lattner wrote: > > >I think that we should switch to C constants in this case. Can you try > >#include <math.h> and use HUGE_VAL instead? > > > It works: > > [finna at coplin11 ~/test]$ cat tst.cpp > #include <limits> > #include <iostream> > #include
2004 May 06
3
[LLVMdev] Plea for help
Chris Lattner wrote: >I think that we should switch to C constants in this case. Can you try >#include <math.h> and use HUGE_VAL instead? > It works: [finna at coplin11 ~/test]$ cat tst.cpp #include <limits> #include <iostream> #include <math.h> int main() { std::cerr << std::numeric_limits<float>::infinity() << "\n"; std::cerr
2007 Sep 05
0
[LLVMdev] Seeing a crash with ConstantFP::get
On Sep 5, 2007, at 2:21 PM, Chuck Rose III wrote: > Hola LLVMers, > > > > I’m getting a crash when using ConstantFP::get. > > > > I can repro it by adding one line to the Fibonacci example program: > > > > int main(int argc, char **argv) { > > int n = argc > 1 ? atol(argv[1]) : 24; > > > > // Create some module to put our function
2007 Sep 06
0
[LLVMdev] Seeing a crash with ConstantFP::get
Hola Dale, I spent some time walking through what's going on with a friend of mine from VStudio. Category is given 2 bits in the APFloat class definition. It's sign extending the enum value for the comparisons when it loads it out of the class, so the 2 becomes a -2 and the comparison fails. He sent me a piece of code which I might be able to use to force the issue. I'll update
2004 May 05
0
[LLVMdev] Plea for help
On Wed, 5 May 2004, Finn S Andersen wrote: > Chris Lattner wrote: > > >Could you try compiling and running this program: > > > >--- > >#include <limits> > >#include <iostream> > >int main() { > > std::cerr << std::numeric_limits<float>::infinity() << "\n"; > >} > >--- > > > > > Sure
2012 May 24
1
[LLVMdev] vmkit: Getting Started
Hi, I recently tried to follow the instructions on http://vmkit.llvm.org/get_started.html but all I get is -- snip -- In file included from /home/birdspider/vmkit-test/llvm/include/llvm/Support/SwapByteOrder.h:20: /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:1404:27: error: use of undeclared identifier '__int128'; did you mean
2005 May 03
0
[LLVMdev] VC++ build broken
On Mon, 2 May 2005, Jeff Cohen wrote: > The recently added code: > static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { > if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); > if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); > if (V2->isNullValue()) return 0; > BuiltinType R =
2005 May 03
2
[LLVMdev] VC++ build broken
Yes, that will work. I'll make the change. Chris Lattner wrote: > On Mon, 2 May 2005, Jeff Cohen wrote: > >> The recently added code: >> static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { >> if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); >> if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty,
2006 Sep 02
0
[LLVMdev] gfortran calling convention
On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.
2007 Aug 18
1
[LLVMdev] Soft floating point support
This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and
2015 May 18
2
[LLVMdev] copy value of a global's data field to another global
getInitializer returns the complete initializer of the global. My globals are complex nested structs, from which I want to extract e.g. one double datafield. Example: >From a struct Stuct having double,array(3xint),float fields, I could extract the second int value using the index sequence 0,1,1 with getGetElementPtr. This gives me a constantPointer, but I would need to get a constInt...
2015 Mar 18
5
[LLVMdev] casting Constant * to value *?
John, you are right. I 'browsed' the doxygen's inheritance diagram. Shouldn't I then be able to cast Constant * to Value*? Plugging the retrieved Constant* (from ConstantExpr::getGetElementPtr) into Instruction->setOperand compiles, but gives me an assertion failure at runtime. I have no access to the code at the moment. I will gather more information possibly tomorrow.
2006 Sep 02
2
[LLVMdev] gfortran calling convention
The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common
2015 Mar 16
4
[LLVMdev] size of const_ptr for array index
Hi all, when e.g. accessing a global variable residing in a structure, the c++API code looks like: std::vector<Constant*> const_ptr_183_indices; const_ptr_183_indices.push_back(const_int32_172); const_ptr_183_indices.push_back(const_int32_184); const_ptr_183_indices.push_back(const_int64_175); Constant* const_ptr_183 = ConstantExpr::getGetElementPtr(gvar_struct_foo,
2015 Mar 10
3
[LLVMdev] Chatty C++API code generation
Hi all, when I have c code like --- c code ------------- struct stest { /* deklariert den Strukturtyp person */ int age; float weight; } foo={44,67.2}; /* deklariert Variable des Typs person */ int main() { callAFunction(foo.weight); ------------------------ The generated c++API code to me seems to be too chatty in the sense that the foo.weight's data