similar to: [LLVMdev] .thumb_set

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] .thumb_set"

2015 Jun 12
2
[LLVMdev] .thumb_set
For what it is worth it, gas has this strange behaviour. I agree it is strange, but why is it an issue for r239440? Will I get a failure if I revert it? Cheers, Rafael On 12 June 2015 at 12:17, Pete Cooper <peter_cooper at apple.com> wrote: > Hey Salem, > > Any chance you’ve had time to take a look at this? > > If you prefer, I can prepare a patch with the change i’d like
2015 Jun 13
2
[LLVMdev] .thumb_set
On 13 June 2015 at 04:12, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > The behavior was taken from GAS. I don't know if there are applications > using this and dependent on the behavior. Given that this is a GNU > extension, I think its better to keep the behavior similar to GAS rather > than implement and diverge. I kind of agree with Saleem, here. We don't
2014 Mar 03
3
[LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)
On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at nondot.org> wrote: > > On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > > > On 3 March 2014 12:32, Pete Cooper <peter_cooper at apple.com> wrote: > >> Would those work with a foreach construct? Perhaps I forgot to mention > that was what I'm trying to work out
2014 Mar 03
3
[LLVMdev] C++11 reverse iterators (was C++11 is here)
On 3 March 2014 12:32, Pete Cooper <peter_cooper at apple.com> wrote: > Would those work with a foreach construct? Perhaps I forgot to mention that was what I'm trying to work out here. > > In example 3 I was wondering if we could define a method reverse(). We could use sfinae to wrap that around rbegin/rend if people like that style? Sorry, I was too terse... ;) If MF is a
2014 Mar 03
2
[LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)
On Mar 2, 2014, at 10:27 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Sun, Mar 2, 2014 at 10:13 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Sun, Mar 2, 2014 at 9:26 PM, Chris Lattner <sabre at nondot.org> wrote: > > On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > > > On 3 March 2014
2014 Jun 23
4
[LLVMdev] Support for Windows Phone 8.1
On Wed, Jun 18, 2014 at 10:25 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com> wrote: > >> Hi Saleem, >> >> Though a simple app works great I am facing few issues trying to link a >> slightly complex object file, generated via LLVM, with some libs generated >> via
2015 Apr 24
3
[LLVMdev] unwind move *NOW*
Greetings, As previously mentioned, the unwind contents are going to be moved today. Im working on this now. If you could please hold off any commits to the Unwind part of things, it would be greatly appreciated. See you on the new layout! -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL:
2015 Jan 31
2
[LLVMdev] unwind's permanent residence
On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: > >> Shouldn't it just use the default unwinder for the given platform? >> > > Sure, but what is the default unwinder for a given platform? > > Lets go with Linux. I have two different
2015 Apr 22
4
[LLVMdev] unwind's permanent residence
On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 22 April 2015 at 03:40, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> So after a bit of a hiatus (sorry, other stuff has been eating up my free >> time), Id like to pick this up again. I think that its a matter of just >> copying the unwind sources into the right
2014 Jun 18
2
[LLVMdev] Support for Windows Phone 8.1
Hi Saleem, Though a simple app works great I am facing few issues trying to link a slightly complex object file, generated via LLVM, with some libs generated via Visual Studio - 1. Seems IMAGE_SCN_MEM_16BIT is only written for the the first header in the COFF file, thus functions in other headers (if you are using function sections) don’t work. I was able to workaround this by forcing this entry
2015 Jan 31
0
[LLVMdev] unwind's permanent residence
On Fri, Jan 30, 2015 at 4:15 PM, Dan Albert <danalbert at google.com> wrote: > On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org > > wrote: > >> On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: >> >>> Shouldn't it just use the default unwinder for the given platform? >>> >>
2014 Jun 08
2
[LLVMdev] Code generation support in llvm for windows phone
Thank you so much Saleem, The target is Windows phone 8.1 (ARM). I'll update the crash details tomorrow. One big problem is that I have to use a physical windows phone for execution. I wonder if it is possible to execute such "exes" using qemu. Regards, Kashyap On Sun, Jun 8, 2014 at 2:53 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Sat, Jun 7, 2014 at
2014 Jun 09
2
[LLVMdev] Support for Windows Phone 8.1
Thanks a lot Saleem, The issue is fixed and a simple app works fine now. -Daman On 08/06/14 12:57 pm, "Nick Lewycky" <nicholas at mxc.ca> wrote: >Damanjit Singh wrote: >> Thanks Saleem, Nick. >> >> I will try with the latest code and share the results. >> >> Though, just curious if I need to really use clang to generate the >> object file
2014 Sep 06
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > Sergey, > > Not that it'll save you much hassle, but here's an implementation of > __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while. > > I vaguely remember compnerd suggesting that I don't commit them to > compiler_rt, but I don't remember
2019 Jun 27
2
A libc in LLVM
On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner <clattner at nondot.org> wrote: > Saleem, Owen, others on the thread who are concerned about this: it seems > that some of the concern is that the project goals are too narrow, and thus > the eventual result may not serve the full community well over time. > > Would any of you be interested in what we should consider as the list
2015 Feb 05
3
[LLVMdev] unwind's permanent residence
On Tue, Feb 3, 2015 at 4:07 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> > wrote: > > Last time we brought this up, there was only partial consensus, and then > > someone arbitrarily declared total consensus (without compelling > arguments > > in any particular direction)
2018 Jan 04
8
Linker Option support for ELF
Hello all, There was some interest from a number of a few people about adding support for embedded linker options to ELF. This would be an extension that requires linker support to actually work, but has significant prior art with PE/COFF as well as MachO both having support for this. The desire here is to actually add support to LLVM to pass along the necessary information into the object
2014 Jun 08
2
[LLVMdev] Support for Windows Phone 8.1
Thanks Saleem, Nick. I will try with the latest code and share the results. Though, just curious if I need to really use clang to generate the object file and the current steps won't work? I ask because using .c file was only an illustration. For my project the IR is not generated from .c files or clang. Thanks, Daman Sent from my phone On 08-Jun-2014, at 11:00 am, "Saleem
2014 Sep 10
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
On Tue, Sep 9, 2014 at 1:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 9 September 2014 02:18, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > The current implementations actually return 0. Can you point out where > that > > doesn't hold please? > > With the current implementation... > > int foo(int a) { > return
2015 Jan 30
2
[LLVMdev] unwind's permanent residence
On 30 Jan 2015 21:24, "Saleem Abdulrasool" <compnerd at compnerd.org> wrote: > The library is agnostic of the unwinder, the driver is who cares (as it needs to generate the linker invocation). I think that adding a flag to control that similar to -rtlib is probably what we may have to do then. What about the default unwinder for Compiler-RT? Should we assume our own?