search for: clang_cc1

Hello all, I am writing test cases which are dedicated to be executed by llvm-lit. Most of my test cases have the same logic but different types. For example: // RUN: %clang_cc1 -fsyntax-only func (int a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (char a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (unsigned a) { a = 3; } Now I put them in three different test cases but it is hard to maintain. I am wondering whether llvm-lit support writing test cases...

On 08/12/2013 16:43, Daniel Dunbar wrote: > > With one-to-one mapping, it becomes possible to use simple tools > like grep to validate common mistakes like %clang / %clang_cc1 > mixups, a missing -o flag and so on. > > Right now there's no obvious way to do those checks and we've > ended up without an easy way to lint for broken tests as a result. > Each broken test has a high cost so we need to continually look at > ways to...

Ok, that makes sense. I don't see this as a good enough argument to remove backslash support though. For problems like the clang_cc1 substitution mistakes, it would be much better to just improve the substitution support so that those cause immediate test failures. I would definitely support a move to make lit's substitution machinery more strict. For problems like your first search, I can appreciate how wrapped lines make t...

Following came from tools/clang/test/CodeGenObjC/message-arrays.m. But I don't know how to compile it at terminal command since no clang_cc1 executable file. Can some one help me? I am writing the llvm backend document --http://jonathan2251.github.com/lbd/index.html now. I use "clang -c hello.cpp -emit-llvm" to compile C++ but don't know how to compile Object-C. // RUN: %clang_cc1 -emit-llvm -o %t %s void f0(id a) { //...

...e benefit you pointed out so far has been visual wrapping in the editor, > but the cost of that is very high. Perhaps your editor has a virtual > wrapping mode? > > With one-to-one mapping, it becomes possible to use simple tools like grep > to validate common mistakes like %clang / %clang_cc1 mixups, a missing -o > flag and so on. > > Right now there's no obvious way to do those checks and we've ended up > without an easy way to lint for broken tests as a result. Each broken test > has a high cost so we need to continually look at ways to improve the > situatio...

...> Look up --emit-llvm. I think it has to be used with -c. > > On Apr 5, 2013 10:55 PM, "Jonathan" <gamma_chen at yahoo.com.tw> wrote: > Following came from tools/clang/test/CodeGenObjC/message-arrays.m. But I don't know how to compile it at terminal command since no clang_cc1 executable file. Can some one help me? I am writing the llvm backend document --http://jonathan2251.github.com/lbd/index.html now. I use "clang -c hello.cpp -emit-llvm" to compile C++ but don't know how to compile Object-C. > > // RUN: %clang_cc1 -emit-llvm -o %t %s > >...

Look up --emit-llvm. I think it has to be used with -c. On Apr 5, 2013 10:55 PM, "Jonathan" <gamma_chen at yahoo.com.tw> wrote: > Following came from tools/clang/test/CodeGenObjC/message-arrays.m. But I > don't know how to compile it at terminal command since no clang_cc1 > executable file. Can some one help me? I am writing the llvm backend > document --http://jonathan2251.github.com/lbd/index.html now. I use > "clang -c hello.cpp -emit-llvm" to compile C++ but don't know how to > compile Object-C. > > // RUN: %clang_cc1 -emit-llvm -...

.... This has the undesirable property that it is really easy for tests to bitrot. For example, something like llc %s | FileCheck %s will still pass if llc crashes after printing what FileCheck was looking for. It is also easy to break the tests when refactoring. I have fixed tests that were doing %clang_cc1 -a-driver-options ... | not grep clearly the test was changed from %clang to %clang_cc1 and we missed the fact that the option also had to be updated. Currently to check a command output and that it doesn't crash we have to do llc %s > %t FileCheck %s < %t I would like to switch to us...

...rapped RUN lines. The benefit you pointed out so far has been visual wrapping in the editor, but the cost of that is very high. Perhaps your editor has a virtual wrapping mode? With one-to-one mapping, it becomes possible to use simple tools like grep to validate common mistakes like %clang / %clang_cc1 mixups, a missing -o flag and so on. Right now there's no obvious way to do those checks and we've ended up without an easy way to lint for broken tests as a result. Each broken test has a high cost so we need to continually look at ways to improve the situation. Alp. -- http://www....

...--emit-llvm. I think it has to be used with -c. >> >> On Apr 5, 2013 10:55 PM, "Jonathan" <gamma_chen at yahoo.com.tw> wrote: >> Following came from tools/clang/test/CodeGenObjC/message-arrays.m. But I don't know how to compile it at terminal command since no clang_cc1 executable file. Can some one help me? I am writing the llvm backend document --http://jonathan2251.github.com/lbd/index.html now. I use "clang -c hello.cpp -emit-llvm" to compile C++ but don't know how to compile Object-C. >> >> // RUN: %clang_cc1 -emit-llvm -o %t %s &gt...

On Sep 10, 2016, at 3:33 AM, Steve Canon <scanon at apple.com> wrote: >>> >>> Pretty much. In particular, imagine a user trying to debug an unexpected floating point result caused by conversion of a*b + c into fma(a, b, c). >> >> I think that’s unavoidable, because of the way the optimization levels work. Even fma contraction is on by default (something I’d

...t is really easy for tests to > bitrot. For example, something like > > llc %s | FileCheck %s > > will still pass if llc crashes after printing what FileCheck was > looking for. It is also easy to break the tests when refactoring. I > have fixed tests that were doing > > %clang_cc1 -a-driver-options ... | not grep > > clearly the test was changed from %clang to %clang_cc1 and we missed > the fact that the option also had to be updated. > > Currently to check a command output and that it doesn't crash we have to do > > llc %s > %t > FileCheck %s...

...ler inputs, so trailing >> slash is a bit unfortunate. >> > > How does the backslash break this in any way? The backslash is interpreted by lit and the compiler in different and incompatible ways. Spot the problem in this reduced example.. // expected-no-diagnostics // RUN: %clang_cc1 %s -verify -emit-llvm -o - | \ __attribute__((packed)) // no warning int x; // RUN: FileCheck %s // CHECK: @x = common global i32 0, align 4 It is easier to get this wrong than it is to get it right -- in effect, lit is encouraging use of backslash line continuations which are guaranteed to...

...// generate a very good error message with the information we have that // includes the list of valid values. def clang_f_fp_contract : ClangSeparateValues<"ffp-contract", ["fast", "on", "off"]>; ClangCC1.td: include "Option.td" def clang_cc1 : Tool; class ClangCC1Option< list<string> prefixes , string name , dag strparse , string render , dag rendermatch> : Option<prefixes, name, clang_cc1, strparse, render, rendermatch>;...

As long as the individual commands are still copy-pastable into both cmd and bash, I'm happy. I think practice this means the output should look more like this: some test: // RUN: %clang_cc1 %s -verify output: $ "C:\\src\\llvm\\build\\bin\\clang.exe" -cc1 "C:\\....\\test.cpp" -verify Essentially every program used in the LLVM test suite understands forward slashes, so we could rewrite the path to test.cpp to use forward slashes, but I think cmd wants to see backsl...

Hi, I've prepared patches for both LLVM and Clang to change the datalayout for R600. This may seem like a bold move, but I think it is warranted. R600/SI is a strange architecture in that it uses 64bit pointers but does not support 64 bit arithmetic except for load/store operations that roughly map onto getelementptr. The current datalayout for r600 includes n32:64, which is odd

...with the information we have that > // includes the list of valid values. > def clang_f_fp_contract : ClangSeparateValues<"ffp-contract", > ["fast", "on", "off"]>; > > ClangCC1.td: > include "Option.td" > > def clang_cc1 : Tool; > > class ClangCC1Option< list<string> prefixes > , string name > , dag strparse > , string render > , dag rendermatch> > : Option<prefixes, name, clang_cc1, str...

On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com> wrote: >> >> Agreed. Although I assume you mean invoke the new pass under a >> ThinLTO-only option so that avail extern are not dropped in the >> compile pass before the LTO link? > > > No, this pass

On Jun 18, 2011, at 3:14 PM, Xi Wang wrote: > Hi, > > When generating debugging information for a data member (e.g., a struct field), Clang doesn't set the member's context to the enclosed class/struct/union type --- it currently sets the context to the file instead. The attached patch corrects this. Thanks. Do you have a test case ? Please update createMemberType() directly,

So I manage to get clang's colored output through ninja simply by force (CMAKE_CXX_FLAGS=-fcolor-diagnostics), which isn't ideal (if I were to pipe ninja's output to a file it'd still have color escapes, etc) but it works. But I haven't found a similar solution for FileCheck & I'm wondering has anyone already solved this problem for themselves - if so, how? if not,