Displaying 8 results from an estimated 8 matches for "requares".
Did you mean:
requare
2004 Jul 01
1
[LLVMdev] Add assert in llvm::StroreInst::init and llvm::LoadInst::init
I'm make silly error (swap arguments in llvm::StroreInst constructor call:
llvm::Value* var = genExpr(bb,*varExpr,false);
llvm::Value* val = genExpr(bb,*valExpr,true );
llvm::StoreInst* lStore = new llvm::StoreInst(var,val,bb);
instead
assert(var && var->getType()->getTypeID()==llvm::Type::PointerTyID && "var
side isn't pointer type");
llvm::StoreInst*
2008 Nov 22
2
This diff needs fixing.
...kay?
It's either one or the other, for example why is MS Office 2007 rated platinum for? You need native dll's and not wines versions to run it, yet in games that use secu-rom or other copy protections that are not implemented in WINE the highest it can achieve is a gold rating, because it requares a fixed exe both need extra files therefore both should be rated GOLD.
It's almost has if the rating system is controlled by favoritism.
2004 Nov 08
2
[LLVMdev] Dejagnu Support Added (+ problems with build LLVM at FreeBSD)
> I'm asking for people (especially those running nightly testers) to give
> Dejagnu a try.
I will do.
But last 2 days (after
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020279.html )
LLVM broken at FreeBSD:
In file included from Path.cpp:27:
platform/Path.cpp:26: error: no `bool llvm::sys::Path::isvalid() const'
member function declared in class
2005 Feb 04
0
[LLVMdev] question about compile path [patch adding .cc support]
On Thu, 3 Feb 2005, Vladimir Merzliakov wrote:
>> Doing it this way
>> allows you to re-use the LLVM build system, as opposed to building your
>> own set of Makefiles.
> I have pre-LLVM projects in C++ with often used at Unix C++ source file
> extention .cc
> I modify LLVM build system (original LLVM Makefile.rules already partly
> support .cc extention,
> for
2005 Feb 03
3
[LLVMdev] question about compile path [patch adding .cc support]
> Doing it this way
> allows you to re-use the LLVM build system, as opposed to building your
> own set of Makefiles.
I have pre-LLVM projects in C++ with often used at Unix C++ source file
extention .cc
I modify LLVM build system (original LLVM Makefile.rules already partly
support .cc extention,
for example, in Sources and FakeSources make vars setup code).
Is attached patch
2005 Feb 05
3
[LLVMdev] Improving Makefile.rules header install rules [PATCH]
>> Is attached patch acceptable?
>
> Looks great, applied, thanks!
> http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050131/023931.html
Thanks!
>> Also I have in Makefile.rules (but not include in patch) some
>> modification for simplify used common Makefile.rules in LLVM projects and
>> non-LLVM project (guarding some LLVM specific parts by ifdef
2005 Feb 15
0
[LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
On Mon, 2005-02-14 at 20:53, Chris Lattner wrote:
> On Mon, 14 Feb 2005, Reid Spencer wrote:
>
> > Personally, I don't think LLVM projects should need much in the way of
> > autoconf stuff. They certainly don't need to replicate things like
> > install-sh and mkinstalldirs. I'd vote for taking these out of the
> > projects rather than making the makefiles
2005 Feb 15
3
[LLVMdev] Removing $(LLVM_SRC_ROOT)/autoconf dependensies in Stacker, llvm-java [PATCH]
On Mon, 14 Feb 2005, Reid Spencer wrote:
> Personally, I don't think LLVM projects should need much in the way of
> autoconf stuff. They certainly don't need to replicate things like
> install-sh and mkinstalldirs. I'd vote for taking these out of the
> projects rather than making the makefiles deal with them. I think in
> most cases these are just historical artifacts