Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] UnitTests/2003-05-31-CastToBool.c"
2004 Jul 07
0
[LLVMdev] UnitTests/2003-05-31-CastToBool.c
Volodya,
This program is in error. Either the format specifier needs to be %lld
or the argument value X needs to be casted to type long. This will
compile fine but it probably won't work at runtime because printf is
expecting a long, not a long long. I think your backend producing "wrong
results" is actually correct :)
Most modern C/C++ compilers will detect this for you at
2004 Jul 07
1
[LLVMdev] UnitTests/2003-05-31-CastToBool.c
Reid Spencer wrote:
> This program is in error. Either the format specifier needs to be %lld
> or the argument value X needs to be casted to type long. This will
> compile fine but it probably won't work at runtime because printf is
> expecting a long, not a long long. I think your backend producing "wrong
> results" is actually correct :)
Yea, that's what
2004 Jul 08
2
[LLVMdev] UnitTests/2002-05-19-DivTest.c
The above-mentioned test contains this:
long B53 = - (1LL << 53);
strictly speaking, this is not correct code. The C standard says about shift:
"if the value of the first operator is ... or greater than ... the width of
the promoted left operand, the behaviour is underfined".
Thouhts?
- Volodya
2004 Jul 08
3
[LLVMdev] UnitTests/2002-05-19-DivTest.c
Vladimir Prus wrote:
> Vladimir Prus wrote:
> > The above-mentioned test contains this:
> >
> > long B53 = - (1LL << 53);
> >
> > strictly speaking, this is not correct code. The C standard says about
> > shift: "if the value of the first operator is ... or greater than ... the
> > width of the promoted left operand, the behaviour is
2004 Jul 08
0
[LLVMdev] UnitTests/2002-05-19-DivTest.c
On Thu, 2004-07-08 at 07:07, Vladimir Prus wrote:
> Vladimir Prus wrote:
> > Vladimir Prus wrote:
> > > The above-mentioned test contains this:
> > >
> > > long B53 = - (1LL << 53);
> > >
> > > strictly speaking, this is not correct code. The C standard says about
> > > shift: "if the value of the first operator is ... or
2004 Jul 08
0
[LLVMdev] UnitTests/2002-05-19-DivTest.c
Vladimir Prus wrote:
> The above-mentioned test contains this:
>
> long B53 = - (1LL << 53);
>
> strictly speaking, this is not correct code. The C standard says about
> shift: "if the value of the first operator is ... or greater than ... the
> width of the promoted left operand, the behaviour is underfined".
Forget this, I've missed the 'LL'
2004 Jul 08
1
[LLVMdev] UnitTests/2002-05-19-DivTest.c
Alkis Evlogimenos wrote:
> > But the test still has a problem ;-)
> >
> > printf("%ld\n", Arg / (1LL << 4));
> >
> > Again, the passed value is long long, and format specifier is '%ld'. What
> > about the attached patch?
>
> I think testL has another problem. It takes a long argument which in C I
> think is a 4-byte int,
2004 Jun 09
1
[LLVMdev] Testing backend
Reid Spencer wrote:
> Vladimir,
>
> The makefile for the feature tests is in the directory above. Simply:
>
> cd ~/llvm/test
> make Feature.t
>
> This works for the regression tests to:
>
> make Regression.t
>
> The tests are run QMTest which just "knows" what to do with the test
> file. In many cases there is a RUN: line which instructs the
2004 Jul 07
2
[LLVMdev] Duplicate assignment in LLVM?
Hello,
when I'm compiling
test/Programs/SingleSource/UnitTests/2003-05-26-Shorts.c
I get LLVM assembler which looks like:
int %main(int %argc, sbyte** %argv) {
entry:
call void %__main( )
%tmp.11 = call ulong %getL( ) ; <ulong> [#uses=16]
%tmp.3 = cast ulong %tmp.11 to long ; <long> [#uses=
%tmp.5 = cast ulong %tmp.11 to
2010 Jun 13
2
wrappers
Hi,
I've sent one of these before, but i wasn't subscribed, and i'm unsure if it
went out. I'm subscribed now and i've written another (i believe) nifty wrapper
for oggz-tools.
oggz-comments - allows a user to pass the plain text file with each tag on their
own line
theoracomment - works like 'vorbiscomment' from VorbisTools package, but sets
comments for the
2008 May 24
0
[LLVMdev] A quick update on FreeBSD support
On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote:
> All,
>
> So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD
> and aside for ia64, things look pretty good for a first try. There
> are 2 unexpected failures for PowerPC, which appear to be caused by
> uninitialized memory. I'm still working on a fix for that (need to
> brush up on my C++
2008 May 24
2
[LLVMdev] A quick update on FreeBSD support
All,
So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD
and aside for ia64, things look pretty good for a first try. There
are 2 unexpected failures for PowerPC, which appear to be caused by
uninitialized memory. I'm still working on a fix for that (need to
brush up on my C++ skills).
[sidenote: In FreeBSD -current, the memory allocator initializes
memory with 0xa5
2004 Jul 07
2
[LLVMdev] Duplicate assignment in LLVM?
Reid Spencer wrote:
> Volodya,
>
> I think you may need to update your CFE and rebuild. I compiled the test
> using my local build and I didn't get the results you see below. I'm
> also very surprised to see this output. The first %tmp.11 should have
> been %tmp.1 .. not sure how it got corrupted. In any event, the
> attachment is obviously generated by code that runs
2005 Feb 16
4
[LLVMdev] Install fails due to missing 'pax' tool
Hello,
I've just tries make && make install on a fresh CVS tree, and get:
llvm[0]: Installing include files
/bin/sh: line 1: pax: command not found
Two questions.
1. Why install process requires some nonstandard tool? Is it possible to get
away without it.
2. autoconf/configure.ac has this:
AC_PATH_PROG(PAX, [pax], [pax])
but Makefile.rules uses plain 'pax',
2004 Jul 07
0
[LLVMdev] Duplicate assignment in LLVM?
Volodya,
I think you may need to update your CFE and rebuild. I compiled the test
using my local build and I didn't get the results you see below. I'm
also very surprised to see this output. The first %tmp.11 should have
been %tmp.1 .. not sure how it got corrupted. In any event, the
attachment is obviously generated by code that runs quite differently
because the virtual register names
2004 Jun 09
3
[LLVMdev] Testing backend
I've finally managed to bring my backend to a minimally working form. I can
compile three small examples with arithmetic operations, branches and phi
operations. However, there surely is a lot of omissions and bugs.
How do I test a backend. For obvious reasons, I'd prefer a number of really
small tests, to make debugging easier. I see some number of such small tests
in
2004 Aug 29
6
[LLVMdev] lib/System Unleashed - Need Your Help!
Folks,
With some MacOS help from Nate, I've begun the conversion of LLVM to use
lib/System, the operating system independence layer. Currently, the
library has implementations for three abstractions: Path, Program, and
Signals. These provide some basic utilities for manipulating file system
paths, finding and executing programs, and cleaning up after Signals.
The implementations should work
2020 Jul 08
8
Redis in place of astdb
Hi,
Does anyone know of any projects that would allow you to use Redis in place
of AstDB? By in place of I don't mean for what Asterisk needs but to store
values. For instance for CNAM currently we need to use an AGI to connect to
redis to pull CNAM. So in place of:
Set(CALLERID(name)=${DB(CNAM/${CALLERID(num)})}
it would be done with redis for example:
2004 Jun 21
2
[LLVMdev] More on backend testing
Ok, I'm slowly making my backend understand stuff in
test/Programs/SingleSource/UnitTests. I can convert the first test to
assembler, compile it and run.
The only thing I don't see if the expected outputs from the tests -- so that I
don't need to look at each test and figure out what it should output. Is it
true such expected outputs are not available? I not, I'll probably do
2004 Jun 24
2
[LLVMdev] Instruction ctor: insertBefore
Hi,
the insertBefore parameter, present in all constructors, is declared like
this:
Instruction *InsertBefore=0
any reason there's no "const" before "Instruction"
?
- Volodya