similar to: [LLVMdev] Native Static Compilers Compatible with LLVM

Is there anything else besides GNU or any other targets in the future? My goal is to be able to not have all the binaries coming out to be GPL.. If not, I will have to go back to using C as an intermediate language. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090408/5216ab28/attachment.html>

Hello, I have looked around the LLVM documentation, and tried to experiment with static compilation. So far It appears as though the assembly file is only compatible with GCC. When I use llvm-ld it also appears to use GCC. Is there any other assembler or compiler that can statically compile LLVM output? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Apr 8, 2009 at 5:50 PM, Bot Tiger <bottiger1 at gmail.com> wrote: > Is there anything else besides GNU or any other targets in the future? > > My goal is to be able to not have all the binaries coming out to be GPL.. You do know that the GNU tools don't cause their output to be GPL'ed, right? http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF and

If you're generating a .s file for X86, you can specify the flavor of assembly language on the command line like this: llvm-gcc ... -mllvm -x86-asm-syntax=[att|intel] Here's the relevant lines in the llc -help: ... -x86-asm-syntax - Choose style of code to emit from X86 backend: =att - Emit AT&T-style assembly =intel

Hello Jeffery, Thank you for the information, but I was already aware of this. I still have many concerns about GCC from the links you sent yourself: >"A file is an "Independent Module" if it either requires the Runtime Library for execution after a Compilation >Process, or makes use of an interface provided by the Runtime Library, but is not otherwise based on the >

Hello. Is there a way to output native assembly from llvm-ld to FASM? Also when I tried to compile C code generated by llc with TCC, it complained about not having the alloca.h header. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090406/c3243719/attachment.html>

I've tried compiling with tinycc, and assembling with yasm, and fasm even with intel syntax. I'm just wondering what available compilers and assemblers there are without trying every one of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090408/b779a781/attachment.html>

> I've tried compiling with tinycc, and assembling with yasm, and fasm even > with intel syntax. I'm just wondering what available compilers and > assemblers there are without trying every one of them. gas -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Wed, Jul 15, 2009 at 3:43 PM, Eli Friedman<eli.friedman at gmail.com> wrote: > On Wed, Jul 15, 2009 at 3:01 PM, Bill Wendling<isanbard at gmail.com> wrote: >> The core problem, in my opinion, is that people *don't* pay attention >> to the build bot failure messages that come along. > > That's largely because of the number of false positives. > There

On Apr 3, 2013, at 2:07 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 1 April 2013 22:05, Bill Wendling <wendling at apple.com> wrote: > We would like to support ARM again. > > Hi Bill, > > Glad you asked! ;) > > I'm getting the test-suite bot green (a few minor tweaks and we're good) and that should get us well ahead of what we've

Happy April! [Contrary to the day, this is not an April Fool's joke. ;-)] It has been several months since the release of Clang 3.2. Now is the time to start thinking about the next release! The (very) tentative schedule is testing in May and a release in June. What This Means For You Now is the time to start thinking about which features you are currently working on and getting them

On Wed, Jul 15, 2009 at 1:50 PM, Dale Johannesen<dalej at apple.com> wrote: > > On Jul 15, 2009, at 1:43 PMPDT, Török Edwin wrote: >> On 2009-07-15 23:24, Dale Johannesen wrote: >>> On Jul 15, 2009, at 11:52 AMPDT, Stuart Hastings wrote: > >>> I wonder if we might be able to automate the stabilization somewhat. >>> I'm not at all sure this can be

On Jul 15, 2009, at 4:48 PMPDT, Daniel Dunbar wrote: > That depends on what you call a false positive. The public buildbot > regularly fails because of mailing Frontend tests, and I have had > continues failures of some DejaGNU tests for a long time on some > builders. Its not a false positive per se, but one starts to ignore > the failures because they aren't unexpected. Yes.

+1 to Justin's comment The only standard for revert should be: it's broken, and here's a reproducer.  Nothing else should matter. ... says the person w/a ton of internal regression testing which regularly finds crashes upstream, and is terrified of the implied effort of having to engage each author of a broken patch individually while being unable to ship or see what other

That depends on what you call a false positive. The public buildbot regularly fails because of mailing Frontend tests, and I have had continues failures of some DejaGNU tests for a long time on some builders. Its not a false positive per se, but one starts to ignore the failures because they aren't unexpected. - Daniel On Wed, Jul 15, 2009 at 4:10 PM, Bill Wendling<isanbard at

Hello, I''ve been using cbq''s "weight" parameter to influence distribution of excess bandwidth among sibling classes. Does htb offer something similar? So far I think that - you either use priorities - then excess bandwidth is offered to higher priority classes first, the rest (if any) is distributed among lower priority classes - or you don''t use

2009/7/15 Dale Johannesen <dalej at apple.com> > > On Jul 15, 2009, at 4:48 PMPDT, Daniel Dunbar wrote: > > > That depends on what you call a false positive. The public buildbot > > regularly fails because of mailing Frontend tests, and I have had > > continues failures of some DejaGNU tests for a long time on some > > builders. Its not a false positive per

Hello, I've recently discovered a persistent issue with rpanel when running R.app (2.6.1) on Mac OS X 10.4.11. tcltk and rpanel load without any apparent error, and the interactive panels appear to work as expected, however upon closing the panels rpanel has created I get catastrophic errors and R crashes completely. For the most part R manages to crash with dignity and work can be saved, but

On Fri, May 29, 2020 at 4:00 PM Richard Smith <richard at metafoo.co.uk> wrote: > > On Fri, 29 May 2020 at 11:06, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 28 May 2020, at 18:42, Bill Wendling wrote: >> >> > On Tue, May 26, 2020 at 7:49 PM James Y Knight via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote:

On 08/26/2015 09:46 AM, Philip Reames wrote: > On 08/26/2015 09:41 AM, David Blaikie via llvm-dev wrote: >> >> >> On Wed, Aug 26, 2015 at 9:41 AM, Renato Golin >> <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: >> >> On 26 August 2015 at 17:39, David Blaikie <dblaikie at gmail.com >> <mailto:dblaikie at