search for: real_typ

...a/LLVM/src/GCC/RELEASE_26/gcc/llvm-abi.h.jnz Thu Oct 29 00:32:52 2009 +++ /data/LLVM/src/GCC/RELEASE_26/gcc/llvm-abi.h Fri Oct 30 13:09:09 2009 @@ -529,7 +529,12 @@ HandleArgument(TREE_TYPE(type), ScalarElts); C.ExitField(); } + } else if (TREE_CODE(type) == REAL_TYPE) { + fprintf(stderr,"unhandled REAL_TYPE!\n"); + assert(0 && "unhandled REAL_TYPE!"); + abort(); } else { + fprintf(stderr,"unknown aggreate type %d\n",TREE_CODE(type)); assert(0 && "unknown aggregate type!")...

Hello, Juergen > With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', > so I wonder what needs to be done in order to get LLVM to produce > code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function. > > > Does anyone have an idea? And why does this only happen on SPARC? What is the value of "Ty" in your...

...he fast response. Ty->dump() prints "{double, double}" in the failing case (just before my introduced assert). HTH, and regards, Juergen On 10/30/09 16:19, Anton Korobeynikov wrote: > Hello, Juergen > >> With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', >> so I wonder what needs to be done in order to get LLVM to produce >> code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function. >> >> >> Does anyone have an idea? And why does this only happen on SPARC? > What is the value o...

Anton, I went with the first alternative with some success. However, now I get some errors during the build of libgcc with 'multiply defined symbols'. One thing I noticed is the following fact: Definition in unwind-pe.h: static const unsigned char * read_sleb128 (const unsigned char *p, _Unwind_Sword *val) --- GCC 4.2.4 bootstrapped on Solaris/SPARC -bash-3.00$ nm unwind-dw2.o | grep

Hello, Juergen > Ty->dump() prints "{double, double}" in the failing case (just before my > introduced assert). The answer is simple. The code in question contains extended IEEE FP argument / return type (aka 'long double'). By default it's lowered into struct {double, double} as you already saw and sparc currently does not provide any argument layout hooks. There

...0 Aaron Gray <aaronngray.lists at googlemail.com> > 2010/1/10 Duncan Sands <baldrick at free.fr> > > Hi Aaron, >> >> >> Thanks, okay heres the results :- >>> >>> LLVM type size doesn't match GCC type size! >>> >>> <real_type 0x7ff80b40 long double sizes-gimplified XF size <integer_cst >>> 0x7ff010e0 type <integer_type 0x7ff80060 bit_size_type> constant invariant >>> 96> >>> unit size <integer_cst 0x7ff01100 type <integer_type 0x7ff80000 >>> unsigned int> cons...

...compatible with that flag at -O3. I see compilation failures of the form... /sw/lib/gcc4.5/bin/gfortran -O3 -fplugin=/sw/lib/gcc4.5/lib/dragonegg.so -fplugin-arg-dragonegg-enable-gcc-optzns ac.f90 -o ac <misaligned_indirect_ref 0x1438ad230 type <vector_type 0x141d6ad20 type <real_type 0x141d1e0a8 real(kind=8) DF size <integer_cst 0x141d01a50 constant 64> unit size <integer_cst 0x141d01a78 constant 8> align 64 symtab 0 alias set 2 canonical type 0x141d1e0a8 precision 64 pointer_to_this <pointer_type 0x141d1e2a0> r...

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

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call

...;type" in current context. (gdb) up #4 0x0000000000a86501 in TypeConverter::ConvertType (this=0x16941a0, orig_type=0x2b709d6f8790) at /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:756 756 case 80: return SET_TYPE_LLVM(type, Type::X86_FP80Ty); (gdb) call debug_tree(type) <real_type 0x2b709d6f8790 long double sizes-gimplified XF size <integer_cst 0x2b709d6f39c0 type <integer_type 0x2b709d6e4370 bit_size_type> constant invariant 96> unit size <integer_cst 0x2b709d6f39f0 type <integer_type 0x2b709d6e42c0 long unsigned int> constant invariant 12>...

I am getting an assertion firing while building TOT llvm-gcc on Cygwin in libgcc2.c :- /home/ang/build/llvm-gcc/./gcc/xgcc -B/home/ang/build/llvm-gcc/./gcc/ -B/home/an g/llvm-gcc/i686-pc-cygwin/bin/ -B/home/ang/llvm-gcc/i686-pc-cygwin/lib/ -isystem /home/ang/llvm-gcc/i686-pc-cygwin/include -isystem /home/ang/llvm-gcc/i686-pc-c ygwin/sys-include -O2

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

Bam. This is about as reduced as it gets. I think I can spot the problem point: chandlerc at osiris ~/code/compilers/build/llvm-gcc $ cat testcase.i void foo () { float x __attribute__ ((mode (XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const