similar to: Any objections to moving ObjCARC analysis passes to llvm/Analysis?

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

> On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote: > > On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi, > > I am trying to build a completely GNU free linux toolchain for the raspberry pi. > > I successfully managed to compile llvm and clang

Can anyone provide a fix to this error on the llvm trunk at the latest revision (): make[3]: Entering directory `/usr/local/svn-repos/llvm-svn-trunk/build/lib/Transforms/ObjCARC' llvm[3]: Compiling ObjCARCOpts.cpp for Release+Debug+Asserts build /usr/local/svn-repos/llvm-svn-trunk/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp: In constructor

On Sat, Jul 15, 2017 at 5:35 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>> >>>> Thank you all for your replies. >>>> So here seems to be an agreement that the documentation for >>>> PartialAlias is incorrect. >>>>

> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >> Thank you all for your replies. >> So here seems to be an agreement that the documentation for PartialAlias >> is incorrect. >> >> Daniel: now you got me wondering about MustAlias. This is what the docs >> say: >> "The MustAlias response may only be returned if the two memory objects >> are

On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes <nunoplopes at sapo.pt> wrote: > >On 07/15/2017 04:51 AM, Nuno Lopes wrote: > >>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: > >>>> Thank you all for your replies. > >>>> So here seems to be an agreement that the documentation for > >>>> PartialAlias is incorrect. > >>>>

Hi, I am trying to test ThinLTO mode with lld, but am seeing failures because (at optimisation levels above -O0), clang inserts calls to clang.arc.use, which are expected to be removed by the ObjCARCCompact pass. Unfortunately, this pass doesn’t seem to be being run by lld (and adding -mllvm -print-after-all indicates that only SimplifyCFG is being run, which is a bit surprising, though the

On Sun, Jul 16, 2017 at 2:34 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > On Sun, Jul 16, 2017, 12:45 PM Nuno Lopes wrote: >>> >>>> On 07/15/2017 04:51 AM, Nuno Lopes wrote: >>>> >>>>> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >>>>>> >>>>>>> Thank you all for your replies.

On Thu, Nov 28, 2013 at 5:12 PM, Tom Browder <tom.browder at gmail.com> wrote: > Can anyone provide a fix to this error on the llvm trunk at the latest > revision (): Sorry, that is revision 195934. -Tom

Hi. There are few one-line bugs Andrey Karpov have found with static analisys. He wrote a big article in russian on http://habrahabr.ru/blogs/compilers/125626/ for advertising purposes of static analyzer for Visual Studio his company developed. Most of the problems are easy to fix, so I list them in here for trunk version. Also few problems in clang code were found, I don't list them in here.

Can anyone tell me the latest trunk rev that builds successfully? I'm getting the following errors: llvm[3]: Compiling ObjCARCOpts.cpp for Release+Debug+Asserts build /usr/local/svn-repos/llvm-svn-trunk/llvm/lib/Transforms/ObjCARC/ObjCARCOpts.cpp: In constructor '{anonymous}::PtrState::PtrState({anonymous}::PtrState&&)':

The fundamental problem here is that opt doesn’t use ExecutionEngine (because it has no need to), so trying to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for that matter) in an opt plugin isn’t going to work. The solution I’d go with would be to build llvm with shared libraries (use –DBUILD_SHARED_LIBS=ON on the cmake command) then link the plugin against ExecutionEngine.

Thank you all for your replies. So here seems to be an agreement that the documentation for PartialAlias is incorrect. Daniel: now you got me wondering about MustAlias. This is what the docs say: "The MustAlias response may only be returned if the two memory objects are *guaranteed to always start at exactly the same location*" This statement is regardless of the access sizes. For

By linux derivative I meant that it borrows the linux GCC ABI... and it does. You can compile with an off the shelf GCC cross compiler and link the resultant object files ones compiled with the PS3 provided version. We have done it. Also, as both an XBox 360 and PS3 developer, there seems to me to be nothing in the TCRs/TRCs that preclude us from using a different compiler. There are rules

Hi Lockal S, > ---- > > lib/Target/X86/X86ISelLowering.cpp:11689 > !DAG.isKnownNeverZero(LHS)&& !DAG.isKnownNeverZero(LHS)) > > Note that there are identical subexpressions '!DAG.isKnownNeverZero (LHS)' to > the left and to the right of the '&&' operator. > The second subexpression should probably be !DAG.isKnownNeverZero(RHS)). a patch

Hey: I spent sometime debugging this, it seems like editing ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the beginning of main() solved it for me. I'm not sure if this is a bug on LLVM side Zhang ------------------ Original ------------------ From: "Viktor Was BSc via