similar to: [LLVMdev] Broken PLT on ARM from R183966

Cool, I'll file a bug tomorrow at work and add you to the CC list. Thanks! Gordon Keiser Software Development Engineer Arxan Technologies gkeiser at arxan.com www.arxan.com  Protecting the App EconomyT  > -----Original Message----- > From: Eric Christopher [mailto:echristo at gmail.com] > Sent: Tuesday, August 20, 2013 9:47 PM > To: Gordon Keiser > Cc: llvmdev at

Hi Anton and JF, Thanks for your review. After reading the source code more carefully, I have come up with a different way fix this issue. We can simply resolve this issue by adding ARMII::MO_PLT flags with MachineInstrBuilder in FastISel pass (without failing back to DAG lowering). The new patch is attached, and the test case is not changed. Sorry for your inconvenience. Please have a

LGTM On Wed, Aug 21, 2013 at 1:51 PM, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > Hi, > > I have created a workaround to deal with the PIC function call. With this > patch, the FastISel will switch back to DAG lowering mechanism if (1) there > is a function call in the basic block and (2) the relocation model is PIC. > Please have a look. Hoping the patch will

I'm not very familiar with relocations but your fix looks the same as ARMTargetLowering::LowerCall, so from that perspective it lgtm (but I may be missing something). On Wed, Aug 21, 2013 at 8:04 AM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > Hi Anton and JF, > > Thanks for your review. After reading the source code more carefully, I > have come up with a

lgtm On Wed, Aug 21, 2013 at 3:18 AM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > LGTM > > On Wed, Aug 21, 2013 at 1:51 PM, Logan Chien <tzuhsiang.chien at gmail.com> > wrote: > > Hi, > > > > I have created a workaround to deal with the PIC function call. With > this > > patch, the FastISel will switch back to DAG lowering

Filing a bug would be a good start, go ahead and cc me and jfb at google.com. Thanks! -eric On Tue, Aug 20, 2013 at 6:10 PM, Gordon Keiser <gkeiser at arxan.com> wrote: > For ARM targets on linux, revision 183966 made Fast ISel default. > Unfortunately, Fast ISel is broken in terms of applying the ARMII::MO_PLT > flags to calls in PIC mode (at least when emitting assembly); it

That change seems to fix things here. Thanks! -Gordon From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of JF Bastien Sent: Wednesday, August 21, 2013 12:53 PM To: Logan Chien Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Broken PLT on ARM from R183966 I'm not very familiar with relocations but your fix looks the same as

Hi, I have created a workaround to deal with the PIC function call. With this patch, the FastISel will switch back to DAG lowering mechanism if (1) there is a function call in the basic block and (2) the relocation model is PIC. Please have a look. Hoping the patch will help. Sincerely, Logan On Wed, Aug 21, 2013 at 10:17 AM, Gordon Keiser <gkeiser at arxan.com> wrote: > Cool,

On 04/12/2012 06:29, Michael Spencer wrote: > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: >> As an update to this: >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 >> >> Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release.

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft

As an update to this: http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's nice to know. The workaround involves marking a single function with attribute((noinline)) and is

Hi, I was wondering if there was any way to return an i1 type (or something that llvm would accept as one, internally) from a C function compiled with llvm-gcc. My thought from searching around was that it might take rewriting (or at least writing a wrapper to %trunc the result) in assembly. I'm fairly new to LLVM so I may have missed something important. Any thoughts ? Thanks much,

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Óscar Fuentes > > Vladimir Pouzanov <farcaller at gmail.com> writes: > > > On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > >> Llvm typically doesn't build with RTTI enabled. Perhaps that's what

Hi there, I'm using clang to cross compile for cortex-m3. I eventually managed to do so with clang++ -ccc-gcc-name arm-none-linux-gnueabi-g++ -ccc-host-triple thumbv7m-none-gnueabi source.cpp -c -mcpu=cortex-m3 I would like to understand what -ccc-gcc-name does exactly and how can I get ride of it? >From what I understand, it's needed by the driver in order to find the binutils for

Hi Gordon, Clang can do it if you include <stdbool.h> .  I found this out when writing a LibC wrapper library for LLVM Bitcode. --Sam >________________________________ >From: Gordon Keiser <gkeiser at arxan.com> >To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> >Sent: Wednesday, September 21, 2011 9:55 PM >Subject: [LLVMdev] Returning i1 type

On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: > As an update to this: > http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 > > Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release. I know not a lot of people are building with VS, but it's

Gordon Keiser <gkeiser at arxan.com> writes: > There is (was?) a CMake variable for this if you're going that route. > Setting LLVM_REQUIRES_RTTI=1 enabled an RTTI build that I haven't had > issues with. I don't know what the ./configure equivalent is, sorry. LLVM_REQUIRES_RTTI is an internal variable. It works as you say, but there is no guarantee about it. Adding a

Making a symlink to clang in the same directory as the GCC / binutils (I'll call it $ARM_BIN) called arm-none-linux-gnueabi-clang (and one with clang++ too) and another link in the $ARM_BIN/../lib directory to clang directory located under clang's lib (for includes) should be enough. Gordon Keiser Software Development Engineer Arxan Technologies gkeiser at arxan.com www.arxan.com 

> -----Original Message----- > On Behalf Of James Courtier-Dutton > To: John Criswell > > On 7 May 2012 16:31, John Criswell <criswell at illinois.edu> wrote: > > On 5/7/12 5:47 AM, James Courtier-Dutton wrote: > >> > >> Hi, > >> > >> I am writing a decompiler. I was wondering if some of LLVM could be > >> used for a

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Philip Reames > Sent: Monday, December 03, 2012 9:51 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Minimum Python Version > > > > On 12/03/2012 01:53 PM, Joshua Cranmer wrote: > > I don't know any hard examples off the top