similar to: [LLVMdev] X86-64 / AMD64 support

That is, indeed, good news. This will make several developer's quite happy. I hope it doesn't take too long to complete. Thanks, Evan. Reid. On Mon, 2006-08-07 at 11:52 -0700, Evan Cheng wrote: > Hi all, > > Now that 64-bit Intel Mac OS X has been publicly announced, we can > finally say something about this topic. > > Yep, the initial support for 64-bit Intel has

"Finkel, Hal J. via llvm-dev" <llvm-dev at lists.llvm.org> writes: > And then there is also the argument for reusing Clang tooling, > which David Greene keeps making, though that idea does not seem to > get a lot of interest. > > > I disagree. There's been a lot of interest in modeling Flang's tooling > after Clang's

All, Here's an update on the Developer's Meeting. I've created a page for the meeting on the main web site at http://llvm.org/DevMtgMay2007.html. If you want to find out the latest, please visit that page. From here on out, I will be tracking the meeting's progress on that page. However, I'll still send out one of these update notes when there are significant developments.

On Wednesday 12 December 2007 06:16:25 pm Evan Cheng wrote: > Hold on, changing to movq will break it on Mac OS X. I'll need to > find a proper solution. > > Thanks, The proper solution is to fix the assembler, but in the meantime, the mr and rm variants at least should be changed to movq. They are broken on MacOS X right now anyway. From what you've said, one can't do

Hi Zoltan, The part that determines whether SIB byte is needed caused a lot of regressions last night (see Geryon-X86-64 etc.). I've reverted it for now. Please take a look. Thanks, Evan On May 4, 2009, at 3:49 PM, Evan Cheng wrote: > Committed as revision 70929. Thanks. > > Evan > > On May 3, 2009, at 8:29 PM, vargaz wrote: > >> >> Hi, >> >>

On Dec 12, 2007, at 7:42 PM, David A. Greene wrote: > On Wednesday 12 December 2007 06:16:25 pm Evan Cheng wrote: > >> Hold on, changing to movq will break it on Mac OS X. I'll need to >> find a proper solution. >> >> Thanks, > > The proper solution is to fix the assembler, but in the meantime, > the mr and rm variants at least should be changed to movq.

My nightly tester reports that it failed to bootstrap today: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./c-cppbuiltin.o differs ./real.o differs ./build/genautomata.o differs Ciao, Duncan.

Actually, movq is recognized by the assembler on Leopard. I've fixed this: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20071210/056334.html Please verify. Thanks. Evan On Dec 14, 2007, at 10:12 AM, Evan Cheng wrote: > > On Dec 12, 2007, at 7:42 PM, David A. Greene wrote: > >> On Wednesday 12 December 2007 06:16:25 pm Evan Cheng wrote: >>

Hi, If this looks ok, could somebody check it in ? thanks Zoltan Evan Cheng-2 wrote: > > Looks good. Thanks. > > Evan > > On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: > >> Hi, >> >> The attached patch contains the following changes: >> >> * X86InstrInfo.cpp: Synchronize a few places with the code

I think this is fixed. Please try again. Evan On Jun 17, 2008, at 8:39 AM, Duncan Sands wrote: > My nightly tester reports that it failed to bootstrap today: > > Comparing stages 2 and 3 > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > Bootstrap comparison failure! > ./c-cppbuiltin.o differs > ./real.o differs > ./build/genautomata.o

Hi, I can't reproduce these failures on my linux machine. The test machine seems to be running darwin. I suspect that the problem might be with RIP relative addressing, or with the encoding of R12/R13, but the code seems to handle the latter, since it checks for ESP/EBP which is the same as R12/R13. Zoltan On Tue, May 5, 2009 at 8:18 PM, Evan Cheng <evan.cheng at

Hi, It looks like the problem was with the RIP relative addressing. The original patch mistakenly removed the || DispForReloc part because I tough that the RIP relative addressing was done by the SIB encodings, but it is actually done by the shorter ones. The attached patch seems to work for me on linux and when simulating darwin by forcing some variables in X86TargetMachine.cpp to their darwin

On Thu, Feb 23, 2012 at 3:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > LLVM has traditionally assumed that all integer argument and return > types narrower than int are promoted to int on all architectures. > Nobody has actually noticed any issues with this before now, as far as > I know. The only reason that I noticed was that Python ctypes started misbehaving when

Committed as revision 70929. Thanks. Evan On May 3, 2009, at 8:29 PM, vargaz wrote: > > Hi, > > If this looks ok, could somebody check it in ? > > thanks > > Zoltan > > > Evan Cheng-2 wrote: >> >> Looks good. Thanks. >> >> Evan >> >> On May 1, 2009, at 8:40 AM, Zoltan Varga wrote: >>

Hi Meador, Have you filed a bugzilla report? What's the PR number? Evan On Feb 23, 2012, at 3:11 PM, Meador Inge wrote: > On Thu, Feb 23, 2012 at 3:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> LLVM has traditionally assumed that all integer argument and return >> types narrower than int are promoted to int on all architectures. >> Nobody has

Hello! I have been looking at the LLVM project for quite a bit but I was wondering if there are any implication of using the project in a commercial enviroment in terms of licensing restrictions and other related issues, are there other people that use LLVM in a commecial enviroment? Regards Jonas Gustavsson

I'll be there. I'd like to talk about a topic that's near and dear to my hear: "How to survive an attack by Oscar?". :-) Evan On Mar 31, 2007, at 3:11 PM, Reid Spencer wrote: > All, > > Here's an update on the Developer's Meeting. I've created a page > for the > meeting on the main web site at http://llvm.org/DevMtgMay2007.html. If > you

Hello to all: I know this list is generally Linux-only, but I figured I'd try to gain wisdom from those with hard-core Windows needs, too. I was recently pricing out a high-end desktop system for a user who will doing a lot of CAD, Matlab, SolidWorks, and other apps that will utilize a lot of number crunching and video. The quote for the desktop (64-bit Vista is likely), which included 12

On Friday 14 December 2007 13:55, Evan Cheng wrote: > Actually, movq is recognized by the assembler on Leopard. I've fixed > this: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- > Mon-20071210/056334.html > > Please verify. Thanks. The patch is similar to what I did. I'll have to create an llvm testcase to verify it as this is a Fortran code. It would also

Things are still broken. Unfortunately llvm test suite does not contain enough vector code to fully test this. Can you revert the patch first? Evan On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members > and passes results back via