[PATCH] D36364: [AArch64] Add support for a MinGW AArch64 target

2017-08-12 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

@compnerd - are you ok with this one as well?


https://reviews.llvm.org/D36364



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 110863.
yaxunl marked 5 inline comments as done.
yaxunl added a comment.

Revised by John's and Tony's comments.


https://reviews.llvm.org/D36580

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/SyncScope.h
  lib/CodeGen/CGAtomic.cpp
  lib/Frontend/InitPreprocessor.cpp
  lib/Sema/SemaChecking.cpp
  test/CodeGenOpenCL/atomic-ops-libcall.cl
  test/CodeGenOpenCL/atomic-ops.cl
  test/SemaOpenCL/atomic-ops.cl

Index: test/SemaOpenCL/atomic-ops.cl
===
--- test/SemaOpenCL/atomic-ops.cl
+++ test/SemaOpenCL/atomic-ops.cl
@@ -14,7 +14,6 @@
 int8 i64;
 
 atomic_int gn;
-
 void f(atomic_int *i, const atomic_int *ci,
atomic_intptr_t *p, atomic_float *d,
int *I, const int *CI,
@@ -81,6 +80,13 @@
 }
 
 void memory_checks(atomic_int *Ap, int *p, int val) {
+  // non-integer memory order argument is casted to integer type.
+  (void)__opencl_atomic_load(Ap, 1.0f, memory_scope_work_group);
+  float forder;
+  (void)__opencl_atomic_load(Ap, forder, memory_scope_work_group);
+  struct S s;
+  (void)__opencl_atomic_load(Ap, s, memory_scope_work_group); // expected-error {{passing 'struct S' to parameter of incompatible type 'int'}}
+
   (void)__opencl_atomic_load(Ap, memory_order_relaxed, memory_scope_work_group);
   (void)__opencl_atomic_load(Ap, memory_order_acquire, memory_scope_work_group);
   (void)__opencl_atomic_load(Ap, memory_order_consume, memory_scope_work_group); // expected-error {{use of undeclared identifier 'memory_order_consume'}}
@@ -151,8 +157,15 @@
   (void)__opencl_atomic_load(Ap, memory_order_relaxed, memory_scope_device);
   (void)__opencl_atomic_load(Ap, memory_order_relaxed, memory_scope_all_svm_devices);
   (void)__opencl_atomic_load(Ap, memory_order_relaxed, memory_scope_sub_group);
-  (void)__opencl_atomic_load(Ap, memory_order_relaxed, scope); // expected-error{{non-constant synchronization scope argument to atomic operation is not supported}}
+  (void)__opencl_atomic_load(Ap, memory_order_relaxed, scope);
   (void)__opencl_atomic_load(Ap, memory_order_relaxed, 10);//expected-error{{synchronization scope argument to atomic operation is invalid}}
+
+  // non-integer memory scope is casted to integer type.
+  float fscope;
+  (void)__opencl_atomic_load(Ap, memory_order_relaxed, 1.0f);
+  (void)__opencl_atomic_load(Ap, memory_order_relaxed, fscope);
+  struct S s;
+  (void)__opencl_atomic_load(Ap, memory_order_relaxed, s); //expected-error{{passing 'struct S' to parameter of incompatible type 'int'}}
 }
 
 void nullPointerWarning(atomic_int *Ap, int *p, int val) {
Index: test/CodeGenOpenCL/atomic-ops.cl
===
--- test/CodeGenOpenCL/atomic-ops.cl
+++ test/CodeGenOpenCL/atomic-ops.cl
@@ -52,6 +52,81 @@
   return __opencl_atomic_compare_exchange_strong(i, &cmp, 1, memory_order_acquire, memory_order_acquire, memory_scope_work_group);
 }
 
+void fi5(atomic_int *i, int scope) {
+  // CHECK-LABEL: @fi5
+  // CHECK: switch i32 %{{.*}}, label %opencl_allsvmdevices [
+  // CHECK-NEXT: i32 1, label %opencl_workgroup
+  // CHECK-NEXT: i32 2, label %opencl_device
+  // CHECK-NEXT: i32 4, label %opencl_subgroup
+  // CHECK-NEXT: ]
+  // CHECK: opencl_workgroup:
+  // CHECK: load atomic i32, i32 addrspace(4)* %{{.*}} syncscope("workgroup") seq_cst
+  // CHECK: br label %atomic.scope.continue
+  // CHECK: opencl_device:
+  // CHECK: load atomic i32, i32 addrspace(4)* %{{.*}} syncscope("agent") seq_cst
+  // CHECK: br label %atomic.scope.continue
+  // CHECK: opencl_allsvmdevices:
+  // CHECK: load atomic i32, i32 addrspace(4)* %{{.*}} seq_cst, align 4
+  // CHECK: br label %atomic.scope.continue
+  // CHECK: opencl_subgroup:
+  // CHECK: %5 = load atomic i32, i32 addrspace(4)* %0 syncscope("subgroup") seq_cst, align 4
+  // CHECK: br label %atomic.scope.continue
+  // CHECK: atomic.scope.continue:
+  int x = __opencl_atomic_load(i, memory_order_seq_cst, scope);
+}
+
+void fi6(atomic_int *i, int order, int scope) {
+  // CHECK-LABEL: @fi6
+  // CHECK: switch i32 %{{.*}}, label %monotonic [
+  // CHECK-NEXT: i32 1, label %acquire
+  // CHECK-NEXT: i32 2, label %acquire
+  // CHECK-NEXT: i32 5, label %seqcst
+  // CHECK-NEXT: ]
+  // CHECK: monotonic:
+  // CHECK: switch i32 %{{.*}}, label %[[MON_ALL:.*]] [
+  // CHECK-NEXT: i32 1, label %[[MON_WG:.*]]
+  // CHECK-NEXT: i32 2, label %[[MON_DEV:.*]]
+  // CHECK-NEXT: i32 4, label %[[MON_SUB:.*]]
+  // CHECK-NEXT: ]
+  // CHECK: acquire:
+  // CHECK: switch i32 %{{.*}}, label %[[ACQ_ALL:.*]] [
+  // CHECK-NEXT: i32 1, label %[[ACQ_WG:.*]]
+  // CHECK-NEXT: i32 2, label %[[ACQ_DEV:.*]]
+  // CHECK-NEXT: i32 4, label %[[ACQ_SUB:.*]]
+  // CHECK-NEXT: ]
+  // CHECK: seqcst:
+  // CHECK: switch i32 %2, label %[[SEQ_ALL:.*]] [
+  // CHECK-NEXT: i32 1, label %[[SEQ_WG:.*]]
+  // CHECK-NEXT: i32 2, label %[[SEQ_DEV:.*]]
+  // CHECK-NEXT: i32 4, label %[[SEQ_SUB:.*]]
+  // C

Re: r309226 - Headers: improve ARM EHABI coverage of unwind.h

2017-08-12 Thread Saleem Abdulrasool via cfe-commits
Yeah, we should adjust that.  Technically, it is `_Unwind_Control_Block on
ARM EHABI.  However, _Unwind_Exception is aliased to that, which is why we
can use that in the personality routine.  We should adjust the sources for
the personality routine.

On Fri, Aug 11, 2017 at 1:12 PM, Evgenii Stepanov  wrote:

> Hi,
>
> I've noticed that the code in
> compiler-rt/lib/builtins/gcc_personality_v0.c refers to
> _Unwind_Exception as "struct _Unwind_Exception". With this change, it
> is not a struct anymore on ARM. Should that code be fixed, or is it a
> problem in this change?
>
> compiler-rt/lib/builtins/gcc_personality_v0.c:153:23: error:
> declaration of 'struct _Unwind_Exception' will not be visible outside
> of this function [-Werror,-Wvisibility]
> continueUnwind(struct _Unwind_Exception *exceptionObject,
>
> On Thu, Jul 27, 2017 at 9:46 AM, Hans Wennborg via cfe-commits
>  wrote:
> > Merged to 5.0 in r309290.
> >
> > On Wed, Jul 26, 2017 at 3:55 PM, Saleem Abdulrasool via cfe-commits
> >  wrote:
> >> Author: compnerd
> >> Date: Wed Jul 26 15:55:23 2017
> >> New Revision: 309226
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=309226&view=rev
> >> Log:
> >> Headers: improve ARM EHABI coverage of unwind.h
> >>
> >> Ensure that we define the `_Unwind_Control_Block` structure used on ARM
> >> EHABI targets.  This is needed for building libc++abi with the unwind.h
> >> from the resource dir.  A minor fallout of this is that we needed to
> >> create a typedef for _Unwind_Exception to work across ARM EHABI and
> >> non-EHABI targets.  The structure definitions here are based originally
> >> on the documentation from ARM under the "Exception Handling ABI for the
> >> ARM® Architecture" Section 7.2.  They are then adjusted to more closely
> >> reflect the definition in libunwind from LLVM.  Those changes are
> >> compatible in layout but permit easier use in libc++abi and help
> >> maintain compatibility between libunwind and the compiler provided
> >> definition.
> >>
> >> Modified:
> >> cfe/trunk/lib/Headers/unwind.h
> >>
> >> Modified: cfe/trunk/lib/Headers/unwind.h
> >> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/
> unwind.h?rev=309226&r1=309225&r2=309226&view=diff
> >> 
> ==
> >> --- cfe/trunk/lib/Headers/unwind.h (original)
> >> +++ cfe/trunk/lib/Headers/unwind.h Wed Jul 26 15:55:23 2017
> >> @@ -76,7 +76,13 @@ typedef intptr_t _sleb128_t;
> >>  typedef uintptr_t _uleb128_t;
> >>
> >>  struct _Unwind_Context;
> >> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) ||
> defined(__ARM_DWARF_EH___))
> >> +struct _Unwind_Control_Block;
> >> +typedef struct _Unwind_Control_Block _Unwind_Exception; /* Alias */
> >> +#else
> >>  struct _Unwind_Exception;
> >> +typedef struct _Unwind_Exception _Unwind_Exception;
> >> +#endif
> >>  typedef enum {
> >>_URC_NO_REASON = 0,
> >>  #if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) && \
> >> @@ -109,8 +115,42 @@ typedef enum {
> >>  } _Unwind_Action;
> >>
> >>  typedef void (*_Unwind_Exception_Cleanup_Fn)(_Unwind_Reason_Code,
> >> - struct _Unwind_Exception
> *);
> >> + _Unwind_Exception *);
> >>
> >> +#if defined(__arm__) && !(defined(__USING_SJLJ_EXCEPTIONS__) ||
> defined(__ARM_DWARF_EH___))
> >> +typedef struct _Unwind_Control_Block _Unwind_Control_Block;
> >> +typedef uint32_t _Unwind_EHT_Header;
> >> +
> >> +struct _Unwind_Control_Block {
> >> +  uint64_t exception_class;
> >> +  void (*exception_cleanup)(_Unwind_Reason_Code,
> _Unwind_Control_Block *);
> >> +  /* unwinder cache (private fields for the unwinder's use) */
> >> +  struct {
> >> +uint32_t reserved1; /* forced unwind stop function, 0 if not
> forced */
> >> +uint32_t reserved2; /* personality routine */
> >> +uint32_t reserved3; /* callsite */
> >> +uint32_t reserved4; /* forced unwind stop argument */
> >> +uint32_t reserved5;
> >> +  } unwinder_cache;
> >> +  /* propagation barrier cache (valid after phase 1) */
> >> +  struct {
> >> +uint32_t sp;
> >> +uint32_t bitpattern[5];
> >> +  } barrier_cache;
> >> +  /* cleanup cache (preserved over cleanup) */
> >> +  struct {
> >> +uint32_t bitpattern[4];
> >> +  } cleanup_cache;
> >> +  /* personality cache (for personality's benefit) */
> >> +  struct {
> >> +uint32_t fnstart; /* function start address */
> >> +_Unwind_EHT_Header *ehtp; /* pointer to EHT entry header word */
> >> +uint32_t additional;  /* additional data */
> >> +uint32_t reserved1;
> >> +  } pr_cache;
> >> +  long long int : 0; /* force alignment of next item to 8-byte
> boundary */
> >> +};
> >> +#else
> >>  struct _Unwind_Exception {
> >>_Unwind_Exception_Class exception_class;
> >>_Unwind_Exception_Cleanup_Fn exception_cleanup;
> >> @@ -120,16 +160,18 @@ struct _Unwind_Exception {
> >> * aligned".  GCC

[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-12 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 10 inline comments as done.
yaxunl added inline comments.



Comment at: include/clang/Basic/SyncScope.h:46
+  Scopes.push_back(SyncScope::OpenCLSubGroup);
+  return Scopes;
+}

rjmccall wrote:
> t-tye wrote:
> > Should there be an assert/static_assert in case SyncScope enum grows due to 
> > other languages?
> It makes sense to add a 'last' enumerator to SyncScope and do a static_assert 
> here that last == OpenCLSubGroup.
Thanks. Will do.



Comment at: include/clang/Basic/SyncScope.h:47
+  return Scopes;
+}
+

rjmccall wrote:
> You could just return an ArrayRef to a static const array.
Thanks. Will do.



Comment at: include/clang/Basic/SyncScope.h:59
+return "opencl_subgroup";
+  }
+}

rjmccall wrote:
> t-tye wrote:
> > Should there be a default/assert/static_assert to allow SyncScope enum to 
> > grow due to other languages?
> There will already be a warning from -Wswitch about this, which should be 
> sufficient.
> 
> But we do often add llvm_unreachable after switches like this.
I tried adding

```
default:
llvm_unreachable("Invalid sync scope");
```

However, it results in error:

```
 error: default label in switch which covers all enumeration values 
[-Werror,-Wcovered-switch-default]
```
I guess I'd better leave it as it is since we already have -Wswitch.



Comment at: lib/CodeGen/CGAtomic.cpp:687
+
+  auto *SC = Builder.CreateIntCast(Scope, Builder.getInt32Ty(), false);
+  // If unsupported sync scope is encountered at run time, assume default sync

rjmccall wrote:
> Does Sema not coerce the argument to int?  It really should, and then you can 
> just rely on that here.  (You should use CGF.IntTy if you do this, though, in 
> case you're on a target with a non-32-bit int.)
It is coerced to `Context.IntTy`. I will add some tests for non-integral 
order/scope argument.



Comment at: lib/CodeGen/CGAtomic.cpp:696
+if (S != Default)
+  SI->addCase(Builder.getInt32(static_cast(S)), B);
+

rjmccall wrote:
> t-tye wrote:
> > rjmccall wrote:
> > > t-tye wrote:
> > > > Is it documented in the SyncScope enum that the enumerator values are 
> > > > in fact the values used for source language runtime values? Seems if 
> > > > other languages want to use scopes they may may have a different 
> > > > ordering. That would imply that there would be a function to map a 
> > > > SyncScope value to the value used by the source language. For OpenCL 
> > > > the mapping is identity.
> > > > 
> > > > The memory ordering has the isValidAtomicOrderingCABI() that does a 
> > > > similar thing.
> > > The values in the SyncScope enum are the source language values.  We 
> > > already have a step to translate them into LLVM values when we generate a 
> > > native LLVM construct.  To the extent that we call into a runtime 
> > > instead, none of that code has been written to be runtime-agnostic at 
> > > all, and I've been assuming that we're basically okay with that, at least 
> > > for now.
> > That sounds reasonable to me. When/if another language comes along the task 
> > of mapping the multiple ABIs can be done then. Still wanted to make sure it 
> > is clear that the enum values in the SyncScope enum are documented as BEING 
> > the OpenCL runtime ABI values and not some arbitrary list as in other enums 
> > such as the address space enum. 
> They are documented as being the values expected by the builtins, so they 
> already can't be arbitrarily changed.
> 
> Now, the values expected by the builtin were chosen to match this specific 
> runtime, but we had to choose something, and matching a runtime isn't the 
> worst way of doing that.  But now that I think about it, those values seem to 
> be rather sub-optimal because they don't start at 0, which means that things 
> like this switch will be less efficient than they could be.  And I think the 
> AST and IRGen would benefit from needing to renumber values; it will make the 
> code clearer, and it'll help protect against people adding values to this 
> enum just because those values are used by the runtime, i.e. without fully 
> realizing that they're expanding a user-facing feature.  So let's go ahead 
> and renumber the values in SyncScope to start at 0 and then re-map them in 
> IRGen.
Will do. Thanks.


https://reviews.llvm.org/D36580



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r310783 - Fix Wdocumentation warning - typo in argument list. NFCI.

2017-08-12 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Sat Aug 12 11:50:53 2017
New Revision: 310783

URL: http://llvm.org/viewvc/llvm-project?rev=310783&view=rev
Log:
Fix Wdocumentation warning - typo in argument list. NFCI.

Modified:
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h

Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h?rev=310783&r1=310782&r2=310783&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h Sat Aug 12 
11:50:53 2017
@@ -52,7 +52,7 @@ protected:
   /// \param MacroFlag The macro name of the flag.
   /// \param ArgPos The 0-based position of the flag argument.
   void insertMacroFlag(const ast_matchers::MatchFinder::MatchResult &Result,
-   StringRef MarcoFlag, int ArgPos);
+   StringRef MacroFlag, int ArgPos);
 
   /// Type2 is to replace the API to another function that has required the
   /// ability. For example:


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D29660: [OpenMP] Add flag for overwriting default PTX version for OpenMP targets

2017-08-12 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea added a comment.

In https://reviews.llvm.org/D29660#839736, @alekseyshl wrote:

> In https://reviews.llvm.org/D29660#839728, @alekseyshl wrote:
>
> > In https://reviews.llvm.org/D29660#839550, @alekseyshl wrote:
> >
> > > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7109 
> > > failed on r310718, please fix.
> >
> >
> >
> >
> > In https://reviews.llvm.org/D29660#839647, @gtbercea wrote:
> >
> > > In https://reviews.llvm.org/D29660#839550, @alekseyshl wrote:
> > >
> > > > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7109
> > > >  failed on r310718, please fix.
> > >
> > >
> > > Couldn't fix/find the actual error so for now, just moving the flag patch 
> > > tests to openmp-offload-gpu.c which is a disabled test.
> > >
> > > 310765
> >
> >
> > Bad news, the bot is still red: 
> > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7114
>
>
> Disabled openmp-offload.c on Linux again: https://reviews.llvm.org/rL310772


How am I supposed to run the script you suggested?

I keep getting svn errors:

svn: E175002: Unexpected HTTP status 413 'Request Entity Too Large' on 
'/svn/llvm-project/!svn/vcc/default'


Repository:
  rL LLVM

https://reviews.llvm.org/D29660



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r310778 - clang-format: add an option -verbose to list the files being processed

2017-08-12 Thread Sylvestre Ledru via cfe-commits
Author: sylvestre
Date: Sat Aug 12 08:15:10 2017
New Revision: 310778

URL: http://llvm.org/viewvc/llvm-project?rev=310778&view=rev
Log:
clang-format: add an option -verbose to list the files being processed

Reviewers: djasper

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D34824

Added:
cfe/trunk/test/Format/verbose.cpp
Modified:
cfe/trunk/docs/ClangFormat.rst
cfe/trunk/docs/ReleaseNotes.rst
cfe/trunk/tools/clang-format/ClangFormat.cpp

Modified: cfe/trunk/docs/ClangFormat.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangFormat.rst?rev=310778&r1=310777&r2=310778&view=diff
==
--- cfe/trunk/docs/ClangFormat.rst (original)
+++ cfe/trunk/docs/ClangFormat.rst Sat Aug 12 08:15:10 2017
@@ -71,6 +71,7 @@ to format C/C++/Obj-C code.
 Use -style="{key: value, ...}" to set specific
 parameters, e.g.:
   -style="{BasedOnStyle: llvm, IndentWidth: 8}"
+-verbose  - If set, shows the list of processed files
 
   Generic Options:
 

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=310778&r1=310777&r2=310778&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Sat Aug 12 08:15:10 2017
@@ -187,6 +187,9 @@ clang-format
 
 ...
 
+* Option -verbose added to the command line.
+  Shows the list of processed files.
+
 libclang
 
 

Added: cfe/trunk/test/Format/verbose.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/verbose.cpp?rev=310778&view=auto
==
--- cfe/trunk/test/Format/verbose.cpp (added)
+++ cfe/trunk/test/Format/verbose.cpp Sat Aug 12 08:15:10 2017
@@ -0,0 +1,16 @@
+// RUN: clang-format %s  2> %t.stderr
+// RUN: not grep "Formatting" %t.stderr
+// RUN: clang-format %s -verbose 2> %t.stderr
+// RUN: grep -E "Formatting (.*)verbose.cpp(.*)" %t.stderr
+// RUN: clang-format %s -verbose=false 2> %t.stderr
+// RUN: not grep "Formatting" %t.stderr
+
+int a;
+// RUN: clang-format %s  2> %t.stderr
+// RUN: not grep "Formatting" %t.stderr
+// RUN: clang-format %s -verbose 2> %t.stderr
+// RUN: grep -E "Formatting (.*)verbose.cpp(.*)" %t.stderr
+// RUN: clang-format %s -verbose=false 2> %t.stderr
+// RUN: not grep "Formatting" %t.stderr
+
+int a;

Modified: cfe/trunk/tools/clang-format/ClangFormat.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/ClangFormat.cpp?rev=310778&r1=310777&r2=310778&view=diff
==
--- cfe/trunk/tools/clang-format/ClangFormat.cpp (original)
+++ cfe/trunk/tools/clang-format/ClangFormat.cpp Sat Aug 12 08:15:10 2017
@@ -102,6 +102,10 @@ static cl::opt SortIncludes(
  "SortIncludes style flag"),
 cl::cat(ClangFormatCategory));
 
+static cl::opt
+Verbose("verbose", cl::desc("If set, shows the list of processed files"),
+cl::cat(ClangFormatCategory));
+
 static cl::list FileNames(cl::Positional, cl::desc("[ 
...]"),
cl::cat(ClangFormatCategory));
 
@@ -365,23 +369,19 @@ int main(int argc, const char **argv) {
   }
 
   bool Error = false;
-  switch (FileNames.size()) {
-  case 0:
+  if (FileNames.empty()) {
 Error = clang::format::format("-");
-break;
-  case 1:
-Error = clang::format::format(FileNames[0]);
-break;
-  default:
-if (!Offsets.empty() || !Lengths.empty() || !LineRanges.empty()) {
-  errs() << "error: -offset, -length and -lines can only be used for "
-"single file.\n";
-  return 1;
-}
-for (unsigned i = 0; i < FileNames.size(); ++i)
-  Error |= clang::format::format(FileNames[i]);
-break;
+return Error ? 1 : 0;
+  }
+  if (FileNames.size() != 1 && (!Offsets.empty() || !Lengths.empty() || 
!LineRanges.empty())) {
+errs() << "error: -offset, -length and -lines can only be used for "
+  "single file.\n";
+return 1;
+  }
+  for (const auto &FileName : FileNames) {
+if (Verbose)
+  errs() << "Formatting " << FileName << "\n";
+Error |= clang::format::format(FileName);
   }
   return Error ? 1 : 0;
 }
-


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D34824: clang-format: add an option -verbose to list the files being processed

2017-08-12 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru reopened this revision.
sylvestre.ledru added a comment.
This revision is now accepted and ready to land.

actually, arc commit never landed this change :(


https://reviews.llvm.org/D34824



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits