similar to: [LLVMdev] error in /lib/CodeGen/MachOWriter.cpp: line 200

Hi! I updated LLVM from CVS today and run into the following error: /lib/CodeGen/MachOWriter.cpp: line 200: no match for function max(unsigned_int_32, unsigned int) the line is Sec.align = std::max(Sec.align, Align); where Sec.align is of type "unsigned_int_32" and Align is of "unsigned int". I use gcc-3.4.4 under cygwin. Сasting of the first parameter to simple unsigned

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

On Oct 29, 2012, at 3:28 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Arnold, > > I wanted to hear from Jacob is the original patch in question still needed, > since our use of this field could surpass const extenders and could > potentially include MO_Register. > > Jacob, > > Can you please comment? Thanks. I don't really have

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

On Sep 17, 2012, at 12:01 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > On 17/09/12 05:58, Daniel Berlin wrote: >> On Sat, Sep 15, 2012 at 9:03 AM, Nadav Rotem <nrotem at apple.com> wrote: >>> >>> >>> On Sep 15, 2012, at 14:24, Nuno Lopes <nunoplopes at sapo.pt> wrote: >>> >>>> Wait, doesn't this

Begin forwarded message: > > Increase default setting of tail-merge-threshold to > 150, based on llvm-test measurements. > > static cl::opt<unsigned> > TailMergeThreshold("tail-merge-threshold", > cl::desc("Max number of predecessors to consider tail > merging"), > - cl::init(100), cl::Hidden); > + cl::init(150),

MSVC complains of truncating a double to a float. Let's just give it a float. -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -------------- next part

On Jul 26, 2012, at 12:57 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> +<p>This function returns the same values as the libm <tt>floor</tt> functions >> + would, and handles error conditions in the same way.</p> > > Why the intrinsic then? So that it's possible to access the ISD::FFLOOR SDNode without having to enable a

Hello! The if-converter tries to match 'Simple' patterns looking like this: // Simple (split, no rejoin): // EBB // | \_ // | | // | TBB---> exit // | // FBB The IfConverter::ValidSimple method (lib/CodeGen/IfConversion.cpp:461) checks if TBB matches this pattern. It basically does this by simply checking if AnalyseBranch fails on

On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote: > unfortunately, race detectors like helgrind don't like this kind of > thing, and report it as a race. Last time I asked about it I was > told that fixing it would be too hard/expensive. I know, and it's somewhat unfortunate. However, this path is extremely hot in LLC, and was significantly contended using only two threads. I

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan >

Hello, Chuck. You wrote Tuesday, May 16, 2006, 6:03:14 PM: C> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: BFD C> 2.16.91 C> 20050610 assertion fail C> /netrel/src/binutils-20050610-1/bfd/cofflink.c:1926 C> make[2]: *** This is a bug in binutils also seen in mingw32 build. :( I've sent bug report to binutils bugzilla this weekend. Hope, this will be

Hello, Reid. You wrote Tuesday, May 16, 2006, 11:13:19 PM: RS> What does the assertion say? The same text, as in the original e-mail: <=cut=> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: BFD 2.16.91 20050610 assertion fail /netrel/src/binutils-20050610-1/bfd/cofflink.c:1926 <=cut=> This assertions is in big function named: bfd_boolean

Hello, Reid. You wrote Friday, January 21, 2005, 11:14:41 PM: RS> FYI, work progresses on the Win32 native port which you might also find RS> interesting. It might even get done before the cygwin stuff. Jeff Cohen RS> is working on that. Perhaps he can indicate the status of that effort. There is too much work to do native Win32 builds. I've tried to get llvm compiled on mingw32

Arnold, I wanted to hear from Jacob is the original patch in question still needed, since our use of this field could surpass const extenders and could potentially include MO_Register. Jacob, Can you please comment? Thanks. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Arnold

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

Hello, Ashwin. You wrote Wednesday, May 24, 2006, 11:25:11 AM: AC> "Pass::getClassPassInfo<PassClass>() "Pass class not AC> registered!"" failed: file AC> "/cygdrive/c/llvm/llvm/include/llvm/PassAnalysisSupport.h", line 76 AC> Aborted Same for me. AC> Wihtout the -march specified (using native x86 assembly) it does AC> convert it into

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem