search for: function_decl

...#39;/usr/include/math.h', ['-x', 'c-header']) >>> c = tu.cursor >>> for d in c.get_children(): ... print d.kind, d.spelling ... CursorKind.TYPEDEF_DECL __int128_t CursorKind.TYPEDEF_DECL __uint128_t CursorKind.TYPEDEF_DECL __builtin_va_list [...] CursorKind.FUNCTION_DECL acosf CursorKind.FUNCTION_DECL acos CursorKind.FUNCTION_DECL acosl [...] Am I doing something obviously wrong (aside from calling math.h a C++ header)? Is there any reasonable way to debug problems like this? I'm on Mac OS X 10.8 using the Clang binaries from Xcode (Apple LLVM version 5.0 (cl...

...'c-header']) > >>> c = tu.cursor > >>> for d in c.get_children(): > ... print d.kind, d.spelling > ... > CursorKind.TYPEDEF_DECL __int128_t > CursorKind.TYPEDEF_DECL __uint128_t > CursorKind.TYPEDEF_DECL __builtin_va_list > [...] > CursorKind.FUNCTION_DECL acosf > CursorKind.FUNCTION_DECL acos > CursorKind.FUNCTION_DECL acosl > [...] > > Am I doing something obviously wrong (aside from calling math.h a C++ > header)? Is there any reasonable way to debug problems like this? > > I'm on Mac OS X 10.8 using the Clang binaries...

...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 8> align 64 context <function_decl 0x4175d400 MAIN__> LLVM: i64 %67 chain <var_decl 0x41774310 D.927 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 s...

...#39;c-header']) > >>> c = tu.cursor > >>> for d in c.get_children(): > ... print d.kind, d.spelling > ... > CursorKind.TYPEDEF_DECL __int128_t > CursorKind.TYPEDEF_DECL __uint128_t > CursorKind.TYPEDEF_DECL __builtin_va_list > [...] > CursorKind.FUNCTION_DECL acosf > CursorKind.FUNCTION_DECL acos > CursorKind.FUNCTION_DECL acosl > [...] > > Am I doing something obviously wrong (aside from calling math.h a C++ header)? Is there any reasonable way to debug problems like this? > > I'm on Mac OS X 10.8 using the Clang binaries fro...

.... */ external_p = (DECL_INTERFACE_KNOWN (d) && DECL_REALLY_EXTERN (d)); /* In general, we do not instantiate such templates... */ if (external_p /* ... but we instantiate inline 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_s...

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* >

...= (DECL_INTERFACE_KNOWN (d) && DECL_REALLY_EXTERN (d)); > /* In general, we do not instantiate such templates... */ > if (external_p > /* ... but we instantiate inline 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 o...

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

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.

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

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.

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

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) ((NODE)->common.static_flag) Ciao, Duncan.

...field_decl 0x200008460c0 __offset>>        pointer_to_this <pointer_type 0x20000b4c210>>    addressable used asm-frame-size 0 BLK file ../../source/gcc/libgcov.c line 818 size <integer_cst 0x20000820ea0 128> unit size <integer_cst 0x20000820ed0 16>    align 64 context <function_decl 0x20000b08300 __gcov_execl>    LLVM: %struct.va_list* %ap chain <var_decl 0x20000b44300 aq>> DestLoc is 0. Anyone have a suggestion on how to fix this? Thanks, Andrew

Hello, I'm trying to use the python libclang bindings to write a C++ style-checker, and I'd like to detect all the typedefs to recommend switching to using. I'm using libclang 3.8, with the python bindings provided with it. When I parse a file with index = clang.cindex.Index.create() tu = index.parse(f, ['-x', 'c++', '-std=c++11', '-fsyntax-only',

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

...CE_KNOWN (d) && DECL_REALLY_EXTERN (d)); >> /* In general, we do not instantiate such templates... */ >> if (external_p >> /* ... but we instantiate inline 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))) &gt...

...alias (decl=0xb7b9d618, target=0xb698fe00) at ../../2006-03-14-llvm-gcc-4/gcc/varasm.c:4765 #4 0x084d05e6 in rest_of_decl_compilation (decl=0xb7b9d618, top_level=1, at_end=0) at ../../2006-03-14-llvm-gcc-4/gcc/passes.c:204 Printing decl in frame 2 gives: (gdb) call debug_tree(decl) <function_decl 0xb7b9d618 _X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv type <function_type 0xb7ab7e88 type <void_type 0xb7ab5b40 void sizes-gimplified type_6 VOID align 8 symtab 146744576 alias set -1 pointer_to_this <pointer_type 0xb7ab5bb8>> ty...

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"));

Evan Cheng wrote: > Hi, > > Here is the follow on patch for this problem. Please apply this from > the top of the tree and rebuild. With the patch from Chris and then the patch from you combined, the previous error disappeared, but I get another error, reduced to this: ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro -auxbase-strip libgcc/./_clz.o -g -O2