similar to: [LLVMdev] LLVM and Cygwin

Hi Brian, On 29/07/13 23:42, Brian Herman wrote: > I got the following error while compiling llvm and clang under cygwin. > > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): > undefined reference to `__register_frame' I register_frame is used to enable the debugger (gdb) to

I get this when I type: brianherman at windows-8-[REDACTED] ~ $ nm libgcc_eh.a | grep register_frame nm: 'libgcc_eh.a': No such file brianherman at windows-8-[REDACTED] ~ $ nm libgcc_eh.a | grep register_fram nm: 'libgcc_eh.a': No such file brianherman at windows-8-[REDACTED] ~ $ On Tue, Jul 30, 2013 at 7:51 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi

brianherman at windows-8-doesn't rock /lib/gcc/i686-pc-cygwin/4.7.3 $ nm libgcc_eh.a | grep register_frame 000011b0 T ___deregister_frame 000011a0 T ___deregister_frame_info 000010d0 T ___deregister_frame_info_bases 00000fe0 T ___register_frame 00000fb0 T ___register_frame_info 00000f40 T ___register_frame_info_bases 00001070 T ___register_frame_info_table 00001010 T

> $ nm libgcc_eh.a | grep register_frame > nm: 'libgcc_eh.a': No such file I think he meant to find out where libgcc_eh.a lives under Cygwin and execute the command on that file. It should be somewhere amongst the stuff installed with gcc, but the exact location can vary quite a bit. Cheers. Tim.

llvm[2]: Compiling FileSystemStatCache.cpp for Release+Asserts build FileSystemStatCache.cpp: In static member function 'static bool clang::FileSystemStatCache::get(const char*, stat&, bool, int*, clang::FileSystemStatCache*)': FileSystemStatCache.cpp:63: error: 'openFileForRead' is not a member of 'llvm::sys::fs' make[2]: ***

Anyone have any tips on upgrading the llvm visual studio project from 2008 to 2010? -- Thanks, Brian Herman college.nfshost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130726/fa06116c/attachment.html>

I am curious how do you guys do it anyways? On Mon, Jul 29, 2013 at 3:27 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Vijay Daultani wrote: > >> Respected Sir/Madam, >> >> As I was developing some part of compiler for a project. I require grammar >> (BNF or EBNF) for converting the C code in the IR as it is not been >> mentioned any where over your

Hi, Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash with a backtrace like: [ 3149s] -- [ 3149s] 0 libLLVMSupport.so 0x00003fff7ed0b864 llvm::sys::PrintStackTrace(_IO_FILE*) + 4294746876 [ 3149s] 1 libLLVMSupport.so 0x00003fff7ed0bb1c [ 3149s] 2 libLLVMSupport.so 0x00003fff7ed0c520 [ 3149s] 3 linux-vdso64.so.1 0x00003fff7f7b0478 __kernel_sigtramp_rt64 + 0 [ 3149s] 4

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "İsmail Dönmez" <ismail at donmez.ws> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 26, 2014 8:14:18 AM > Subject: Re: [LLVMdev] Lots of regtest failures on PPC64/Linux > > Hi Ismail, > > Is

Hi, It seems orderings are not assigned to DAG nodes created after the DAG builder, e.g., DAG nodes created during legalization. This causes instructions being scheduled in different order than source order for O0. This is my plan to fix it: Make a utility routine that recursively assign ordering to a chain of nodes, just like what SelectionDAGBuilder::AssignOrderingToNode() does. Then add call

On Wed, Jun 12, 2013 at 7:28 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > So fence only forces ordering of atomic instructions.**** > > ** ** > > Let me change my question then.**** > > ** ** > > If I have a target-specific intrinsic which forces ordering of ordinary > load/store instructions. Then should it also force ordering of load/stores > to

Hi Xiaoyi, Do you still see this behavior after r177525? I recently fixed several places where ordering was not propagated, including during legalization. There are probably still cases that are missed, but I'd be interested in seeing a missed case. I'm guessing it's a legalization that expands to multiple new nodes. The AssignOrdering calls in the legalizer may need to be expanded

On Mon, Jul 29, 2013 at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi,**** > > ** ** > > We have a benchmark where there are 128 MAD computations in a loop. (See > the attached IR.) Creating SCEVs for these expressions takes a long time, > making the compile time too long. E.g., running opt with the “indvars” pass > only takes 45 seconds.**** > >

On Wed, Jun 12, 2013 at 6:17 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > I have the following test case: > > define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* > noalias nocapture %data0) nounwind { > entry: > %val1 = load <2 x float>* %data0, align 8 > store <2 x float> %val1, <2 x float>* %out,

On Thu, Jun 13, 2013 at 10:52 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > I mean something like a target-specific fence machine instruction which > forces ordering of all loads/stores. I want to clarify the meaning of > “noalias” in this case. Is the fence machine instruction considered > “touching” all memory and thus breaks the “noalias” contract? > A fence

On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the “indvars” pass only takes 45 seconds. > > It seems that the majority of the time is

On Thu, Jun 13, 2013 at 11:39 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > In a multi-threaded environment, in order to ensure the memory ordering > expressed by the memory fence, certain memory operations should not be > moved across the fence, right?**** > > ** > Yes, but operations on noalias pointers don't fall into that category. For noalias pointers, while

I have three modules: ----------------------------------------------------------------- s1.ll: %0 = type <{ i32, i32 }> define void @s1(%0* byval %myStruct) nounwind { return: ret void } ----------------------------------------------------------------- s2.ll: %0 = type <{ i32, i32 }> define void @s2(%0* byval %myStruct) nounwind { return: ret void }

Hi Eric, Sorry I wasn't clear. The problem happened in the "source" pre-RA scheduler, which relies on DAG node ordering to schedule the nodes. Xiaoyi From: Eric Christopher [mailto:echristo at gmail.com] Sent: Tuesday, April 30, 2013 12:54 AM To: Guo, Xiaoyi Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] [PATCH] Propagate DAG node ordering during legalization and

Okay, now, before 3.10 is finalized... what bug reports am I still forgetting? -hpa