similar to: [LLVMdev] IAS and inline assembly

There was another option mentioned on the gcc mailing list: Pass comments through to the output. The current behaviour is to remove them. I prefer either 'continuing with the current behaviour' or 'current behaviour but report parse errors as warnings for -S'. I'd prefer the former of these two but I'm pushed away from that position by the fact that gas and IAS

First, I would assume this would be better spelled as: __has_feature(integrated_assembler) But I agree with others that "integrated assembler" isn't a feature which should be observable in source code. On Sun, Feb 23, 2014 at 4:27 PM, Renato Golin <renato.golin at linaro.org>wrote: > On a higher level, there's the quality issue. People should test for >

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

This seems to be a slightly contentious suggestion, so it seems fitting to bring it up on cfe-dev. Given that -fintegrated-as and -fno-integrated-as are available to the user, and that the integrated assembler can be a bit stringent (as compared to GAS at least, which, for example, supports deprecated syntax), it might be nice to permit the user to detect that an integrated assembler is in use.

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:

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

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

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

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

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

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

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

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)

On Tue, Sep 16, 2014 at 4:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: > If you build with configure+make, just run configure with —disable-zlib. > We do this routinely, so I’m pretty sure it works. > It "works" as in it builds. However, the support for it is disabled since zlib::compress will always return StatusUnsupported, so the debug information will just not

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?

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

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

On Fri, Jan 30, 2015 at 3:10 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 1:41 PM, Renato Golin <renato.golin at linaro.org> > wrote: > >> What about the default unwinder for Compiler-RT? Should we assume our >> own? Gcc's? Assuming nothing will break compilation, since the libraries >> won't be available...

On Thu, Jun 27, 2019 at 4:58 PM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > For what it is worth, I do believe that these files do really belong in > the libc project because they are so intricately tied to the implementation > of the language. I just think that the fact these files will be part of > the project is merely an implementation detail and should not even

In spite of this possibly raising a holy war, I thought I would bring up this question again. When switching between a couple of LLVM repositories, I find having to switch between coding styles a bit of an annoyance. It always takes me a while to get adjusted when switching between LLVM (or clang) and lld. While not an absolute show stopper, not having such friction would be nicer. I realize