similar to: [LLVMdev] RFC: Change tests to run with fixed (not-host dependent) triple

On Mon, Dec 3, 2012 at 9:21 AM, David Tweed <david.tweed at arm.com> wrote: > -----Original Message----- > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On > Behalf Of David Blaikie > Sent: 03 December 2012 16:41 > To: Renato Golin > Cc: LLVM Developers Mailing List; cfe-dev > Subject: Re: [cfe-dev] [LLVMdev] RFC: Change tests to run with

On Mon, Dec 3, 2012 at 1:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > Apart from what has already being said, which I agree mostly, I have > some specific comments: > > >> a. We change the test suite to run in such a way that all tools default to >> an "unknown" host triple. > > The assumptions will be different and I believe the

I'm ok with this in principle, but how about with the nuance that some tests (eg test/codegen) explicitly opt into march=native? -Chris On Nov 30, 2012, at 12:16 PM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi all, > > We consistently see test failures arising because by default many of our tests run in a mode where the tool (clang or llc) pick host-dependent behavior.

On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: > I'm ok with this in principle, but how about with the nuance that some > tests (eg test/codegen) explicitly opt into march=native? > I'd really like the default behavior to be something that forces the test to either be independent of the targeted triple, or explicitly set a target. I like the

Apart from what has already being said, which I agree mostly, I have some specific comments: > a. We change the test suite to run in such a way that all tools default to > an "unknown" host triple. The assumptions will be different and I believe the refactoring of the tests to make them pass on all currently passing architectures will not be trivial. Good luck! ;) > b. If

My thoughts: On Sat, Dec 1, 2012 at 9:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com>wrote: > >> I'm ok with this in principle, but how about with the nuance that some >> tests (eg test/codegen) explicitly opt into march=native? >> > > I'd really like the default

On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: > >> I'm ok with this in principle, but how about with the nuance that some >> tests (eg test/codegen) explicitly opt into march=native? >> > > I'd really like the default behavior to be

On Mon, Dec 3, 2012 at 10:47 AM, Daniel Dunbar <daniel at zuster.org> wrote: > On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com> > wrote: >> >> On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> I'm ok with this in principle, but how about with the nuance that some >>>

On Mon, Dec 3, 2012 at 10:56 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Dec 3, 2012 at 10:47 AM, Daniel Dunbar <daniel at zuster.org> wrote: > > On Sat, Dec 1, 2012 at 1:06 AM, Chandler Carruth <chandlerc at google.com> > > wrote: > >> > >> On Fri, Nov 30, 2012 at 8:04 PM, Chris Lattner <clattner at apple.com> > wrote:

On 3 December 2012 17:21, David Tweed <david.tweed at arm.com> wrote: > Just a point here: the reason I'd mildly prefer not to have a default that > avoids as much target dependent stuff as possible is that it's generally > going to have a higher probability of passing even if something is "wrong" > in the sense that, eg, if the return type of some thing is ABI

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

On 6/23/14, 8:31 AM, David Chisnall wrote: > On 23 Jun 2014, at 15:13, Renato Golin <renato.golin at linaro.org> wrote: > >> The main issue with your patch is that it can change user expected >> behaviour, and I can't tell you what is the expected behaviour in >> Darwin or BSD. If people usually use "unknown" in triples, this will >> break their

Hi all, I have some ideas for GSOC projects using LLVM, where should I post them? Idea #1: llvm-env A simple tool, with little or no dependency on LLVM itself, that will investigate a target architecture by probing hardware, software, libraries and compiling and executing code to identify all properties that would be relevant to command-line options, triple settings etc. The first stage is to

I have managed to compile llvm and clang against musl, but it behaves really strange: At first I tried to launch the compiler with musl dynamic loader: $ LD_LIBRARY_PATH=/path/to/musl/lib /path/to/musl/lib/ld-musl-x86_64.so.1 /path/to/llvm/bin/clang -v clang version 4.0.0 (https://github.com/llvm-mirror/clang 40adebeca0f99006d407508653c2cbd270a1a51c) (https://github.com/llvm-mirror/llvm

On 31 January 2013 12:45, Chandler Carruth <chandlerc at google.com> wrote: > This to me says that the concerns and protections of the experimental > backend aren't needed, and are more likely to impede progress than help it > -- specifically, we won't get good build bot coverage and diverse host > compiler coverage until it's enabled. > +1 --renato

On 25 June 2014 12:58, James Molloy <james at jamesmolloy.co.uk> wrote: > This is one of the worst parts about the Clang CLI for cross compilation at > the moment. I'd really like, if we're changing the CLI, to allow users to > remove it. For example, if I specify -march=armv7-a, it *shouldn't* need me > to put "-target arm" before it to work! Good lord,

Renato Golin wrote: [...] > Try setting armv7a-unknown-linux-gnueabihf and see if it works better. No, that doesn't work either. [...] > JIT was never the forte of ARM and I haven't tried yet, but I doubt > it'll be any Debian misconfiguration. The whole architecture > configuration is a bit odd... Debian's clang packages are totally broken on armhf --- the compiler

Hi Guy, Thanks a lot for the clarification. I tried using the triple for SPIR as $ clang -x cl -fno-builtin -emit-llvm -c -Xclang -triple -Xclang spir-unknown-unknown Simple_Kernel.cl However I get the following error. error: unknown target triple 'spir-unknown-unknown', please use -triple or -arch I also tried with triple nvptx-unknown-unknown clang -x cl -fno-builtin -emit-llvm -S

On Jan 23, 2013, at 4:04 , "Benyei, Guy" <guy.benyei at intel.com> wrote: > Hi Ankur, > Since you use –Xclang, the clang executable passes multiple triples to “clang -cc1”. You can see that if you add the -v option. I’m sure there is someone here who can explain it better than I… > Anyhow, I think you better use clang -cc1. Make sure -cc1 is the first command line option