search for: kbarton

...serif;" ><font size="2" ><span style="font-size:0.857em;" >Kit Barton, Ph.D.<br>STSM, Technical lead for LLVM on Power and XL Compilers<br>IBM Toronto Lab, C2/705/8200/MKM<br>8200 Warden Ave, Markham, L6G 1C7<br>(905) 413-3452<br>kbarton@ca.ibm.com</span></font></span></font></font></div></div></div></div></div></div></div><BR>

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal > Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> > Sent: Wednesday, February 10, 2016 6:59:50 PM > Subject: Re: [llvm-dev] [PPC] Linker fails on -fstack-protector > On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > When -fstack-protector is turned on, lin...

Hi, I am wondering why we dont support PPC32 LE? Here is the output of llvm-mc --version, in which only PPC32, PPC64 & PPC64LE are supported. $ llvm-mc --version LLVM (http://llvm.org/): LLVM version 3.6.2 Optimized build with assertions. Built Aug 2 2015 (11:39:46). Default target: x86_64-apple-darwin15.4.0 Host CPU: core-avx2 Registered Targets: aarch64 - AArch64

...; ------------------------------ >> >> *From: *"Eric Christopher" <echristo at gmail.com> >> *To: *"Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal >> Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> >> *Sent: *Wednesday, February 10, 2016 6:59:50 PM >> *Subject: *Re: [llvm-dev] [PPC] Linker fails on -fstack-protector >> >> >> >> >> >> On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < >> llvm-dev at lists.llvm.org...

...>>>> >>>> *From: *"Eric Christopher" <echristo at gmail.com> >>>> *To: *"Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal >>>> Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> >>>> *Sent: *Wednesday, February 10, 2016 6:59:50 PM >>>> *Subject: *Re: [llvm-dev] [PPC] Linker fails on -fstack-protector >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Jan 25, 2016 at 11:58 A...

Full_Name: Kamil Barto? Version: 2.8.0 OS: windows xp Submission from: (NULL) (212.33.92.187) According to the "deparse" function documentation "nlines" is the *maximum* number of lines to produce. But, when "nlines" argument is supplied, it produces exactly nlines of result, and the result contains empty elements at the end. Example: >

There was a GSoC project in 2016, final report at https://docs.google.com/document/d/1v-R7gB7Or4bPn0LW7d-yb1yla8jK3DVmTJNFVNYNu6k Google doesn't show a lot of activity since. Has anyone taken this work further / put it near production? I'm interested in removing register spills around functions that are known to not clobber said registers. Thanks! Jon -------------- next part

When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put the stack guard into TCB. x86 fixed this issue by injecting a special address space (which is later translated to TCB register access) and hard code the offset of stack_guard, but I don't see a easy way to