similar to: [LLVMdev] Visual Studio 2012 cl.exe ICE while building LLVM for x64 (in TableGen) at -O2

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

> 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

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.

Hi, Just wanted to point this out here, in case it hasn't been run into yet. I've filed a bug with MS already, but it might be a warning to anyone thinking about uninstalling their older versions. Workaround was to build lib/TableGen (well, all of LLVM really due to a case of laziness) at /O1 and utils/TableGen at /Od. Turning inline expansion to 0 apparently works as well.

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

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

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

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,

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

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

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

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

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 

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

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----- > 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

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 never does this. The normal ISel pass handles this situation correctly so a temporary local change to disable FastISel for linux / NaCl targets is working for me right now. I'm not very

> -----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