search for: var_decl

Displaying 20 results from an estimated 20 matches for "var_decl".

2012 Sep 13
1
[LLVMdev] Parsing C++ template parameters using cindex.py
...am parsing a C++ file using cindex.py and want to get the template parameters to a specific node. However, the tree seems to be different depending on if the template parameter is a struct/class or a simple type such as int or float. In the first case the template type is appended as a child to the VAR_DECL node (the TYPE_REF node seen in the example below), but this is not the case with for example int. Any hint on where the template type is located for int/float/etc? /joel de vahl Example code: template <typename T> class Test { T test; }; struct S { }; Test<int> test_int; Test<...
2008 Nov 02
1
[LLVMdev] llvm-2.4 prerelease gfortran results
...64 symtab 12 alias set -1 precision 64 min <integer_cst 0x417048a0 -9223372036854775808> max <integer_cst 0x417048d0 9223372036854775807> LLVM: i64 pointer_to_this <pointer_type 0x41731070> reference_to_this <reference_type 0x4175f310>> arg 0 <var_decl 0x417742a0 D.926 type <integer_type 0x4170a4d0 int8> used ignored asm-frame-size 0 DI file /sw/src/fink.build/llvm-gcc42-2.4-1/llvm-gcc4.2-2.4.source/gcc/testsuite/gfortran.dg/array_constructor_12.f90 line 11 size <integer_cst 0x41704930 64> unit size <integer_cst 0x41704960...
2010 Mar 09
0
[LLVMdev] Fwd: help with llvm-convert
...ucts and allocated by alloca, unlike x86.  EmitBuiltinVACopy is therefore using the second branch of the if (~llvm-convert.cpp:6538) to emit the second argument.  The second argument is the result of an alloca.  TreeToLLVM::Emit is hitting the first assertion (~929). The exp being passed is:  <var_decl 0x20000b44240 ap    type <record_type 0x200008f96b0 va_list sizes-gimplified no-force-blk BLK        size <integer_cst 0x20000820ea0 constant invariant 128>        unit size <integer_cst 0x20000820ed0 constant invariant 16>        align 64 symtab 0 alias set -1        fields <fiel...
2009 Dec 04
4
[LLVMdev] r72619
...ne functions so that we can inline them and ... */ && ! (TREE_CODE (d) == FUNCTION_DECL && DECL_INLINE (d)) /* ... we instantiate static data members whose values are needed in integral constant expressions. */ && ! (TREE_CODE (d) == VAR_DECL && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (d))) goto out; For the basic_string constructor, if we don't take that "goto", something is wrong. If we do take that "goto", my guess is wrong. I don't have a recent debug llvm-gcc to validate...
2006 Sep 11
0
[LLVMdev] trying to build llvm-gcc in linux/amd64
On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to build llvm-gcc4 on a amd64. I had to add the attached > patch to get the build system to select the correct library. Now the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* >
2007 Oct 26
2
[LLVMdev] RFC: llvm-convert.cpp Patch
...lignment. + tree new_exp = copy_node(TREE_OPERAND(exp, 1)); + unsigned NewAlignment = expr_align(new_exp) / 8; + Alignment = (Alignment < NewAlignment) ? Alignment : NewAlignment; + TYPE_ALIGN(TREE_TYPE(new_exp)) = Alignment; + + switch (TREE_CODE(new_exp)) { + case VAR_DECL: + case PARM_DECL: + case RESULT_DECL: + DECL_ALIGN (new_exp) = Alignment * 8; + break; + default: + break; + } + + Emit(new_exp, LV.Ptr); } else { // Need to do a volatile store into TREE_OPERAND(exp, 1). To do this, we // emit it into a temporary me...
2009 Dec 04
0
[LLVMdev] r72619
...we can inline > them and ... */ > && ! (TREE_CODE (d) == FUNCTION_DECL && DECL_INLINE (d)) > /* ... we instantiate static data members whose values are > needed in integral constant expressions. */ > && ! (TREE_CODE (d) == VAR_DECL > && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (d))) > goto out; > > For the basic_string constructor, if we don't take that "goto", > something is wrong. If we do take that "goto", my guess is wrong. I > don't have a recent...
2006 Sep 11
5
[LLVMdev] trying to build llvm-gcc in linux/amd64
I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc
2009 Jan 05
2
[LLVMdev] RFA: TREE_READONLY in LLVM-GCC
Hi Chris, > I think this change is fine and should go into the normal apple GCC as > well. Setting TREE_READONLY means that it can go into the "constant" > section of the executable, go in ROM, etc. This is the same as the > llvm constant bit on globals. for this I think it has to be static as well as readonly. Ciao, Duncan.
2009 Jan 05
0
[LLVMdev] RFA: TREE_READONLY in LLVM-GCC
I did mark it as TREE_CONSTANT. Is that enough? -bw On Jan 5, 2009, at 2:03 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Chris, > >> I think this change is fine and should go into the normal apple GCC >> as >> well. Setting TREE_READONLY means that it can go into the "constant" >> section of the executable, go in ROM, etc. This is the same
2009 Jan 05
1
[LLVMdev] RFA: TREE_READONLY in LLVM-GCC
On Monday 05 January 2009 12:42:16 Bill Wendling wrote: > I did mark it as TREE_CONSTANT. Is that enough? No idea - if it works I guess it was enough :) I was actually thinking of TREE_STATIC: /* In a VAR_DECL, nonzero means allocate static storage. In a FUNCTION_DECL, nonzero if function has been defined. In a CONSTRUCTOR, nonzero means allocate static storage. ??? This is also used in lots of other nodes in unclear ways which should be cleaned up some day. */ #define TREE_STATIC(NODE) ((N...
2011 Apr 09
0
[LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
...ame 0x143846580 type <pointer_type 0x141d74930 type <vector_type 0x141d6ad20> public unsigned DI size <integer_cst 0x141d01a50 64> unit size <integer_cst 0x141d01a78 8> align 64 symtab 0 alias set -1 canonical type 0x141d74930> var <var_decl 0x143845460 vect_pdsauto.757>def_stmt vect_pdsauto.757_3065 = vect_pdsauto.832_3197 + 8; version 3065> arg 1 <integer_cst 0x141dea4d8 type <integer_type 0x141d11000> constant 64>> Not a gimple constant! UNREACHABLE executed at /sw/src/fink.build/dragonegg-gcc45-2.9...
2009 Dec 04
0
[LLVMdev] r72619
Hi Bill, > Here's what I get with TOT compiling with -Os. The orig.ll is what I get > before r72619. Notice that orig.ll has only one function in it. Both the > one you sent and duncan.ll have more than one function. It's not the > fact that more than one function is showing up, but these functions in > particular shouldn't be there because of the implicit/explicit
2011 Apr 09
3
[LLVMdev] dragonegg/llvm-gfortran/gfortran benchmarks
On 4/9/2011 6:09 AM, Duncan Sands wrote: > Hi Jack, thanks for the numbers. Any chance of analysing why gcc does better on > those where it does much better than dragonegg? > > Ciao, Duncan. Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to match GCC performance where GCC was faster? Marcus
2005 Aug 12
3
IA32E make failed in latest version 6117
...sn:HI 2752 2751 396 19 (set (reg/f:DI 707) (plus:DI (reg/f:DI 262) (const_int 137438953472000 [0x7d0000000000]))) -1 (insn_list 2751 (nil)) (expr_list:REG_DEAD (reg/f:DI 262) (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("_end") [flags 0x40] <var_decl 0x2a97cb1270 _end>) (const_int 137438953472000 [0x7d0000000000]))) (nil)))) setup.c:530: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugz...
2009 Dec 04
2
[LLVMdev] r72619
...>> them and ... */ >> && ! (TREE_CODE (d) == FUNCTION_DECL && DECL_INLINE (d)) >> /* ... we instantiate static data members whose values are >> needed in integral constant expressions. */ >> && ! (TREE_CODE (d) == VAR_DECL >> && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (d))) >> goto out; >> >> For the basic_string constructor, if we don't take that "goto", >> something is wrong. If we do take that "goto", my guess is wrong. I >> don...
2007 Oct 26
0
[LLVMdev] RFC: llvm-convert.cpp Patch
...node(TREE_OPERAND(exp, 1)); > + unsigned NewAlignment = expr_align(new_exp) / 8; > + Alignment = (Alignment < NewAlignment) ? Alignment : > NewAlignment; > + TYPE_ALIGN(TREE_TYPE(new_exp)) = Alignment; > + > + switch (TREE_CODE(new_exp)) { > + case VAR_DECL: > + case PARM_DECL: > + case RESULT_DECL: > + DECL_ALIGN (new_exp) = Alignment * 8; > + break; > + default: > + break; > + } > + > + Emit(new_exp, LV.Ptr); > } else { > // Need to do a volatile store into TREE_OPERAND(exp, 1)...
2009 Dec 04
2
[LLVMdev] r72619
On Dec 4, 2009, at 12:52 AM, Duncan Sands wrote: > Hi Bill, > >> There's a problem with your check-in for r72619 is causing "weak >> external" symbols to appear in C++ code when it shouldn't. Take >> this code for example, >> #include <stdexcept> >> void dummysymbol() { >> throw(std::runtime_error("string"));
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =