Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] X86-64 target"
2006 Jan 20
2
[LLVMdev] X86-64 target
Chris Lattner wrote:
> On Thu, 19 Jan 2006, Morten Ofstad wrote:
>> Hello, I'm currently porting our software to the x86-64 (windows)
>> platform. I've already done most of the work involved in getting LLVM
>> itself to run on 64-bit windows, but of course that doesn't help much
>> as long as the emitted code is 32-bit...
>
> My understanding is
2006 Jan 19
0
[LLVMdev] X86-64 target
On Thu, 19 Jan 2006, Morten Ofstad wrote:
> Hello, I'm currently porting our software to the x86-64 (windows)
> platform. I've already done most of the work involved in getting LLVM
> itself to run on 64-bit windows, but of course that doesn't help much as
> long as the emitted code is 32-bit...
My understanding is that LLVM builds fine on AMD64 machines running Linux,
2006 Jan 26
4
[LLVMdev] VS2005 patch
OK, fixed the problem with the intrin.h header that doesn't exist in previous versions of VS...
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JIT.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060126/7e55b0d0/attachment.ksh>
2006 Jan 26
0
[LLVMdev] VS2005 patch
Hi Morten,
If you can make the VS2005 project files availiable on the net then I can
test them as I have VS2005 now, so then with Chris'es okay then they could
be distributed with LLVM.
Thanks,
Aaron
----- Original Message -----
From: "Morten Ofstad" <morten at hue.no>
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Sent: Thursday, January 26,
2006 Jan 26
2
[LLVMdev] VS2005 patch
The project files need frequent updating. I cannot maintain VS2005
project files, so while they could be distributed with LLVM, they will
become broken fast. Also, VS2003 and VS2005 project and solution files
cannot coexist in the same directories, further complicating matters.
Aaron Gray wrote:
> Hi Morten,
>
> If you can make the VS2005 project files availiable on the net then I
2006 Jan 27
2
[LLVMdev] VS2005 patch
The new property manager doesn't exist in VS2003 either. Don't know
where to add it.
Chris Lattner wrote:
> On Fri, 27 Jan 2006, Jeff Cohen wrote:
>
>> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it
>> in VS2003.
>
>
> It shouldn't hurt to define it though, even if VC2003 where it does
> nothing. Right?
>
> -Chris
>
2006 Jan 27
2
[LLVMdev] VS2005 patch
_CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in
VS2003.
Morten Ofstad wrote:
> Jeff Cohen wrote:
>
>> The project files need frequent updating. I cannot maintain VS2005
>> project files, so while they could be distributed with LLVM, they
>> will become broken fast. Also, VS2003 and VS2005 project and
>> solution files cannot coexist in
2006 Jan 27
0
[LLVMdev] VS2005 patch
On Fri, 27 Jan 2006, Jeff Cohen wrote:
> The new property manager doesn't exist in VS2003 either. Don't know where to
> add it.
Isn't there a place to add -D_CRT_SECURE_NO_DEPRECATE for the
preprocessor? Isn't this all we are talking about, or am I missing
something?
-Chris
>> On Fri, 27 Jan 2006, Jeff Cohen wrote:
>>
>>> _CRT_SECURE_NO_DEPRECATE
2006 Jan 27
0
[LLVMdev] VS2005 patch
On Fri, 27 Jan 2006, Jeff Cohen wrote:
> _CRT_SECURE_NO_DEPRECATE is new for VS2005. Nothing I can do with it in
> VS2003.
It shouldn't hurt to define it though, even if VC2003 where it does
nothing. Right?
-Chris
> Morten Ofstad wrote:
>
>> Jeff Cohen wrote:
>>
>>> The project files need frequent updating. I cannot maintain VS2005
>>>
2007 Mar 12
2
[LLVMdev] LLVM with Microsoft Visual Studio
Jeff Cohen wrote:
> The recent issues concern the head revision, post 1.9. As no one has
> ever submitted patches to fix 2005 problems with the 1.9 release, it is
> safe to say they still exist.
For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails
in the archives about the issues I ran into. I also submitted patches
2006 Jan 27
0
[LLVMdev] VS2005 patch
Jeff Cohen wrote:
> The project files need frequent updating. I cannot maintain VS2005
> project files, so while they could be distributed with LLVM, they will
> become broken fast. Also, VS2003 and VS2005 project and solution files
> cannot coexist in the same directories, further complicating matters.
The VS2003 project files convert without problems -- you might want to add in
2007 Mar 12
0
[LLVMdev] LLVM with Microsoft Visual Studio
Morten Ofstad wrote:
> Jeff Cohen wrote:
>
>> The recent issues concern the head revision, post 1.9. As no one has
>> ever submitted patches to fix 2005 problems with the 1.9 release, it is
>> safe to say they still exist.
>>
>
> For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails
2006 Jan 27
3
[LLVMdev] VS2005 patch
I don't know. If that's all it was, why is there a special new property
manager to set it? Morten will need to explain what to do in VS2003 to
make VS2005 happy.
Chris Lattner wrote:
> On Fri, 27 Jan 2006, Jeff Cohen wrote:
>
>> The new property manager doesn't exist in VS2003 either. Don't know
>> where to add it.
>
>
> Isn't there a place to
2004 Dec 13
3
[LLVMdev] misc. patches
Jeff Cohen wrote:
> VS has a 64-bit portability mode, where it will complain when it sees
> non-portable code. I haven't tried it yet on LLVM, but in my experience
> it will generate a *lot* of warnings. Every time a size_t or ptrdiff_t
> is assigned to an int or even a long it will complain (Microsoft defines
> long as 32-bits, even in win64). On the other hand, gcc
2004 Oct 12
3
[LLVMdev] set_intersect and Visual C compiler
Hello,
This is my first post on this mailing list, so bear with me... My name
is Morten Ofstad and I work for Hue AS (www.hue.no), a company that
makes 3D Visualization software. We are looking into using LLVM for JIT
compiling shader programs, to replace our own (slow) VM. A requirement
for this is that we can compile LLVM in VS7.1, so I contacted Paolo
Invernizzi to find the status of his
2007 Mar 14
1
[LLVMdev] LLVM with Microsoft Visual Studio
Jeff Cohen wrote:
> Morten Ofstad wrote:
>> Jeff Cohen wrote:
>>
>>> The recent issues concern the head revision, post 1.9. As no one has
>>> ever submitted patches to fix 2005 problems with the 1.9 release, it is
>>> safe to say they still exist.
>>>
>>
>> For the 1.5 release I submitted patches that made everything compile
2004 Nov 08
2
[LLVMdev] Small patch for visual studio project files
We could also do the "cvs admin -kb" thing on all the project files so
that cvs won't do keyword expansion or line ending conversion.
Thoughts?
Reid.
On Mon, 2004-11-08 at 07:36, Jeff Cohen wrote:
> You have to use a version of CVS that's specifically built for Windows.
> You can find prebuilt Windows binaries at cvshome.org. The cygwin
> supplied CVS no doubt
2004 Oct 18
3
[LLVMdev] Fix for non-standard variable length array
Paolo Invernizzi wrote:
> I submitted a patch with a std::vector, but was commited as alloca ;-P
for the other problem?
I made a nice clean patch using std::vector in LiveVariables.cpp now,
which I include with this message... By the way, where do you submit the
patches if not to the mailing list? I thought I should post here so
Paolo and others interested in the porting effort can apply
2004 Nov 08
3
[LLVMdev] Small patch for visual studio project files
Jeff Cohen wrote:
> Are you sure your CVS is configured correctly? On Windows, CVS
> automatically converts between LF and CR/LF line endings. I sent a
> patch to remove all CRs from the repository because when I checked out
> the files on Windows, every line had two CRs and a single LF. When VS
> saved a modified project file, the extra CR went away, causing every
> line to
2007 Apr 13
4
[LLVMdev] "Name that compiler"
me22 wrote:
> One of the nicer project names I've seen recently is Alexandria, for a
> book database program ( http://alexandria.rubyforge.org/ ). It
> unfortunately fails the searchability test, but does brilliantly at
> reminding you what it is.
Along these lines, is there any mythical characters or historical persons which are associated with translation (which
is the primary