search for: baldrick

...sing here that's not getting us > very far very fast. > > -eric > > > On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > > yes - i checked that the src->getType()->isFloatTy() is true > Yakov > > > On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > >> On 14/11/11 19:20, Yakov Malinkovich wrote: >> >>> I sure that is. >>> >> >> Did you test it? Can you do: src->getType()->isFloatTy() >> >> >> What could be other reasons for such error? >> >&g...

So what do you think the problem is? Thank you. Yakov On Mon, Nov 14, 2011 at 10:20 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 21:11, Yakov Malinkovich wrote: > >> Here is the error that I get: >> Assertion failed: (i >= FTy->getNumParams() || FTy->getParamType(i) == >> Params[i]->getType()) && "Calling a function with a bad signature!&qu...

...; far very fast. > > -eric > > > On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > >> yes - i checked that the src->getType()->isFloatTy() is true >> Yakov >> >> >> On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> On 14/11/11 19:20, Yakov Malinkovich wrote: >> >> I sure that is. >> >> >> Did you test it? Can you do: src->getType()->isFloatTy() >> >&...

...g-x86_64-linux/builds/197 The odd thing is that I can't see any suspicious looking commits. Does anyone have any suggestions? Here are what the failures look like: (1) llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td 0 llvm-tblgen 0x0818937b Stack dump: 0. Program arguments: /home/baldrick/osuosl/slave/llvm-gcc-i386-linux-selfhost/llvm.obj.2/Release+Asserts/bin/llvm-tblgen -I /home/baldrick/osuosl/slave/llvm-gcc-i386-linux-selfhost/llvm.src/lib/VMCore -I /home/baldrick/osuosl/slave/llvm-gcc-i386-linux-selfhost/llvm.src/include -I /home/baldrick/osuosl/slave/llvm-gcc-i386-linux-sel...

...) + 1609 37 clang 0x000000000063c268 cc1_main(char const**, char const**, char const*, void*) + 920 38 clang 0x0000000000645f77 main + 7079 39 libc.so.6 0x00002aaaab8b7c4d __libc_start_main + 253 40 clang 0x0000000000639ad9 Stack dump: 0. Program arguments: /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.obj/Release+Asserts/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-llvm -disable-free -main-file-name slib.c -mrelocation-model static -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -coverage-file Output/s...

...a different issue that appeared at -O1 (and it first seemed to explain your original problem; but now I think the -O1 transform was correct and does not explain your original problem). Ciao, Duncan. > > Thanks for your answers > Best Regards > Seb > > 2012/2/29 Duncan Sands <baldrick at free.fr <mailto:baldrick at free.fr>> > > Hi Seb, > > > If I remove datalayout definition, code is not optimized and work as > expected. > So my question is: > > What attribute/value/interpretation of data-layout would cause...

yes - i checked that the src->getType()->isFloatTy() is true Yakov On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 19:20, Yakov Malinkovich wrote: > >> I sure that is. >> > > Did you test it? Can you do: src->getType()->isFloatTy() > > > What could be other reasons for such error? > > The only other possibility I can think of is...

...is none). For example, alias analysis, anything that needs to understand getelementptr offsets, the list is endless. I suggest you open a bug report, describing your original problem as in your first email. Ciao, Duncan. > Thanks for your answers > Seb > > 2012/2/28 Duncan Sands <baldrick at free.fr <mailto:baldrick at free.fr>> > > On 28/02/12 17:48, John Regehr wrote: > >> void t2(double *x) > >> { > >> long long a[2]; > >> a[0] = 3; > >> a[1] = 5; > >> *x...

...8 cc1_main(char const**, char > const**, char const*, void*) + 920 > 38 clang 0x0000000000645f77 main + 7079 > 39 libc.so.6 0x00002aaaab8b7c4d __libc_start_main + 253 > 40 clang 0x0000000000639ad9 > Stack dump: > 0. Program arguments: > > /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.obj/Release+Asserts/bin/clang > -cc1 -triple x86_64-pc-linux-gnu -emit-llvm -disable-free > -main-file-name slib.c -mrelocation-model static -masm-verbose > -mconstructor-aliases -munwind-tables -target-cpu x86-64 > -momit-leaf-frame-pointer -co...

...negg bug. Can you please open a bugreport at http://llvm.org/bugs/ and attach the problematic Ada code. Please also indicate how you compiled it, and which version of gcc you are using. Thanks, Duncan. > > Thanks, > ZY > > > On Sat, May 11, 2013 at 3:49 PM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi ZY, > > > On 11/05/13 20:37, Zhiyuan Ren wrote: > > Duncan, > > Thanks for getting back to me. I am not sure how to find the original > bitcode > (and relate...

Already done here : http://llvm.org/bugs/show_bug.cgi?id=12130 Thanks for your answers Best Regards Seb 2012/2/29 Duncan Sands <baldrick at free.fr> > Hi Seb, > > > If I remove datalayout definition, code is not optimized and work as >> expected. >> So my question is: >> >> What attribute/value/interpretation of data-layout would cause this type >> of bug? >> > > all kinds o...

...#39;float' %638 = trunc i40 %637 to float %633 = bitcast i8* %632 to float* %634 = bitcast float* %633 to i40* %635 = load i40* %634, align 1 %636 = shl i40 %635, 7 %637 = ashr i40 %636, 8 %638 = trunc i40 %637 to float Thanks, ZY On Sat, May 11, 2013 at 3:49 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi ZY, > > > On 11/05/13 20:37, Zhiyuan Ren wrote: > >> Duncan, >> >> Thanks for getting back to me. I am not sure how to find the original >> bitcode >> (and related Ada source code) that causes the truncate. This is the error &...

I sure that is.What could be other reasons for such error? Yakov On Mon, Nov 14, 2011 at 5:44 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 16:39, Yakov Malinkovich wrote: > >> It doesnt work it fails with assertation that cast is invalid .What >> could be done? >> > > Maybe src doesn't have Float type? > > Ciao, Duncan. > > > >> >> On 11/...

...is. Did you test it? Can you do: src->getType()->isFloatTy() What could be other reasons for such error? The only other possibility I can think of is that src was created using a different context. Ciao, Duncan. > Yakov > > > On Mon, Nov 14, 2011 at 5:44 PM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > On 14/11/11 16:39, Yakov Malinkovich wrote: > > It doesnt work it fails with assertation that cast is invalid .What > could be done? > > > Maybe src doesn't have Float type? > &g...

...eing generated. A lot of guessing here that's not getting us very far very fast. -eric On Nov 14, 2011, at 10:56 AM, Yakov Malinkovich wrote: > yes - i checked that the src->getType()->isFloatTy() is true > Yakov > > > On Mon, Nov 14, 2011 at 8:24 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 19:20, Yakov Malinkovich wrote: > I sure that is. > > Did you test it? Can you do: src->getType()->isFloatTy() > > > What could be other reasons for such error? > > The only other possibility I can think of is that src was cr...

...the information generated by GDB. For other programs, the process that wrote the first post worked perfectly, except for some. That this is the problem, for the compilation is the need to inform the -lm to link math libraries. It could be related to this -lm argument ? 2011/11/22 Duncan Sands <baldrick at free.fr> > Hi Rafael, > > > it is my program that dies. >> > > try running it under valgrind. > > Ciao, Duncan. > > >> Moreover, if I run ./program.native, it works. >> >> You are missing something? >> >> >> 2011/11/22...

OK, that's my fault. I'm running jitted code on linux x86. 2011/11/9 Duncan Sands <baldrick at free.fr> > Hi Semion, > > > In my case the LLVM is built with assertions, but this doesn't help. From >> your >> answer I conclude that thread-local globals are fully implemented in x86 >> JIT. >> > > you didn't mention the JIT. You didn...

Hi Duncan, I included original email in BUG description which described original issue with store being removed. BR Seb 2012/2/29 Duncan Sands <baldrick at free.fr> > Hi Seb, > > > Already done here : http://llvm.org/bugs/show_bug.**cgi?id=12130<http://llvm.org/bugs/show_bug.cgi?id=12130> >> > > that doesn't describe the original issue (second store removed), it is > talking > about a different issue tha...

...Constant *v = GV->getInitializer(); if (ConstantArray *CA = dyn_cast<ConstantArray>(v)) { StringRef portName(CA->getAsString()); That's some learning experience :-) Regards, Welson On Sat, Jan 28, 2012 at 6:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Welson, > > > Yes, it is a ConstantExpr! Thank you! >> >> Now trying to find a clue in ConstantExpr's functions to get that string >> :-) >> > > you can get the pointer operand by doing: getOperand(0) > The i'th index...

On 6 November 2012 14:52, Duncan Sands <baldrick at free.fr> wrote: > Hi Anitha, > > > On 06/11/12 10:19, Anitha Boyapati wrote: > >> Hi Duncan >> I am facing a build error about __builtin_iceil >> > > it's surely just that dragonegg doesn't have any support for this builtin. > ok. Just verif...