search for: csanchezdl

...7 AM, Carlos Sánchez de La Lama wrote: > Hi again, > > I can confirm r169783 fixes the problem. My testbench segfaulted in > r169782 but works after your commit. > > We can close the issue. > > Thanks, > > Carlos > > > 2012/12/11 Carlos Sánchez de La Lama <csanchezdll at gmail.com > <mailto:csanchezdll at gmail.com>> > > Hi Anshu, > > I got a testbench which fails (and segfaults) consistently with an > environment (gcc + os) conveniently preserved in a virtual > machine. I will confirm that it is gone there and rep...

...Carlos Sánchez de La Lama wrote: > > Hi again, > > I can confirm r169783 fixes the problem. My testbench segfaulted in > r169782 but works after your commit. > > We can close the issue. > > Thanks, > > Carlos > > > 2012/12/11 Carlos Sánchez de La Lama <csanchezdll at gmail.com> > >> Hi Anshu, >> >> I got a testbench which fails (and segfaults) consistently with an >> environment (gcc + os) conveniently preserved in a virtual machine. I will >> confirm that it is gone there and report. >> >> Thanks for the fix...

Hi again, I can confirm r169783 fixes the problem. My testbench segfaulted in r169782 but works after your commit. We can close the issue. Thanks, Carlos 2012/12/11 Carlos Sánchez de La Lama <csanchezdll at gmail.com> > Hi Anshu, > > I got a testbench which fails (and segfaults) consistently with an > environment (gcc + os) conveniently preserved in a virtual machine. I will > confirm that it is gone there and report. > > Thanks for the fix :) > > > Carlos > &g...

Hi Anshu, I got a testbench which fails (and segfaults) consistently with an environment (gcc + os) conveniently preserved in a virtual machine. I will confirm that it is gone there and report. Thanks for the fix :) Carlos 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > Carlos, > > I committed a fix in r169783. Thanks for catching this. > > However, I could

...doing it are equally valid, but the choice of which way to do it is a implementation decision. I don't think it would be that difficult to lower global variables to function arguments given SPIR representation. Micah > -----Original Message----- > From: Carlos Sánchez de La Lama [mailto:csanchezdll at gmail.com] > Sent: Friday, September 28, 2012 12:34 AM > To: James Molloy > Cc: Pekka Jääskeläinen; Ouriel, Boaz; pocl-devel at lists.sourceforge.net; > Villmow, Micah; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [pocl-devel] [cfe-dev] [LLVMdev] SPIR provisional...

...he choice of which way to do it is a implementation > decision. I don't think it would be that difficult to lower global > variables to function arguments given SPIR representation. > > Micah > > > -----Original Message----- > > From: Carlos Sánchez de La Lama [mailto:csanchezdll at gmail.com] > > Sent: Friday, September 28, 2012 12:34 AM > > To: James Molloy > > Cc: Pekka Jääskeläinen; Ouriel, Boaz; pocl-devel at lists.sourceforge.net; > > Villmow, Micah; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > Subject: Re: [pocl-devel] [cfe-dev] [...

Hi guys, > So it is valid SPIR, as the specification stands, to manipulate __local > variables as Constants in a way that is extremely difficult to undo. That > is, in order to transform SPIR to code that can run on a CPU, the > GlobalVariable (which is a subclass of Constant) must be replaced with a > dynamically calculated Value (which is not a subclass of constant). What about

Indeed; I agree it is not an implementation detail as potentially valid SPIR could be almost untranslatable to valid code running on a target without dedicated workgroup-local memory. Micah: the problem can be distilled down to: __local variables in SPIR are represented as Constants (GlobalVariable : public Constant), but they are not in fact constant, for a device with no workgroup-local memory.

Hi, > Problem solved. I was building llvm in a separate llvm-build directory. I > built it within the llvm-src directory (which kept all the llvm .so and my > pass' .so in the llvm-src/Release+Asserts/lib directory) to solve the > problem. I do not fully understand what you mean, there should be no difference on building out of source AFAIK. > Can anyone tell me what's

Hi all, I am having some problems when loading plugins using opt -load=xxx, due to missing symbols. I am using a statically linked version of LLVM under Mac OS X 10.7, and I have pinpointed the problems to two separate causes: 1) opt should not be stripped during installation. When installing Release versions, opt is stripped, removing symbols which might get needed by the plugins. In my case,

Hi all, I am using the fast register allocator on a partially allocated machine function. I have noticed reserved registers (i.e. liveins) are marked as free after first use (in usePhysReg(..) method). This seems an error to me as a livein might be still used later in the basic block. As I understand this should check for isKill() before marking it as free, but I see it even *sets* the kill

Portable OpenCL (pocl) v0.6 released ------------------------------------ Portable OpenCL aims to be an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 standard. In addition to producing an easily portable open source OpenCL implementation, another major goal of the project is improving performance portability of OpenCL programs with compiler optimizations, reducing the

Hi all, I have found what I think it is a bug in DFAPacketizer::ReadTable. When finding NextStateInTable to cache all transitions belonging to a state into CachedTable, ReadTable does not check bounds: unsigned ThisState = DFAStateEntryTable[state]; | unsigned NextStateInTable = DFAStateEntryTable[state+1]; which makes NextStateInTable get a random value when state == <last state in

Hi Anshu, no, I did not fill a bug report. It is not so easy to make the code fail noticeably; during Hexagon CodeGen tests it happens silently and tests pass. I am working on another VLIW backend which uses DFAPacketizer and compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug gets hidden again (it still happens, but values after DFAStateEntryTable in memory are such that