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 =