r287628 - Rename option to -lto-pass-remarks-output

[Adam Nemet via cfe-commits]

Author: anemet
Date: Tue Nov 22 01:35:19 2016
New Revision: 287628

URL: http://llvm.org/viewvc/llvm-project?rev=287628=rev
Log:
Rename option to -lto-pass-remarks-output

The new option -pass-remarks-output broke LLVM_LINK_LLVM_DYLIB because
of the duplicate option name with opt.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/darwin-ld.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=287628=287627=287628=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Nov 22 01:35:19 2016
@@ -8426,7 +8426,7 @@ void darwin::Linker::ConstructJob(Compil
   if (Args.hasFlag(options::OPT_fsave_optimization_record,
options::OPT_fno_save_optimization_record, false)) {
 CmdArgs.push_back("-mllvm");
-CmdArgs.push_back("-pass-remarks-output");
+CmdArgs.push_back("-lto-pass-remarks-output");
 CmdArgs.push_back("-mllvm");
 
 SmallString<128> F;

Modified: cfe/trunk/test/Driver/darwin-ld.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld.c?rev=287628=287627=287628=diff
==
--- cfe/trunk/test/Driver/darwin-ld.c (original)
+++ cfe/trunk/test/Driver/darwin-ld.c Tue Nov 22 01:35:19 2016
@@ -328,11 +328,11 @@
 // LINK_VERSION_DIGITS: invalid version number in 
'-mlinker-version=133.3.0.1.a'
 // LINK_VERSION_DIGITS: invalid version number in '-mlinker-version=133.3.0.1a'
 
-// Check that we're passing -pass-remarks-output for LTO
+// Check that we're passing -lto-pass-remarks-output for LTO
 // RUN: %clang -target x86_64-apple-darwin12 %t.o -fsave-optimization-record 
-### -o foo/bar.out 2> %t.log
 // RUN: FileCheck -check-prefix=PASS_REMARKS_OUTPUT %s < %t.log
-// PASS_REMARKS_OUTPUT: "-mllvm" "-pass-remarks-output" "-mllvm" 
"foo/bar.out.opt.yaml"
+// PASS_REMARKS_OUTPUT: "-mllvm" "-lto-pass-remarks-output" "-mllvm" 
"foo/bar.out.opt.yaml"
 
 // RUN: %clang -target x86_64-apple-darwin12 %t.o -fsave-optimization-record 
-### 2> %t.log
 // RUN: FileCheck -check-prefix=PASS_REMARKS_OUTPUT_NO_O %s < %t.log
-// PASS_REMARKS_OUTPUT_NO_O: "-mllvm" "-pass-remarks-output" "-mllvm" 
"a.out.opt.yaml"
+// PASS_REMARKS_OUTPUT_NO_O: "-mllvm" "-lto-pass-remarks-output" "-mllvm" 
"a.out.opt.yaml"


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

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi Amini via cfe-commits]

Double-checked on the latest binary release on llvm.org, it ships with 
clang+llvm-3.9.0-x86_64-apple-darwin/lib/libLTO.dylib

I also can’t find any CMake option that disable LTO support at build time for 
clang.


> On Nov 21, 2016, at 9:53 PM, Mehdi Amini via cfe-commits 
>  wrote:
> 
> AFAIK any clang build open-source ships with libLTO.
> Not having libLTO built with clang is a Chromium oddity, unless I missed the 
> obvious somewhere.
> 
> 
>> On Nov 21, 2016, at 9:50 PM, Nico Weber > > wrote:
>> 
>> In what way is this chromium specific? It's "all non-xcode uses of clang on 
>> mac", no?
>> 
>> 
>> On Nov 21, 2016 7:29 PM, "Mehdi Amini" > > wrote:
>> 
>>> On Nov 21, 2016, at 2:44 PM, Nico Weber >> > wrote:
>>> 
>>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini >> > wrote:
>>> 
 On Nov 21, 2016, at 2:27 PM, Nico Weber > wrote:
 
 On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits 
 > wrote:
 mehdi_amini added a comment.
 
 In https://reviews.llvm.org/D25932#601842 
 , @rnk wrote:
 
 > In https://reviews.llvm.org/D25932#601820 
 > , @mehdi_amini wrote:
 >
 > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if 
 > > you don't package libLTO yourself, it is already accessible from the 
 > > linker: it will use the one in the toolchain when needed.
 > >
 > > I don't have an immediate idea to prevent this and have the linker 
 > > issue an error (other than removing manually libLTO from the Xcode 
 > > installation).
 >
 >
 > So, even if clang doesn't pass -lto_library to ld64, ld64 will 
 > auto-discover the bundled libLTO that happens to be next to it? That 
 > could go badly.
 
 
 Right: until LLVM 3.8, clang was *never* passing the `-lto_library` 
 option. The only way to have your own libLTO used by ld64 instead of the 
 one in the Xcode toolchain was setting the environment variable 
 "DYLD_LIBRARY_PATH".
 Of course was has many issues, and that's what lead us to have clang 
 passing this option to ld64. Initially only when the driver was invoked 
 with -flto, but recently I had issues with clients that didn't use LTO 
 themselves but were having static archives they depend on that were 
 containing bitcode.
 
 Where those archives system libraries, or other things?
>>> 
>>> We have two cases:
>>> 
>>> 1) Internal teams producing libraries in an internal SDK with LTO enabled, 
>>> and other teams consuming these libraries and linking to the framework. It 
>>> seems also something that people out-in-the-wild are doing according to 
>>> some bug reports.
>>> 2) Any Xcode user that have a somehow complex project which is split in 
>>> multiple targets. Xcode can’t tell clang from one target that it is linking 
>>> with LTO even if LTO is disabled just because another dependency has LTO 
>>> enabled. And sometimes Xcode is only seeing static archive as an input 
>>> anyway.
>>> 
>>> It sounds like this is a pure regression for us then.
>> 
>> Right, for you "downstream consumer of clang in chromium”.
>> 
>>> Since 'it never "hurt" to pass it' isn't true (every link invocation done 
>>> by the driver now prints a warning), maybe this should be reverted until 
>>> there's some better approach?
>>> Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib 
>>> (while clever) seems pretty unfortunate.
>> 
>> Is there a CMake invocation that disable libLTO today and allow to run “make 
>> install” and produce a distribution of clang without libLTO?
>> 
>> If not, then I’m against reverting this because I consider your Chromium 
>> specific incorrect with respect to the support upstream. And I’m fine having 
>> it supported in the future, but you should make it supported, for instance 
>> with a cmake option (if the cmake option already exists, I haven’t checked, 
>> then we could conditionally compile-out the warning based on it).
>> 
>> — 
>> Mehdi
>> 
>> 
>> 
>> 
>>>  
>>> 
 Maybe clang could sniff archives for bitcode and pass only -flto in that 
 case?
>>> 
>>> That seems like a possibility. It’d have to resolve paths to the static 
>>> archives, which it doesn’t do right now I believe (they can be resolved 
>>> with `-Lpath -lfoo`).
>>> 
>>> — 
>>> Mehdi
>> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

___

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi Amini via cfe-commits]

AFAIK any clang build open-source ships with libLTO.
Not having libLTO built with clang is a Chromium oddity, unless I missed the 
obvious somewhere.


> On Nov 21, 2016, at 9:50 PM, Nico Weber  wrote:
> 
> In what way is this chromium specific? It's "all non-xcode uses of clang on 
> mac", no?
> 
> 
> On Nov 21, 2016 7:29 PM, "Mehdi Amini"  > wrote:
> 
>> On Nov 21, 2016, at 2:44 PM, Nico Weber > > wrote:
>> 
>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini > > wrote:
>> 
>>> On Nov 21, 2016, at 2:27 PM, Nico Weber >> > wrote:
>>> 
>>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits 
>>> > wrote:
>>> mehdi_amini added a comment.
>>> 
>>> In https://reviews.llvm.org/D25932#601842 
>>> , @rnk wrote:
>>> 
>>> > In https://reviews.llvm.org/D25932#601820 
>>> > , @mehdi_amini wrote:
>>> >
>>> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if 
>>> > > you don't package libLTO yourself, it is already accessible from the 
>>> > > linker: it will use the one in the toolchain when needed.
>>> > >
>>> > > I don't have an immediate idea to prevent this and have the linker 
>>> > > issue an error (other than removing manually libLTO from the Xcode 
>>> > > installation).
>>> >
>>> >
>>> > So, even if clang doesn't pass -lto_library to ld64, ld64 will 
>>> > auto-discover the bundled libLTO that happens to be next to it? That 
>>> > could go badly.
>>> 
>>> 
>>> Right: until LLVM 3.8, clang was *never* passing the `-lto_library` option. 
>>> The only way to have your own libLTO used by ld64 instead of the one in the 
>>> Xcode toolchain was setting the environment variable "DYLD_LIBRARY_PATH".
>>> Of course was has many issues, and that's what lead us to have clang 
>>> passing this option to ld64. Initially only when the driver was invoked 
>>> with -flto, but recently I had issues with clients that didn't use LTO 
>>> themselves but were having static archives they depend on that were 
>>> containing bitcode.
>>> 
>>> Where those archives system libraries, or other things?
>> 
>> We have two cases:
>> 
>> 1) Internal teams producing libraries in an internal SDK with LTO enabled, 
>> and other teams consuming these libraries and linking to the framework. It 
>> seems also something that people out-in-the-wild are doing according to some 
>> bug reports.
>> 2) Any Xcode user that have a somehow complex project which is split in 
>> multiple targets. Xcode can’t tell clang from one target that it is linking 
>> with LTO even if LTO is disabled just because another dependency has LTO 
>> enabled. And sometimes Xcode is only seeing static archive as an input 
>> anyway.
>> 
>> It sounds like this is a pure regression for us then.
> 
> Right, for you "downstream consumer of clang in chromium”.
> 
>> Since 'it never "hurt" to pass it' isn't true (every link invocation done by 
>> the driver now prints a warning), maybe this should be reverted until 
>> there's some better approach?
>> Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib (while 
>> clever) seems pretty unfortunate.
> 
> Is there a CMake invocation that disable libLTO today and allow to run “make 
> install” and produce a distribution of clang without libLTO?
> 
> If not, then I’m against reverting this because I consider your Chromium 
> specific incorrect with respect to the support upstream. And I’m fine having 
> it supported in the future, but you should make it supported, for instance 
> with a cmake option (if the cmake option already exists, I haven’t checked, 
> then we could conditionally compile-out the warning based on it).
> 
> — 
> Mehdi
> 
> 
> 
> 
>>  
>> 
>>> Maybe clang could sniff archives for bitcode and pass only -flto in that 
>>> case?
>> 
>> That seems like a possibility. It’d have to resolve paths to the static 
>> archives, which it doesn’t do right now I believe (they can be resolved with 
>> `-Lpath -lfoo`).
>> 
>> — 
>> Mehdi
> 

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

Re: [PATCH] D26944: Suppress -Wliblto warning when -flto is not present

[Mehdi Amini via cfe-commits]

FYI, doesn’t look good to me, cf what I described on the other thread.

> On Nov 21, 2016, at 9:51 PM, Nico Weber  wrote:
> 
> Lgtm, works for me. Seems like a good compromise.
> 
> 
> On Nov 21, 2016 6:29 PM, "Reid Kleckner"  > wrote:
> rnk created this revision.
> rnk added reviewers: mehdi_amini, thakis.
> rnk added a subscriber: cfe-commits.
> 
> Without -flto, it's unlikely that users will experience LLVM version
> skew. The system installation of libLTO should be able to handle any
> pre-compiled LLVM bitcode from static archives.
> 
> 
> https://reviews.llvm.org/D26944 
> 
> Files:
>   lib/Driver/Tools.cpp
>   test/Driver/darwin-ld-lto.c
> 
> 
> Index: test/Driver/darwin-ld-lto.c
> ===
> --- test/Driver/darwin-ld-lto.c
> +++ test/Driver/darwin-ld-lto.c
> @@ -1,5 +1,3 @@
> -// REQUIRES: system-darwin
> -
>  // Check that ld gets "-lto_library" and warnings about libLTO.dylib path.
> 
>  // RUN: mkdir -p %T/bin
> @@ -12,12 +10,20 @@
>  // LINK_LTOLIB_PATH: {{ld(.exe)?"}}
>  // LINK_LTOLIB_PATH: "-lto_library"
> 
> -// RUN: %clang -target x86_64-apple-darwin10 -### %s \
> +// Only warn if -flto is on the command line.
> +//
> +// RUN: %clang -target x86_64-apple-darwin10 -### %s -flto \
>  // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
>  // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_WRN %s -input-file %t.log
>  //
>  // LINK_LTOLIB_PATH_WRN: warning: libLTO.dylib relative to clang installed 
> dir not found; using 'ld' default search path instead
> 
> +// Don't warn if -flto isn't present of -Wno-liblto is present.
> +//
> +// RUN: %clang -target x86_64-apple-darwin10 -### %s \
> +// RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
> +// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file %t.log
> +//
>  // RUN: %clang -target x86_64-apple-darwin10 -### %s \
>  // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 -Wno-liblto 
> 2> %t.log
>  // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file %t.log
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -8232,7 +8232,9 @@
>  if (llvm::sys::fs::exists(LibLTOPath)) {
>CmdArgs.push_back("-lto_library");
>CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
> -} else {
> +} else if (D.isUsingLTO()) {
> +  // Warn if we're using LTO with the system version of libLTO. It might 
> not
> +  // understand LLVM bitcode generated by our version of LLVM.
>D.Diag(diag::warn_drv_lto_libpath);
>  }
>}
> 
> 

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

Re: [PATCH] D26944: Suppress -Wliblto warning when -flto is not present

[Nico Weber via cfe-commits]

Lgtm, works for me. Seems like a good compromise.

On Nov 21, 2016 6:29 PM, "Reid Kleckner"  wrote:

> rnk created this revision.
> rnk added reviewers: mehdi_amini, thakis.
> rnk added a subscriber: cfe-commits.
>
> Without -flto, it's unlikely that users will experience LLVM version
> skew. The system installation of libLTO should be able to handle any
> pre-compiled LLVM bitcode from static archives.
>
>
> https://reviews.llvm.org/D26944
>
> Files:
>   lib/Driver/Tools.cpp
>   test/Driver/darwin-ld-lto.c
>
>
> Index: test/Driver/darwin-ld-lto.c
> ===
> --- test/Driver/darwin-ld-lto.c
> +++ test/Driver/darwin-ld-lto.c
> @@ -1,5 +1,3 @@
> -// REQUIRES: system-darwin
> -
>  // Check that ld gets "-lto_library" and warnings about libLTO.dylib path.
>
>  // RUN: mkdir -p %T/bin
> @@ -12,12 +10,20 @@
>  // LINK_LTOLIB_PATH: {{ld(.exe)?"}}
>  // LINK_LTOLIB_PATH: "-lto_library"
>
> -// RUN: %clang -target x86_64-apple-darwin10 -### %s \
> +// Only warn if -flto is on the command line.
> +//
> +// RUN: %clang -target x86_64-apple-darwin10 -### %s -flto \
>  // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
>  // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_WRN %s -input-file
> %t.log
>  //
>  // LINK_LTOLIB_PATH_WRN: warning: libLTO.dylib relative to clang
> installed dir not found; using 'ld' default search path instead
>
> +// Don't warn if -flto isn't present of -Wno-liblto is present.
> +//
> +// RUN: %clang -target x86_64-apple-darwin10 -### %s \
> +// RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
> +// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file
> %t.log
> +//
>  // RUN: %clang -target x86_64-apple-darwin10 -### %s \
>  // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133
> -Wno-liblto 2> %t.log
>  // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file
> %t.log
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -8232,7 +8232,9 @@
>  if (llvm::sys::fs::exists(LibLTOPath)) {
>CmdArgs.push_back("-lto_library");
>CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
> -} else {
> +} else if (D.isUsingLTO()) {
> +  // Warn if we're using LTO with the system version of libLTO. It
> might not
> +  // understand LLVM bitcode generated by our version of LLVM.
>D.Diag(diag::warn_drv_lto_libpath);
>  }
>}
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Nico Weber via cfe-commits]

In what way is this chromium specific? It's "all non-xcode uses of clang on
mac", no?

On Nov 21, 2016 7:29 PM, "Mehdi Amini"  wrote:

>
> On Nov 21, 2016, at 2:44 PM, Nico Weber  wrote:
>
> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini 
> wrote:
>
>>
>> On Nov 21, 2016, at 2:27 PM, Nico Weber  wrote:
>>
>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> mehdi_amini added a comment.
>>>
>>> In https://reviews.llvm.org/D25932#601842, @rnk wrote:
>>>
>>> > In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote:
>>> >
>>> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if
>>> you don't package libLTO yourself, it is already accessible from the
>>> linker: it will use the one in the toolchain when needed.
>>> > >
>>> > > I don't have an immediate idea to prevent this and have the linker
>>> issue an error (other than removing manually libLTO from the Xcode
>>> installation).
>>> >
>>> >
>>> > So, even if clang doesn't pass -lto_library to ld64, ld64 will
>>> auto-discover the bundled libLTO that happens to be next to it? That could
>>> go badly.
>>>
>>>
>>> Right: until LLVM 3.8, clang was *never* passing the `-lto_library`
>>> option. The only way to have your own libLTO used by ld64 instead of the
>>> one in the Xcode toolchain was setting the environment variable
>>> "DYLD_LIBRARY_PATH".
>>> Of course was has many issues, and that's what lead us to have clang
>>> passing this option to ld64. Initially only when the driver was invoked
>>> with -flto, but recently I had issues with clients that didn't use LTO
>>> themselves but were having static archives they depend on that were
>>> containing bitcode.
>>>
>>
>> Where those archives system libraries, or other things?
>>
>>
>> We have two cases:
>>
>> 1) Internal teams producing libraries in an internal SDK with LTO
>> enabled, and other teams consuming these libraries and linking to the
>> framework. It seems also something that people out-in-the-wild are doing
>> according to some bug reports.
>> 2) Any Xcode user that have a somehow complex project which is split in
>> multiple targets. Xcode can’t tell clang from one target that it is linking
>> with LTO even if LTO is disabled just because another dependency has LTO
>> enabled. And sometimes Xcode is only seeing static archive as an input
>> anyway.
>>
>
> It sounds like this is a pure regression for us then.
>
>
> Right, for you "downstream consumer of clang in chromium”.
>
> Since 'it never "hurt" to pass it' isn't true (every link invocation done
> by the driver now prints a warning), maybe this should be reverted until
> there's some better approach?
>
> Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib
> (while clever) seems pretty unfortunate.
>
>
> Is there a CMake invocation that disable libLTO today and allow to run
> “make install” and produce a distribution of clang without libLTO?
>
> If not, then I’m against reverting this because I consider your Chromium
> specific incorrect with respect to the support upstream. And I’m fine
> having it supported in the future, but you should make it supported, for
> instance with a cmake option (if the cmake option already exists, I haven’t
> checked, then we could conditionally compile-out the warning based on it).
>
> —
> Mehdi
>
>
>
>
>
>
>>
>> Maybe clang could sniff archives for bitcode and pass only -flto in that
>> case?
>>
>>
>> That seems like a possibility. It’d have to resolve paths to the static
>> archives, which it doesn’t do right now I believe (they can be resolved
>> with `-Lpath -lfoo`).
>>
>> —
>> Mehdi
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r287618 - [analyzer] Fix a crash on accessing a field within a literal-initialized union.

[Artem Dergachev via cfe-commits]

Author: dergachev
Date: Mon Nov 21 22:29:23 2016
New Revision: 287618

URL: http://llvm.org/viewvc/llvm-project?rev=287618=rev
Log:
[analyzer] Fix a crash on accessing a field within a literal-initialized union.

Because in case of unions we currently default-bind compound values in the
store, this quick fix avoids the crash for this case.

Patch by Ilya Palachev and independently by Alexander Shaposhnikov!

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

Added:
cfe/trunk/test/Analysis/uninit-vals-union.c
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp?rev=287618=287617=287618=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp Mon Nov 21 22:29:23 2016
@@ -1674,7 +1674,8 @@ RegionStoreManager::getBindingForDerived
 
 // Lazy bindings are usually handled through getExistingLazyBinding().
 // We should unify these two code paths at some point.
-if (val.getAs())
+if (val.getAs() ||
+val.getAs())
   return val;
 
 llvm_unreachable("Unknown default value");

Added: cfe/trunk/test/Analysis/uninit-vals-union.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/uninit-vals-union.c?rev=287618=auto
==
--- cfe/trunk/test/Analysis/uninit-vals-union.c (added)
+++ cfe/trunk/test/Analysis/uninit-vals-union.c Mon Nov 21 22:29:23 2016
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core.builtin 
-analyzer-store=region -verify -Wno-unused %s
+
+typedef union {
+  int y;
+} U;
+
+typedef struct { int x; } A;
+
+void foo() {
+  U u = {};
+  A *a =  // expected-warning{{incompatible pointer types}}
+  a->x;  // no-crash
+}


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

[PATCH] D26442: [analyzer] Fix crash on getSVal: handle case of CompoundVal

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL287618: [analyzer] Fix a crash on accessing a field within a 
literal-initialized union. (authored by dergachev).

Changed prior to commit:
  https://reviews.llvm.org/D26442?vs=77316=78826#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D26442

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
  cfe/trunk/test/Analysis/uninit-vals-union.c


Index: cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1674,7 +1674,8 @@
 
 // Lazy bindings are usually handled through getExistingLazyBinding().
 // We should unify these two code paths at some point.
-if (val.getAs())
+if (val.getAs() ||
+val.getAs())
   return val;
 
 llvm_unreachable("Unknown default value");
Index: cfe/trunk/test/Analysis/uninit-vals-union.c
===
--- cfe/trunk/test/Analysis/uninit-vals-union.c
+++ cfe/trunk/test/Analysis/uninit-vals-union.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core.builtin 
-analyzer-store=region -verify -Wno-unused %s
+
+typedef union {
+  int y;
+} U;
+
+typedef struct { int x; } A;
+
+void foo() {
+  U u = {};
+  A *a =  // expected-warning{{incompatible pointer types}}
+  a->x;  // no-crash
+}


Index: cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1674,7 +1674,8 @@
 
 // Lazy bindings are usually handled through getExistingLazyBinding().
 // We should unify these two code paths at some point.
-if (val.getAs())
+if (val.getAs() ||
+val.getAs())
   return val;
 
 llvm_unreachable("Unknown default value");
Index: cfe/trunk/test/Analysis/uninit-vals-union.c
===
--- cfe/trunk/test/Analysis/uninit-vals-union.c
+++ cfe/trunk/test/Analysis/uninit-vals-union.c
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core.builtin -analyzer-store=region -verify -Wno-unused %s
+
+typedef union {
+  int y;
+} U;
+
+typedef struct { int x; } A;
+
+void foo() {
+  U u = {};
+  A *a =  // expected-warning{{incompatible pointer types}}
+  a->x;  // no-crash
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26903: [libcxx] Add tests (but not implementation)

[Eric Fiselier via cfe-commits]

EricWF added a comment.

Thanks guys! I'll address all these tomorrow!


https://reviews.llvm.org/D26903



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

[PATCH] D26955: Fix bitwidth for x87 extended-precision floating-point type

[Dominic Chen via cfe-commits]

ddcc added a comment.

I could be completely mistaken here, but currently 
`Ctx.getRealTypeForBitwidth(llvm::APFloat::getSizeInBits(llvm::APFloat::x87DoubleExtended))`
 with a `ASTContext Ctx` does not round-trip correctly.


https://reviews.llvm.org/D26955



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

[PATCH] D26955: Fix bitwidth for x87 extended-precision floating-point type

[Dominic Chen via cfe-commits]

ddcc created this revision.
ddcc added a reviewer: rsmith.
ddcc added a subscriber: cfe-commits.

llvm::APFloat::x87DoubleExtended is defined as having 80 bits of size


https://reviews.llvm.org/D26955

Files:
  lib/Basic/TargetInfo.cpp


Index: lib/Basic/TargetInfo.cpp
===
--- lib/Basic/TargetInfo.cpp
+++ lib/Basic/TargetInfo.cpp
@@ -226,7 +226,7 @@
 return Double;
 
   switch (BitWidth) {
-  case 96:
+  case 80:
 if (() == ::APFloat::x87DoubleExtended)
   return LongDouble;
 break;


Index: lib/Basic/TargetInfo.cpp
===
--- lib/Basic/TargetInfo.cpp
+++ lib/Basic/TargetInfo.cpp
@@ -226,7 +226,7 @@
 return Double;
 
   switch (BitWidth) {
-  case 96:
+  case 80:
 if (() == ::APFloat::x87DoubleExtended)
   return LongDouble;
 break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26953: clang-format: handle formatting on constexpr if

[Visoiu Mistrih Francis via cfe-commits]

thegameg created this revision.
thegameg added reviewers: djasper, mprobst, ioeric, klimek.
thegameg added a subscriber: cfe-commits.

c++1z adds the following constructions to the language:

if constexpr (cond)

  statement1;

else if constexpr (cond)

  statement2;

else if constexpr (cond)

  statement3;

else

  statement4;

so clang-format needs to accept the `constexpr` keyword after the `if`
keyword.

- lib/Format/TokenAnnotator.cpp: Handle Style.SpaceBeforeParens.
- lib/Format/UnwrappedLineParser.cpp: Skip the token when parsing

`ifThenElse`.

- unittests/Format/FormatTest.cpp: Tests.


https://reviews.llvm.org/D26953

Files:
  lib/Format/TokenAnnotator.cpp
  lib/Format/UnwrappedLineParser.cpp
  unittests/Format/FormatTest.cpp


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -11715,6 +11715,17 @@
"/* comment 3 */ \\\n",
getLLVMStyleWithColumns(40)));
 }
+
+TEST_F(FormatTest, ConstexprIf) {
+  EXPECT_EQ("if constexpr (3 > 4)",
+format("if constexpr(3 > 4)",
+   getLLVMStyle()));
+  EXPECT_EQ("if constexpr (3 > 4)",
+format("if \n"
+   "  constexpr(3 > 4)",
+   getLLVMStyle()));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UnwrappedLineParser.cpp
===
--- lib/Format/UnwrappedLineParser.cpp
+++ lib/Format/UnwrappedLineParser.cpp
@@ -1430,6 +1430,8 @@
 void UnwrappedLineParser::parseIfThenElse() {
   assert(FormatTok->Tok.is(tok::kw_if) && "'if' expected");
   nextToken();
+  if (FormatTok->Tok.is(tok::kw_constexpr))
+nextToken();
   if (FormatTok->Tok.is(tok::l_paren))
 parseParens();
   bool NeedsUnwrappedLine = false;
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2119,9 +2119,9 @@
   return true;
 return Line.Type == LT_ObjCDecl || Left.is(tok::semi) ||
(Style.SpaceBeforeParens != FormatStyle::SBPO_Never &&
-(Left.isOneOf(tok::kw_if, tok::pp_elif, tok::kw_for, tok::kw_while,
-  tok::kw_switch, tok::kw_case, TT_ForEachMacro,
-  TT_ObjCForIn) ||
+(Left.isOneOf(tok::kw_if, tok::kw_constexpr, tok::pp_elif,
+  tok::kw_for, tok::kw_while, tok::kw_switch,
+  tok::kw_case, TT_ForEachMacro, TT_ObjCForIn) ||
  (Left.isOneOf(tok::kw_try, Keywords.kw___except, tok::kw_catch,
tok::kw_new, tok::kw_delete) &&
   (!Left.Previous || Left.Previous->isNot(tok::period) ||


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -11715,6 +11715,17 @@
"/* comment 3 */ \\\n",
getLLVMStyleWithColumns(40)));
 }
+
+TEST_F(FormatTest, ConstexprIf) {
+  EXPECT_EQ("if constexpr (3 > 4)",
+format("if constexpr(3 > 4)",
+   getLLVMStyle()));
+  EXPECT_EQ("if constexpr (3 > 4)",
+format("if \n"
+   "  constexpr(3 > 4)",
+   getLLVMStyle()));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UnwrappedLineParser.cpp
===
--- lib/Format/UnwrappedLineParser.cpp
+++ lib/Format/UnwrappedLineParser.cpp
@@ -1430,6 +1430,8 @@
 void UnwrappedLineParser::parseIfThenElse() {
   assert(FormatTok->Tok.is(tok::kw_if) && "'if' expected");
   nextToken();
+  if (FormatTok->Tok.is(tok::kw_constexpr))
+nextToken();
   if (FormatTok->Tok.is(tok::l_paren))
 parseParens();
   bool NeedsUnwrappedLine = false;
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2119,9 +2119,9 @@
   return true;
 return Line.Type == LT_ObjCDecl || Left.is(tok::semi) ||
(Style.SpaceBeforeParens != FormatStyle::SBPO_Never &&
-(Left.isOneOf(tok::kw_if, tok::pp_elif, tok::kw_for, tok::kw_while,
-  tok::kw_switch, tok::kw_case, TT_ForEachMacro,
-  TT_ObjCForIn) ||
+(Left.isOneOf(tok::kw_if, tok::kw_constexpr, tok::pp_elif,
+  tok::kw_for, tok::kw_while, tok::kw_switch,
+  tok::kw_case, TT_ForEachMacro, TT_ObjCForIn) ||
  (Left.isOneOf(tok::kw_try, Keywords.kw___except, tok::kw_catch,
tok::kw_new, tok::kw_delete) &&
  

[PATCH] D26903: [libcxx] Add tests (but not implementation)

[Stephan T. Lavavej via cfe-commits]

STL_MSFT added a comment.

Found some minor issues.




Comment at: test/std/utilities/variant/variant.get/get_if_index.pass.cpp:92
+V v(42l);
+ASSERT_SAME_TYPE(decltype(std::get_if<1>(std::addressof(v))), long*);
+assert(*std::get_if<1>(std::addressof(v)) == 42);

Technically, addressof() lives in .



Comment at: test/std/utilities/variant/variant.get/get_if_type.pass.cpp:52
+const V v(x);
+ASSERT_SAME_TYPE(decltype(std::get_if(std::addressof(v))), int*);
+assert(std::get_if(std::addressof(v)) == );

 for addressof() (although I'll note that the other tests are saying 
).



Comment at: test/std/utilities/variant/variant.get/get_index.pass.cpp:176
+ASSERT_SAME_TYPE(decltype(std::get<0>(std::move(v))), const int&&);
+assert(std::get<0>(std::move(v)) == 42);
+}

Technically,  for move().



Comment at: test/std/utilities/variant/variant.get/get_index.pass.cpp:220
+template 
+using Idx = std::integral_constant;
+

 for integral_constant.



Comment at: test/std/utilities/variant/variant.get/get_type.pass.cpp:99
+int x = 42;
+V v(std::move(x));
+ASSERT_SAME_TYPE(decltype(std::get(v)), int&);

 move()



Comment at: test/std/utilities/variant/variant.hash/hash.pass.cpp:15
+
+// template  struct hash;
+// template <> struct hash;

"" has really terrible spacing. (Or as I like to say, "Space. 
The final frontier.")



Comment at: 
test/std/utilities/variant/variant.helpers/variant_alternative.pass.cpp:33
+void test() {
+static_assert(std::is_same_v<
+typename std::variant_alternative::type, E>, "");

You aren't directly including  (not sure if 
"variant_test_helpers.hpp" is).



Comment at: 
test/std/utilities/variant/variant.helpers/variant_alternative.pass.cpp:60
+}
+#if !defined(TEST_VARIANT_REFERENCES)
+{

The sense of this #if test seems to be flipped.



Comment at: test/std/utilities/variant/variant.helpers/variant_size.pass.cpp:20
+// template  constexpr size_t variant_size_v
+// = variant_size::value;
+

No indentation! :-<



Comment at: test/std/utilities/variant/variant.helpers/variant_size.pass.cpp:35
+static_assert(std::variant_size_v == E, "");
+static_assert(std::is_base_of,
+  std::variant_size>::value, "");

Need .



Comment at: test/std/utilities/variant/variant.helpers/variant_size.pass.cpp:41
+{
+test, 0>();
+test, 1>();

Hmm, is this cromulent now that empty variants are forbidden?



Comment at: test/std/utilities/variant/variant.monostate/monostate.pass.cpp:20
+#include 
+#include 
+

Don't actually need  since you have no plain asserts and this is C++17.



Comment at: test/std/utilities/variant/variant.relops/relops.pass.cpp:59
+inline bool operator<=(MakeEmptyT const&, MakeEmptyT const&) { assert(false); }
+inline bool operator>(MakeEmptyT const&, MakeEmptyT const&)  { assert(false); }
+inline bool operator>=(MakeEmptyT const&, MakeEmptyT const&) { assert(false); }

No space after >, but space after < above. Madness!



Comment at: test/std/utilities/variant/variant.relops/relops.pass.cpp:66
+try {
+v = std::move(v2);
+assert(false);

 move()



Comment at: 
test/std/utilities/variant/variant.variant/variant.assign/copy.pass.cpp:28
+struct NoCopy {
+  NoCopy(NoCopy const&) = delete;
+  NoCopy& operator=(NoCopy const&) = default;

NoCopy doesn't even have a default ctor, how are you supposed to make one? 
Appears to apply to the classes below.



Comment at: 
test/std/utilities/variant/variant.variant/variant.assign/move.pass.cpp:114
+{
+// variant only provides move assignment when beth the move and move
+// constructors are well formed

"beth". Also, "move and move constructors"?



Comment at: 
test/std/utilities/variant/variant.variant/variant.assign/move.pass.cpp:212
+V v2(42);
+V& vref = (v1 = std::move(v2));
+assert( == );

 move()



Comment at: 
test/std/utilities/variant/variant.variant/variant.ctor/T.pass.cpp:65
+}
+#if defined(VARIANT_TEST_REFERENCES)
+{

You have like twenty different macros for enabling references.



Comment at: 
test/std/utilities/variant/variant.variant/variant.ctor/in_place_index_init_list_Args.pass.cpp:1
+// -*- C++ -*-

[PATCH] D22862: [analyzer] Fix for PR15623: eliminate unwanted ProgramState checker data propagation.

[Anton Yartsev via cfe-commits]

ayartsev updated this revision to Diff 78810.
ayartsev added a comment.

The updated patch implements Devin's solution. Please review.


https://reviews.llvm.org/D22862

Files:
  lib/StaticAnalyzer/Core/ExprEngineC.cpp
  lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
  test/Analysis/unwanted-programstate-data-propagation.c


Index: test/Analysis/unwanted-programstate-data-propagation.c
===
--- test/Analysis/unwanted-programstate-data-propagation.c
+++ test/Analysis/unwanted-programstate-data-propagation.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyze 
-analyzer-checker=core,debug.ExprInspection,unix.Malloc -verify %s
+
+// test for PR15623
+#include "Inputs/system-header-simulator.h"
+
+void clang_analyzer_eval(int);
+
+typedef __typeof(sizeof(int)) size_t;
+void *malloc(size_t);
+void free(void *);
+
+int test1(void) {
+   char *param = malloc(10);
+   char *value = malloc(10);
+   int ok = (param && value);
+   free(param);
+   free(value);
+   // Previously we ended up with 'Use of memory after it is freed' on return.
+   return ok; // no warning
+}
+
+void test2(int n) {
+  if ((n == 0) != 0) {
+clang_analyzer_eval(n == 0); // expected-warning{{TRUE}}
+  }
+}
Index: lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
===
--- lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
+++ lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
@@ -250,6 +250,21 @@
   assert(BinaryOperator::isComparisonOp(op) &&
  "Non-comparison ops should be rewritten as comparisons to zero.");
 
+  SymbolRef Sym = LHS;
+
+  // Simplification: translate an assume of a constraint of the form
+  // "(exp comparison_op expr) != 0" to true into an assume of 
+  // "exp comparison_op expr" to true. (And similarly, an assume of the form
+  // "(exp comparison_op expr) == 0" to true into an assume of
+  // "exp comparison_op expr" to false.)
+  if (Int == 0 && (op == BO_EQ || op == BO_NE)) {
+if (const BinarySymExpr *SE = dyn_cast(Sym)) {
+  BinaryOperator::Opcode Op = SE->getOpcode();
+  if (BinaryOperator::isComparisonOp(Op))
+return assume(state, nonloc::SymbolVal(Sym), (op == BO_NE ? true : 
false));
+}
+  }
+
   // Get the type used for calculating wraparound.
   BasicValueFactory  = getBasicVals();
   APSIntType WraparoundType = BVF.getAPSIntType(LHS->getType());
@@ -261,7 +276,6 @@
   // x < 4 has the solution [0, 3]. x+2 < 4 has the solution [0-2, 3-2], which
   // in modular arithmetic is [0, 1] U [UINT_MAX-1, UINT_MAX]. It's up to
   // the subclasses of SimpleConstraintManager to handle the adjustment.
-  SymbolRef Sym = LHS;
   llvm::APSInt Adjustment = WraparoundType.getZeroValue();
   computeAdjustment(Sym, Adjustment);
 
Index: lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -618,23 +618,13 @@
 if (RHSVal.isUndef()) {
   X = RHSVal;
 } else {
-  DefinedOrUnknownSVal DefinedRHS = RHSVal.castAs();
-  ProgramStateRef StTrue, StFalse;
-  std::tie(StTrue, StFalse) = N->getState()->assume(DefinedRHS);
-  if (StTrue) {
-if (StFalse) {
-  // We can't constrain the value to 0 or 1.
-  // The best we can do is a cast.
-  X = getSValBuilder().evalCast(RHSVal, B->getType(), RHS->getType());
-} else {
-  // The value is known to be true.
-  X = getSValBuilder().makeIntVal(1, B->getType());
-}
-  } else {
-// The value is known to be false.
-assert(StFalse && "Infeasible path!");
-X = getSValBuilder().makeIntVal(0, B->getType());
-  }
+  // We evaluate "RHSVal != 0" expression which result in 0 if the value is
+  // known to be false, 1 if the value is known to be true and a new symbol
+  // when the assumption is unknown.
+  nonloc::ConcreteInt Zero(getBasicVals().getValue(0, B->getType()));
+  X = evalBinOp(N->getState(), BO_NE, 
+svalBuilder.evalCast(RHSVal, B->getType(), RHS->getType()),
+Zero, B->getType());
 }
   }
   Bldr.generateNode(B, Pred, state->BindExpr(B, Pred->getLocationContext(), 
X));


Index: test/Analysis/unwanted-programstate-data-propagation.c
===
--- test/Analysis/unwanted-programstate-data-propagation.c
+++ test/Analysis/unwanted-programstate-data-propagation.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,debug.ExprInspection,unix.Malloc -verify %s
+
+// test for PR15623
+#include "Inputs/system-header-simulator.h"
+
+void clang_analyzer_eval(int);
+
+typedef __typeof(sizeof(int)) size_t;
+void *malloc(size_t);
+void free(void *);
+
+int test1(void) {
+   char *param = malloc(10);
+   char *value = malloc(10);
+   int ok = 

[PATCH] D26657: [Sema] Respect DLL attributes more faithfully

[Shoaib Meenai via cfe-commits]

smeenai added a comment.

General coding style question. Over here, I'm creating a local helper function. 
However, that helper needs to access member functions of Sema, which is why I 
made it a private member function right now, which also unfortunately makes the 
change somewhat non-local (since the header file needs to be modified as well). 
I can think of two alternatives:

- Define a local helper lambda (which will capture `this`) instead of a private 
member function.
- Define a local static helper function and pass the Sema instance as a 
parameter so that it can call member functions on it.

Would either of those be preferable to what I currently have? I'm pretty new 
when it comes to llvm/clang changes, so stylistic feedback is greatly 
appreciated.


https://reviews.llvm.org/D26657



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

[PATCH] D26950: [libc++abi] Add _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++abi static to include in another library,
and we don't want any libc++abi functions getting exported out of that
library. This is a generalization of _LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT.


https://reviews.llvm.org/D26950

Files:
  include/__cxxabi_config.h


Index: include/__cxxabi_config.h
===
--- include/__cxxabi_config.h
+++ include/__cxxabi_config.h
@@ -22,7 +22,7 @@
 #endif
 
 #if defined(_WIN32)
- #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+ #if defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS
   #define _LIBCXXABI_FUNC_VIS
@@ -39,13 +39,20 @@
   #define _LIBCXXABI_TYPE_VIS __declspec(dllimport)
  #endif
 #else
- #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
- #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
- #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
- #if __has_attribute(__type_visibility__)
-  #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #if !defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
+  #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
+  #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
+  #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
+  #if __has_attribute(__type_visibility__)
+   #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+  #else
+   #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+  #endif
  #else
-  #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
  #endif
 #endif
 


Index: include/__cxxabi_config.h
===
--- include/__cxxabi_config.h
+++ include/__cxxabi_config.h
@@ -22,7 +22,7 @@
 #endif
 
 #if defined(_WIN32)
- #if defined(_LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT)
+ #if defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
   #define _LIBCXXABI_HIDDEN
   #define _LIBCXXABI_DATA_VIS
   #define _LIBCXXABI_FUNC_VIS
@@ -39,13 +39,20 @@
   #define _LIBCXXABI_TYPE_VIS __declspec(dllimport)
  #endif
 #else
- #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
- #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
- #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
- #if __has_attribute(__type_visibility__)
-  #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+ #if !defined(_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
+  #define _LIBCXXABI_HIDDEN __attribute__((__visibility__("hidden")))
+  #define _LIBCXXABI_DATA_VIS __attribute__((__visibility__("default")))
+  #define _LIBCXXABI_FUNC_VIS __attribute__((__visibility__("default")))
+  #if __has_attribute(__type_visibility__)
+   #define _LIBCXXABI_TYPE_VIS __attribute__((__type_visibility__("default")))
+  #else
+   #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+  #endif
  #else
-  #define _LIBCXXABI_TYPE_VIS __attribute__((__visibility__("default")))
+  #define _LIBCXXABI_HIDDEN
+  #define _LIBCXXABI_DATA_VIS
+  #define _LIBCXXABI_FUNC_VIS
+  #define _LIBCXXABI_TYPE_VIS
  #endif
 #endif
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26949: [libc++abi] Clean up visibility

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: compnerd, EricWF, howard.hinnant, mclow.lists.
smeenai added a subscriber: cfe-commits.

Use the libc++abi visibility macros instead of pragmas or using
visibility attributes directly. Clean up redundant attributes on
definitions (where the declarations already have visibility attributes
applied, from either libc++ or libc++abi headers).

No functional change. Tested by building on Linux before and after this
change and verifying that the list of exported symbols is identical.


https://reviews.llvm.org/D26949

Files:
  src/abort_message.cpp
  src/abort_message.h
  src/cxa_exception.cpp
  src/cxa_exception.hpp
  src/cxa_handlers.cpp
  src/cxa_handlers.hpp
  src/cxa_new_delete.cpp
  src/cxa_noexception.cpp
  src/cxa_unexpected.cpp
  src/fallback_malloc.cpp
  src/fallback_malloc.h
  src/private_typeinfo.cpp
  src/private_typeinfo.h
  src/stdlib_exception.cpp

Index: src/stdlib_exception.cpp
===
--- src/stdlib_exception.cpp
+++ src/stdlib_exception.cpp
@@ -9,8 +9,6 @@
 
 #include 
 
-#pragma GCC visibility push(default)
-
 namespace std
 {
 
@@ -37,5 +35,3 @@
 }
 
 }  // std
-
-#pragma GCC visibility pop
Index: src/private_typeinfo.h
===
--- src/private_typeinfo.h
+++ src/private_typeinfo.h
@@ -16,7 +16,6 @@
 #include 
 
 namespace __cxxabiv1 {
-#pragma GCC visibility push(hidden)
 
 class _LIBCXXABI_TYPE_VIS __shim_type_info : public std::type_info {
 public:
@@ -94,7 +93,7 @@
 
 class _LIBCXXABI_TYPE_VIS __class_type_info;
 
-struct __dynamic_cast_info
+struct _LIBCXXABI_HIDDEN __dynamic_cast_info
 {
 // const data supplied to the search:
 
@@ -180,7 +179,7 @@
   has_unambiguous_public_base(__dynamic_cast_info *, void *, int) const;
 };
 
-struct __base_class_type_info
+struct _LIBCXXABI_HIDDEN __base_class_type_info
 {
 public:
 const __class_type_info* __base_type;
@@ -260,8 +259,6 @@
   _LIBCXXABI_HIDDEN bool can_catch_nested(const __shim_type_info *) const;
 };
 
-#pragma GCC visibility pop
-
 }  // __cxxabiv1
 
 #endif  // __PRIVATE_TYPEINFO_H_
Index: src/private_typeinfo.cpp
===
--- src/private_typeinfo.cpp
+++ src/private_typeinfo.cpp
@@ -58,9 +58,7 @@
 namespace __cxxabiv1
 {
 
-#pragma GCC visibility push(hidden)
-
-inline
+static inline
 bool
 is_equal(const std::type_info* x, const std::type_info* y, bool use_strcmp)
 {
@@ -579,9 +577,6 @@
 #pragma clang diagnostic pop
 #endif
 
-#pragma GCC visibility pop
-#pragma GCC visibility push(default)
-
 #ifdef __clang__
 #pragma clang diagnostic push
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
@@ -756,9 +751,6 @@
 #pragma clang diagnostic pop
 #endif
 
-#pragma GCC visibility pop
-#pragma GCC visibility push(hidden)
-
 // Call this function when you hit a static_type which is a base (above) a dst_type.
 // Let caller know you hit a static_type.  But only start recording details if
 // this is (static_ptr, static_type) -- the node we are casting from.
@@ -1341,6 +1333,4 @@
   use_strcmp);
 }
 
-#pragma GCC visibility pop
-
 }  // __cxxabiv1
Index: src/fallback_malloc.h
===
--- src/fallback_malloc.h
+++ src/fallback_malloc.h
@@ -10,21 +10,18 @@
 #ifndef _FALLBACK_MALLOC_H
 #define _FALLBACK_MALLOC_H
 
+#include "__cxxabi_config.h"
 #include  // for size_t
 
 namespace __cxxabiv1 {
 
-#pragma GCC visibility push(hidden)
-
 // Allocate some memory from _somewhere_
-void * __malloc_with_fallback(size_t size);
+_LIBCXXABI_HIDDEN void * __malloc_with_fallback(size_t size);
 
 // Allocate and zero-initialize memory from _somewhere_
-void * __calloc_with_fallback(size_t count, size_t size);
-
-void __free_with_fallback(void *ptr);
+_LIBCXXABI_HIDDEN void * __calloc_with_fallback(size_t count, size_t size);
 
-#pragma GCC visibility pop
+_LIBCXXABI_HIDDEN void __free_with_fallback(void *ptr);
 
 } // namespace __cxxabiv1
 
Index: src/fallback_malloc.cpp
===
--- src/fallback_malloc.cpp
+++ src/fallback_malloc.cpp
@@ -191,8 +191,6 @@
 
 namespace __cxxabiv1 {
 
-#pragma GCC visibility push(hidden)
-
 void * __malloc_with_fallback(size_t size) {
 void *ptr = std::malloc(size);
 if (NULL == ptr) // if malloc fails, fall back to emergency stash
@@ -218,6 +216,4 @@
 std::free(ptr);
 }
 
-#pragma GCC visibility pop
-
 } // namespace __cxxabiv1
Index: src/cxa_unexpected.cpp
===
--- src/cxa_unexpected.cpp
+++ src/cxa_unexpected.cpp
@@ -14,14 +14,10 @@
 namespace __cxxabiv1
 {
 
-#pragma GCC visibility push(default)
-
 extern "C"
 {
 
 }
 
-#pragma GCC visibility pop
-
 }  // namespace __cxxabiv1
 
Index: src/cxa_noexception.cpp

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi Amini via cfe-commits]

> On Nov 21, 2016, at 4:29 PM, Mehdi Amini  wrote:
> 
>> 
>> On Nov 21, 2016, at 2:44 PM, Nico Weber > > wrote:
>> 
>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini > > wrote:
>> 
>>> On Nov 21, 2016, at 2:27 PM, Nico Weber >> > wrote:
>>> 
>>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits 
>>> > wrote:
>>> mehdi_amini added a comment.
>>> 
>>> In https://reviews.llvm.org/D25932#601842 
>>> , @rnk wrote:
>>> 
>>> > In https://reviews.llvm.org/D25932#601820 
>>> > , @mehdi_amini wrote:
>>> >
>>> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if 
>>> > > you don't package libLTO yourself, it is already accessible from the 
>>> > > linker: it will use the one in the toolchain when needed.
>>> > >
>>> > > I don't have an immediate idea to prevent this and have the linker 
>>> > > issue an error (other than removing manually libLTO from the Xcode 
>>> > > installation).
>>> >
>>> >
>>> > So, even if clang doesn't pass -lto_library to ld64, ld64 will 
>>> > auto-discover the bundled libLTO that happens to be next to it? That 
>>> > could go badly.
>>> 
>>> 
>>> Right: until LLVM 3.8, clang was *never* passing the `-lto_library` option. 
>>> The only way to have your own libLTO used by ld64 instead of the one in the 
>>> Xcode toolchain was setting the environment variable "DYLD_LIBRARY_PATH".
>>> Of course was has many issues, and that's what lead us to have clang 
>>> passing this option to ld64. Initially only when the driver was invoked 
>>> with -flto, but recently I had issues with clients that didn't use LTO 
>>> themselves but were having static archives they depend on that were 
>>> containing bitcode.
>>> 
>>> Where those archives system libraries, or other things?
>> 
>> We have two cases:
>> 
>> 1) Internal teams producing libraries in an internal SDK with LTO enabled, 
>> and other teams consuming these libraries and linking to the framework. It 
>> seems also something that people out-in-the-wild are doing according to some 
>> bug reports.
>> 2) Any Xcode user that have a somehow complex project which is split in 
>> multiple targets. Xcode can’t tell clang from one target that it is linking 
>> with LTO even if LTO is disabled just because another dependency has LTO 
>> enabled. And sometimes Xcode is only seeing static archive as an input 
>> anyway.
>> 
>> It sounds like this is a pure regression for us then.
> 
> Right, for you "downstream consumer of clang in chromium”.
> 
>> Since 'it never "hurt" to pass it' isn't true (every link invocation done by 
>> the driver now prints a warning), maybe this should be reverted until 
>> there's some better approach?
>> Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib (while 
>> clever) seems pretty unfortunate.
> 
> Is there a CMake invocation that disable libLTO today and allow to run “make 
> install” and produce a distribution of clang without libLTO?
> 
> If not, then I’m against reverting this because I consider your Chromium 
> specific incorrect with respect to the support upstream. And I’m fine having 
> it supported in the future, but you should make it supported, for instance 
> with a cmake option (if the cmake option already exists, I haven’t checked, 
> then we could conditionally compile-out the warning based on it).

I’d also add that such a cmake configuration flag (for example 
`DISABLE_CLANG_LTO_SUPPORT`) should also issue an error when -flto is passed on 
the command line.

— 
Mehdi


> 
> 
>>  
>> 
>>> Maybe clang could sniff archives for bitcode and pass only -flto in that 
>>> case?
>> 
>> That seems like a possibility. It’d have to resolve paths to the static 
>> archives, which it doesn’t do right now I believe (they can be resolved with 
>> `-Lpath -lfoo`).
>> 
>> — 
>> Mehdi

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

r287602 - Fix -Asserts build, and add some more test cases.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Mon Nov 21 18:43:30 2016
New Revision: 287602

URL: http://llvm.org/viewvc/llvm-project?rev=287602=rev
Log:
Fix -Asserts build, and add some more test cases.

Modified:
cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp

Modified: cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp?rev=287602=287601=287602=diff
==
--- cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp Mon Nov 21 18:43:30 2016
@@ -212,10 +212,7 @@ struct A {
   void *p;
 };
 void *foo(A a) { return a.p; }
-// WIN64-LABEL: define i8* @"\01?foo@definition_only@@YAPEAXUA@1@@Z"{{.*}}
-// WIN64-NEXT: :
-// WIN64-NEXT: getelementptr
-// WIN64-NEXT: load
+// WIN64-LABEL: define i8* 
@"\01?foo@definition_only@@YAPEAXUA@1@@Z"(%"struct.definition_only::A"*
 }
 
 namespace deleted_by_member {
@@ -229,11 +226,7 @@ struct A {
   B b;
 };
 void *foo(A a) { return a.b.p; }
-// WIN64-LABEL: define i8* @"\01?foo@deleted_by_member@@YAPEAXUA@1@@Z"{{.*}}
-// WIN64-NEXT: :
-// WIN64-NEXT: getelementptr
-// WIN64-NEXT: getelementptr
-// WIN64-NEXT: load
+// WIN64-LABEL: define i8* 
@"\01?foo@deleted_by_member@@YAPEAXUA@1@@Z"(%"struct.deleted_by_member::A"*
 }
 
 namespace deleted_by_base {
@@ -246,11 +239,34 @@ struct A : B {
   A();
 };
 void *foo(A a) { return a.p; }
-// WIN64-LABEL: define i8* @"\01?foo@deleted_by_base@@YAPEAXUA@1@@Z"{{.*}}
-// WIN64-NEXT: :
-// WIN64-NEXT: bitcast
-// WIN64-NEXT: getelementptr
-// WIN64-NEXT: load
+// WIN64-LABEL: define i8* 
@"\01?foo@deleted_by_base@@YAPEAXUA@1@@Z"(%"struct.deleted_by_base::A"*
+}
+
+namespace deleted_by_member_copy {
+struct B {
+  B();
+  B(const B ) = delete;
+  void *p;
+};
+struct A {
+  A();
+  B b;
+};
+void *foo(A a) { return a.b.p; }
+// WIN64-LABEL: define i8* 
@"\01?foo@deleted_by_member_copy@@YAPEAXUA@1@@Z"(%"struct.deleted_by_member_copy::A"*
+}
+
+namespace deleted_by_base_copy {
+struct B {
+  B();
+  B(const B ) = delete;
+  void *p;
+};
+struct A : B {
+  A();
+};
+void *foo(A a) { return a.p; }
+// WIN64-LABEL: define i8* 
@"\01?foo@deleted_by_base_copy@@YAPEAXUA@1@@Z"(%"struct.deleted_by_base_copy::A"*
 }
 
 namespace explicit_delete {
@@ -259,9 +275,6 @@ struct A {
   A(const A ) = delete;
   void *p;
 };
-// WIN64-LABEL: define i8* @"\01?foo@explicit_delete@@YAPEAXUA@1@@Z"{{.*}}
-// WIN64-NEXT: :
-// WIN64-NEXT: getelementptr
-// WIN64-NEXT: load
+// WIN64-LABEL: define i8* 
@"\01?foo@explicit_delete@@YAPEAXUA@1@@Z"(%"struct.explicit_delete::A"*
 void *foo(A a) { return a.p; }
 }


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

r287600 - Sema, CodeGen: Ensure that an implicit copy ctor is available more often under the Microsoft C++ ABI.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Mon Nov 21 18:21:43 2016
New Revision: 287600

URL: http://llvm.org/viewvc/llvm-project?rev=287600=rev
Log:
Sema, CodeGen: Ensure that an implicit copy ctor is available more often under 
the Microsoft C++ ABI.

This is needed because whether the constructor is deleted can control whether
we pass structs by value directly.

To fix this properly we probably want a more direct way for CodeGen to ask
whether the constructor was deleted.

Fixes PR31049.

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

Modified:
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=287600=287599=287600=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Mon Nov 21 18:21:43 2016
@@ -830,25 +830,32 @@ MicrosoftCXXABI::getRecordArgABI(const C
 getContext().getTypeSize(RD->getTypeForDecl()) > 64)
   return RAA_Indirect;
 
-// We have a trivial copy constructor or no copy constructors, but we have
-// to make sure it isn't deleted.
-bool CopyDeleted = false;
+// If this is true, the implicit copy constructor that Sema would have
+// created would not be deleted. FIXME: We should provide a more direct way
+// for CodeGen to ask whether the constructor was deleted.
+if (!RD->hasUserDeclaredCopyConstructor() &&
+!RD->hasUserDeclaredMoveConstructor() &&
+!RD->needsOverloadResolutionForMoveConstructor() &&
+!RD->hasUserDeclaredMoveAssignment() &&
+!RD->needsOverloadResolutionForMoveAssignment())
+  return RAA_Default;
+
+// Otherwise, Sema should have created an implicit copy constructor if
+// needed.
+assert(!RD->needsImplicitCopyConstructor());
+
+// We have to make sure the trivial copy constructor isn't deleted.
 for (const CXXConstructorDecl *CD : RD->ctors()) {
   if (CD->isCopyConstructor()) {
 assert(CD->isTrivial());
 // We had at least one undeleted trivial copy ctor.  Return directly.
 if (!CD->isDeleted())
   return RAA_Default;
-CopyDeleted = true;
   }
 }
 
 // The trivial copy constructor was deleted.  Return indirectly.
-if (CopyDeleted)
-  return RAA_Indirect;
-
-// There were no copy ctors.  Return in RAX.
-return RAA_Default;
+return RAA_Indirect;
   }
 
   llvm_unreachable("invalid enum");

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=287600=287599=287600=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Nov 21 18:21:43 2016
@@ -7396,6 +7396,17 @@ void Sema::AddImplicitlyDeclaredMembersT
 if (ClassDecl->needsOverloadResolutionForCopyConstructor() ||
 ClassDecl->hasInheritedConstructor())
   DeclareImplicitCopyConstructor(ClassDecl);
+// For the MS ABI we need to know whether the copy ctor is deleted. A
+// prerequisite for deleting the implicit copy ctor is that the class has a
+// move ctor or move assignment that is either user-declared or whose
+// semantics are inherited from a subobject. FIXME: We should provide a 
more
+// direct way for CodeGen to ask whether the constructor was deleted.
+else if (Context.getTargetInfo().getCXXABI().isMicrosoft() &&
+ (ClassDecl->hasUserDeclaredMoveConstructor() ||
+  ClassDecl->needsOverloadResolutionForMoveConstructor() ||
+  ClassDecl->hasUserDeclaredMoveAssignment() ||
+  ClassDecl->needsOverloadResolutionForMoveAssignment()))
+  DeclareImplicitCopyConstructor(ClassDecl);
   }
 
   if (getLangOpts().CPlusPlus11 && ClassDecl->needsImplicitMoveConstructor()) {

Modified: cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp?rev=287600=287599=287600=diff
==
--- cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/uncopyable-args.cpp Mon Nov 21 18:21:43 2016
@@ -204,3 +204,64 @@ void bar() {
 
 // WIN64-LABEL: declare void 
@"\01?foo@two_copy_ctors@@YAXUB@1@@Z"(%"struct.two_copy_ctors::B"*)
 }
+
+namespace definition_only {
+struct A {
+  A();
+  A(A &);
+  void *p;
+};
+void *foo(A a) { return a.p; }
+// WIN64-LABEL: define i8* @"\01?foo@definition_only@@YAPEAXUA@1@@Z"{{.*}}
+// WIN64-NEXT: :
+// WIN64-NEXT: getelementptr
+// WIN64-NEXT: load
+}
+
+namespace deleted_by_member {
+struct B {
+  B();
+  B(B &);
+  void *p;
+};
+struct A {
+  A();
+  B 

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi Amini via cfe-commits]

> On Nov 21, 2016, at 2:44 PM, Nico Weber  wrote:
> 
> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini  > wrote:
> 
>> On Nov 21, 2016, at 2:27 PM, Nico Weber > > wrote:
>> 
>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits 
>> > wrote:
>> mehdi_amini added a comment.
>> 
>> In https://reviews.llvm.org/D25932#601842 
>> , @rnk wrote:
>> 
>> > In https://reviews.llvm.org/D25932#601820 
>> > , @mehdi_amini wrote:
>> >
>> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you 
>> > > don't package libLTO yourself, it is already accessible from the linker: 
>> > > it will use the one in the toolchain when needed.
>> > >
>> > > I don't have an immediate idea to prevent this and have the linker issue 
>> > > an error (other than removing manually libLTO from the Xcode 
>> > > installation).
>> >
>> >
>> > So, even if clang doesn't pass -lto_library to ld64, ld64 will 
>> > auto-discover the bundled libLTO that happens to be next to it? That could 
>> > go badly.
>> 
>> 
>> Right: until LLVM 3.8, clang was *never* passing the `-lto_library` option. 
>> The only way to have your own libLTO used by ld64 instead of the one in the 
>> Xcode toolchain was setting the environment variable "DYLD_LIBRARY_PATH".
>> Of course was has many issues, and that's what lead us to have clang passing 
>> this option to ld64. Initially only when the driver was invoked with -flto, 
>> but recently I had issues with clients that didn't use LTO themselves but 
>> were having static archives they depend on that were containing bitcode.
>> 
>> Where those archives system libraries, or other things?
> 
> We have two cases:
> 
> 1) Internal teams producing libraries in an internal SDK with LTO enabled, 
> and other teams consuming these libraries and linking to the framework. It 
> seems also something that people out-in-the-wild are doing according to some 
> bug reports.
> 2) Any Xcode user that have a somehow complex project which is split in 
> multiple targets. Xcode can’t tell clang from one target that it is linking 
> with LTO even if LTO is disabled just because another dependency has LTO 
> enabled. And sometimes Xcode is only seeing static archive as an input anyway.
> 
> It sounds like this is a pure regression for us then.

Right, for you "downstream consumer of clang in chromium”.

> Since 'it never "hurt" to pass it' isn't true (every link invocation done by 
> the driver now prints a warning), maybe this should be reverted until there's 
> some better approach?
> Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib (while 
> clever) seems pretty unfortunate.

Is there a CMake invocation that disable libLTO today and allow to run “make 
install” and produce a distribution of clang without libLTO?

If not, then I’m against reverting this because I consider your Chromium 
specific incorrect with respect to the support upstream. And I’m fine having it 
supported in the future, but you should make it supported, for instance with a 
cmake option (if the cmake option already exists, I haven’t checked, then we 
could conditionally compile-out the warning based on it).

— 
Mehdi




>  
> 
>> Maybe clang could sniff archives for bitcode and pass only -flto in that 
>> case?
> 
> That seems like a possibility. It’d have to resolve paths to the static 
> archives, which it doesn’t do right now I believe (they can be resolved with 
> `-Lpath -lfoo`).
> 
> — 
> Mehdi

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

r287599 - Indicate in AST dump whether special member functions are defaulted and trivial.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Nov 21 17:43:54 2016
New Revision: 287599

URL: http://llvm.org/viewvc/llvm-project?rev=287599=rev
Log:
Indicate in AST dump whether special member functions are defaulted and trivial.

Modified:
cfe/trunk/lib/AST/ASTDumper.cpp
cfe/trunk/test/Misc/ast-dump-color.cpp

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=287599=287598=287599=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Mon Nov 21 17:43:54 2016
@@ -1137,8 +1137,15 @@ void ASTDumper::VisitFunctionDecl(const
 
   if (D->isPure())
 OS << " pure";
-  else if (D->isDeletedAsWritten())
+  if (D->isDefaulted()) {
+OS << " default";
+if (D->isDeleted())
+  OS << "_delete";
+  }
+  if (D->isDeletedAsWritten())
 OS << " delete";
+  if (D->isTrivial())
+OS << " trivial";
 
   if (const FunctionProtoType *FPT = D->getType()->getAs()) 
{
 FunctionProtoType::ExtProtoInfo EPI = FPT->getExtProtoInfo();

Modified: cfe/trunk/test/Misc/ast-dump-color.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/ast-dump-color.cpp?rev=287599=287598=287599=diff
==
--- cfe/trunk/test/Misc/ast-dump-color.cpp (original)
+++ cfe/trunk/test/Misc/ast-dump-color.cpp Mon Nov 21 17:43:54 2016
@@ -95,9 +95,9 @@ struct Invalid {
 //CHECK: {{^}}[[Blue]]| | `-[[RESET]][[BLUE]]NoInlineAttr[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:18[[RESET]]>
 //CHECK: {{^}}[[Blue]]| 
|-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]line:28:8[[RESET]]> 
[[Yellow]]col:8[[RESET]] implicit used constexpr[[CYAN]] Invalid[[RESET]] 
[[Green]]'void (void) noexcept'[[RESET]] inline
 //CHECK: {{^}}[[Blue]]| | 
`-[[RESET]][[MAGENTA]]CompoundStmt[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]>
-//CHECK: {{^}}[[Blue]]| 
|-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] 
implicit constexpr[[CYAN]] Invalid[[RESET]] [[Green]]'void (const struct 
Invalid &)'[[RESET]] inline noexcept-unevaluated 0x{{[0-9a-fA-F]*}}
+//CHECK: {{^}}[[Blue]]| 
|-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] 
implicit constexpr[[CYAN]] Invalid[[RESET]] [[Green]]'void (const struct 
Invalid &)'[[RESET]] inline default trivial noexcept-unevaluated 
0x{{[0-9a-fA-F]*}}
 //CHECK: {{^}}[[Blue]]| | `-[[RESET]][[GREEN]]ParmVarDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] 
[[Green]]'const struct Invalid &'[[RESET]]
-//CHECK: {{^}}[[Blue]]| 
`-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] 
implicit constexpr[[CYAN]] Invalid[[RESET]] [[Green]]'void (struct Invalid 
&&)'[[RESET]] inline noexcept-unevaluated 0x{{[0-9a-fA-F]*}}
+//CHECK: {{^}}[[Blue]]| 
`-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] 
implicit constexpr[[CYAN]] Invalid[[RESET]] [[Green]]'void (struct Invalid 
&&)'[[RESET]] inline default trivial noexcept-unevaluated 0x{{[0-9a-fA-F]*}}
 //CHECK: {{^}}[[Blue]]|   `-[[RESET]][[GREEN]]ParmVarDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] 
[[Green]]'struct Invalid &&'[[RESET]]
 //CHECK: {{^}}[[Blue]]`-[[RESET]][[GREEN]]VarDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:1[[RESET]], 
[[Yellow]]line:30:3[[RESET]]> [[Yellow]]col:3[[RESET]][[CYAN]] Invalid[[RESET]] 
[[Green]]'struct Invalid':'struct Invalid'[[RESET]]
 //CHECK: {{^}}[[Blue]]  
`-[[RESET]][[MAGENTA]]CXXConstructExpr[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:3[[RESET]]> [[Green]]'struct 
Invalid':'struct Invalid'[[RESET]][[Cyan]][[RESET]][[Cyan]][[RESET]] 
[[Green]]'void (void) noexcept'[[RESET]]


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

[PATCH] D26944: Suppress -Wliblto warning when -flto is not present

[Reid Kleckner via cfe-commits]

rnk created this revision.
rnk added reviewers: mehdi_amini, thakis.
rnk added a subscriber: cfe-commits.

Without -flto, it's unlikely that users will experience LLVM version
skew. The system installation of libLTO should be able to handle any
pre-compiled LLVM bitcode from static archives.


https://reviews.llvm.org/D26944

Files:
  lib/Driver/Tools.cpp
  test/Driver/darwin-ld-lto.c


Index: test/Driver/darwin-ld-lto.c
===
--- test/Driver/darwin-ld-lto.c
+++ test/Driver/darwin-ld-lto.c
@@ -1,5 +1,3 @@
-// REQUIRES: system-darwin
-
 // Check that ld gets "-lto_library" and warnings about libLTO.dylib path.
 
 // RUN: mkdir -p %T/bin
@@ -12,12 +10,20 @@
 // LINK_LTOLIB_PATH: {{ld(.exe)?"}}
 // LINK_LTOLIB_PATH: "-lto_library"
 
-// RUN: %clang -target x86_64-apple-darwin10 -### %s \
+// Only warn if -flto is on the command line.
+//
+// RUN: %clang -target x86_64-apple-darwin10 -### %s -flto \
 // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
 // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_WRN %s -input-file %t.log
 //
 // LINK_LTOLIB_PATH_WRN: warning: libLTO.dylib relative to clang installed dir 
not found; using 'ld' default search path instead
 
+// Don't warn if -flto isn't present of -Wno-liblto is present.
+//
+// RUN: %clang -target x86_64-apple-darwin10 -### %s \
+// RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file %t.log
+//
 // RUN: %clang -target x86_64-apple-darwin10 -### %s \
 // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 -Wno-liblto 2> 
%t.log
 // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file %t.log
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8232,7 +8232,9 @@
 if (llvm::sys::fs::exists(LibLTOPath)) {
   CmdArgs.push_back("-lto_library");
   CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
-} else {
+} else if (D.isUsingLTO()) {
+  // Warn if we're using LTO with the system version of libLTO. It might 
not
+  // understand LLVM bitcode generated by our version of LLVM.
   D.Diag(diag::warn_drv_lto_libpath);
 }
   }


Index: test/Driver/darwin-ld-lto.c
===
--- test/Driver/darwin-ld-lto.c
+++ test/Driver/darwin-ld-lto.c
@@ -1,5 +1,3 @@
-// REQUIRES: system-darwin
-
 // Check that ld gets "-lto_library" and warnings about libLTO.dylib path.
 
 // RUN: mkdir -p %T/bin
@@ -12,12 +10,20 @@
 // LINK_LTOLIB_PATH: {{ld(.exe)?"}}
 // LINK_LTOLIB_PATH: "-lto_library"
 
-// RUN: %clang -target x86_64-apple-darwin10 -### %s \
+// Only warn if -flto is on the command line.
+//
+// RUN: %clang -target x86_64-apple-darwin10 -### %s -flto \
 // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
 // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_WRN %s -input-file %t.log
 //
 // LINK_LTOLIB_PATH_WRN: warning: libLTO.dylib relative to clang installed dir not found; using 'ld' default search path instead
 
+// Don't warn if -flto isn't present of -Wno-liblto is present.
+//
+// RUN: %clang -target x86_64-apple-darwin10 -### %s \
+// RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file %t.log
+//
 // RUN: %clang -target x86_64-apple-darwin10 -### %s \
 // RUN:   -ccc-install-dir %S/dummytestdir -mlinker-version=133 -Wno-liblto 2> %t.log
 // RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH_NOWRN %s -input-file %t.log
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8232,7 +8232,9 @@
 if (llvm::sys::fs::exists(LibLTOPath)) {
   CmdArgs.push_back("-lto_library");
   CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
-} else {
+} else if (D.isUsingLTO()) {
+  // Warn if we're using LTO with the system version of libLTO. It might not
+  // understand LLVM bitcode generated by our version of LLVM.
   D.Diag(diag::warn_drv_lto_libpath);
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Reid Kleckner via cfe-commits]

rnk added a comment.

What if we only warn if `D.isUsingLTO()`? Things are only going to go wrong if 
*this* version of clang generates LLVM IR not understood by the system libLTO. 
Presumably bitcode from static archives will work with the system version of 
libLTO.


Repository:
  rL LLVM

https://reviews.llvm.org/D25932



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

LLVM buildmaster will be restarted tonight

[Galina Kistanova via cfe-commits]

Hello everyone,

LLVM buildmaster will be updated and restarted after 7 PM Pacific time
today.

Thanks

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

[PATCH] D26940: [libc++] Remove unneeded visibility pragmas

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: EricWF, mclow.lists.
smeenai added a subscriber: cfe-commits.

The function definitions being guarded by the pragma were all static, so
they wouldn't be exported anyway. In any case, we should prefer the
visibility macros. No functional change.


https://reviews.llvm.org/D26940

Files:
  src/chrono.cpp


Index: src/chrono.cpp
===
--- src/chrono.cpp
+++ src/chrono.cpp
@@ -90,8 +90,6 @@
 // MachInfo.numer / MachInfo.denom is often 1 on the latest equipment.  
Specialize
 //   for that case as an optimization.
 
-#pragma GCC visibility push(hidden)
-
 static
 steady_clock::rep
 steady_simplified()
@@ -129,8 +127,6 @@
 return _full;
 }
 
-#pragma GCC visibility pop
-
 steady_clock::time_point
 steady_clock::now() _NOEXCEPT
 {


Index: src/chrono.cpp
===
--- src/chrono.cpp
+++ src/chrono.cpp
@@ -90,8 +90,6 @@
 // MachInfo.numer / MachInfo.denom is often 1 on the latest equipment.  Specialize
 //   for that case as an optimization.
 
-#pragma GCC visibility push(hidden)
-
 static
 steady_clock::rep
 steady_simplified()
@@ -129,8 +127,6 @@
 return _full;
 }
 
-#pragma GCC visibility pop
-
 steady_clock::time_point
 steady_clock::now() _NOEXCEPT
 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Nico Weber via cfe-commits]

On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini  wrote:

>
> On Nov 21, 2016, at 2:27 PM, Nico Weber  wrote:
>
> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits  lists.llvm.org> wrote:
>
>> mehdi_amini added a comment.
>>
>> In https://reviews.llvm.org/D25932#601842, @rnk wrote:
>>
>> > In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote:
>> >
>> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if
>> you don't package libLTO yourself, it is already accessible from the
>> linker: it will use the one in the toolchain when needed.
>> > >
>> > > I don't have an immediate idea to prevent this and have the linker
>> issue an error (other than removing manually libLTO from the Xcode
>> installation).
>> >
>> >
>> > So, even if clang doesn't pass -lto_library to ld64, ld64 will
>> auto-discover the bundled libLTO that happens to be next to it? That could
>> go badly.
>>
>>
>> Right: until LLVM 3.8, clang was *never* passing the `-lto_library`
>> option. The only way to have your own libLTO used by ld64 instead of the
>> one in the Xcode toolchain was setting the environment variable
>> "DYLD_LIBRARY_PATH".
>> Of course was has many issues, and that's what lead us to have clang
>> passing this option to ld64. Initially only when the driver was invoked
>> with -flto, but recently I had issues with clients that didn't use LTO
>> themselves but were having static archives they depend on that were
>> containing bitcode.
>>
>
> Where those archives system libraries, or other things?
>
>
> We have two cases:
>
> 1) Internal teams producing libraries in an internal SDK with LTO enabled,
> and other teams consuming these libraries and linking to the framework. It
> seems also something that people out-in-the-wild are doing according to
> some bug reports.
> 2) Any Xcode user that have a somehow complex project which is split in
> multiple targets. Xcode can’t tell clang from one target that it is linking
> with LTO even if LTO is disabled just because another dependency has LTO
> enabled. And sometimes Xcode is only seeing static archive as an input
> anyway.
>

It sounds like this is a pure regression for us then. Since 'it never
"hurt" to pass it' isn't true (every link invocation done by the driver now
prints a warning), maybe this should be reverted until there's some better
approach? Requiring everyone to put a dummy libLTO.dylib at
../lib/libLTO.dylib (while clever) seems pretty unfortunate.


>
> Maybe clang could sniff archives for bitcode and pass only -flto in that
> case?
>
>
> That seems like a possibility. It’d have to resolve paths to the static
> archives, which it doesn’t do right now I believe (they can be resolved
> with `-Lpath -lfoo`).
>
> —
> Mehdi
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi Amini via cfe-commits]

> On Nov 21, 2016, at 2:27 PM, Nico Weber  wrote:
> 
> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits 
> > wrote:
> mehdi_amini added a comment.
> 
> In https://reviews.llvm.org/D25932#601842 
> , @rnk wrote:
> 
> > In https://reviews.llvm.org/D25932#601820 
> > , @mehdi_amini wrote:
> >
> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you 
> > > don't package libLTO yourself, it is already accessible from the linker: 
> > > it will use the one in the toolchain when needed.
> > >
> > > I don't have an immediate idea to prevent this and have the linker issue 
> > > an error (other than removing manually libLTO from the Xcode 
> > > installation).
> >
> >
> > So, even if clang doesn't pass -lto_library to ld64, ld64 will 
> > auto-discover the bundled libLTO that happens to be next to it? That could 
> > go badly.
> 
> 
> Right: until LLVM 3.8, clang was *never* passing the `-lto_library` option. 
> The only way to have your own libLTO used by ld64 instead of the one in the 
> Xcode toolchain was setting the environment variable "DYLD_LIBRARY_PATH".
> Of course was has many issues, and that's what lead us to have clang passing 
> this option to ld64. Initially only when the driver was invoked with -flto, 
> but recently I had issues with clients that didn't use LTO themselves but 
> were having static archives they depend on that were containing bitcode.
> 
> Where those archives system libraries, or other things?

We have two cases:

1) Internal teams producing libraries in an internal SDK with LTO enabled, and 
other teams consuming these libraries and linking to the framework. It seems 
also something that people out-in-the-wild are doing according to some bug 
reports.
2) Any Xcode user that have a somehow complex project which is split in 
multiple targets. Xcode can’t tell clang from one target that it is linking 
with LTO even if LTO is disabled just because another dependency has LTO 
enabled. And sometimes Xcode is only seeing static archive as an input anyway.

> Maybe clang could sniff archives for bitcode and pass only -flto in that case?

That seems like a possibility. It’d have to resolve paths to the static 
archives, which it doesn’t do right now I believe (they can be resolved with 
`-Lpath -lfoo`).

— 
Mehdi

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

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Reid Kleckner via cfe-commits]

rnk added a comment.

Maybe we should `touch ../lib/libLTO.dylib` relative to clang in our package 
and just let the loader fail if a bitcode file comes along.


Repository:
  rL LLVM

https://reviews.llvm.org/D25932



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

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Nico Weber via cfe-commits]

On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> mehdi_amini added a comment.
>
> In https://reviews.llvm.org/D25932#601842, @rnk wrote:
>
> > In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote:
> >
> > > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if
> you don't package libLTO yourself, it is already accessible from the
> linker: it will use the one in the toolchain when needed.
> > >
> > > I don't have an immediate idea to prevent this and have the linker
> issue an error (other than removing manually libLTO from the Xcode
> installation).
> >
> >
> > So, even if clang doesn't pass -lto_library to ld64, ld64 will
> auto-discover the bundled libLTO that happens to be next to it? That could
> go badly.
>
>
> Right: until LLVM 3.8, clang was *never* passing the `-lto_library`
> option. The only way to have your own libLTO used by ld64 instead of the
> one in the Xcode toolchain was setting the environment variable
> "DYLD_LIBRARY_PATH".
> Of course was has many issues, and that's what lead us to have clang
> passing this option to ld64. Initially only when the driver was invoked
> with -flto, but recently I had issues with clients that didn't use LTO
> themselves but were having static archives they depend on that were
> containing bitcode.
>

Where those archives system libraries, or other things?

Maybe clang could sniff archives for bitcode and pass only -flto in that
case?


>
> >
> >
> >> This is the motivation behind the warning I believe: we're trying to
> prevent this situation where a user would have clang but not his own libLTO
> and may encounter an unexpected issue. Even when the user does not opt-in
> to build his own project with LTO enabled, there can be static archive
> dependencies that contain bitcode.
> >
> > I guess ld64 doesn't expose a flag like `-fno-lto` to disable this
> completely? Maybe we could pass `-lto_library /dev/null` or something?
>
> No there is no such flag, what you suggest seems to work:
>
>   $ clang -flto main.c -Wl,-lto_library,/dev/null
>   ld: could not process llvm bitcode object file, because /dev/null could
> not be loaded file 
> '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxwgn/T/main-8e28a4.o'
> for architecture x86_64
>   clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> Also with an non-existing path:
>
>   $ clang -flto main.c -Wl,-lto_library,imaginary_path
>   ld: could not process llvm bitcode object file, because imaginary_path
> could not be loaded file 
> '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxwgn/T/main-319618.o'
> for architecture x86_64
>   clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D25932
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26934: [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS

[Shoaib Meenai via cfe-commits]

smeenai updated this revision to Diff 78785.
smeenai added a comment.

Adding documentation per @EricWF's comment


https://reviews.llvm.org/D26934

Files:
  docs/UsingLibcxx.rst
  include/__config

Index: include/__config
===
--- include/__config
+++ include/__config
@@ -510,7 +510,7 @@
 
 
 #ifdef _WIN32
-#if defined(_LIBCPP_DISABLE_DLL_IMPORT_EXPORT)
+#if defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 # define _LIBCPP_DLL_VIS
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
 # define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
@@ -546,18 +546,30 @@
 #endif // _WIN32
 
 #ifndef _LIBCPP_HIDDEN
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_HIDDEN __attribute__ ((__visibility__("hidden")))
+#else
+#define _LIBCPP_HIDDEN
+#endif
 #endif
 
 #ifndef _LIBCPP_FUNC_VIS
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_FUNC_VIS __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_FUNC_VIS
+#endif
 #endif
 
 #ifndef _LIBCPP_TYPE_VIS
-#  if __has_attribute(__type_visibility__)
-#define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+#  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#if __has_attribute(__type_visibility__)
+#  define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+#else
+#  define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#endif
 #  else
-#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#define _LIBCPP_TYPE_VIS
 #  endif
 #endif
 
@@ -574,19 +586,23 @@
 #endif
 
 #ifndef _LIBCPP_EXCEPTION_ABI
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_EXCEPTION_ABI
+#endif
 #endif
 
 #ifndef _LIBCPP_ENUM_VIS
-#  if __has_attribute(__type_visibility__)
+#  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
 #define _LIBCPP_ENUM_VIS __attribute__ ((__type_visibility__("default")))
 #  else
 #define _LIBCPP_ENUM_VIS
 #  endif
 #endif
 
 #ifndef _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
-#  if __has_attribute(__type_visibility__)
+#  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
 #define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS __attribute__ ((__type_visibility__("default")))
 #  else
 #define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
@@ -598,15 +614,27 @@
 #endif
 
 #ifndef _LIBCPP_INLINE_VISIBILITY
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"), __always_inline__))
+#else
+#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__always_inline__))
+#endif
 #endif
 
 #ifndef _LIBCPP_ALWAYS_INLINE
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_ALWAYS_INLINE  __attribute__ ((__visibility__("hidden"), __always_inline__))
+#else
+#define _LIBCPP_ALWAYS_INLINE  __attribute__ ((__always_inline__))
+#endif
 #endif
 
 #ifndef _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY
-# define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__visibility__("default"), __always_inline__))
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#  define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__visibility__("default"), __always_inline__))
+# else
+#  define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__always_inline__))
+# endif
 #endif
 
 #ifndef _LIBCPP_PREFERRED_OVERLOAD
Index: docs/UsingLibcxx.rst
===
--- docs/UsingLibcxx.rst
+++ docs/UsingLibcxx.rst
@@ -149,3 +149,9 @@
   This macro is used to enable -Wthread-safety annotations on libc++'s
   ``std::mutex`` and ``std::lock_guard``. By default these annotations are
   disabled and must be manually enabled by the user.
+
+**_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS**:
+  This macro is used to disable all visibility annotations inside libc++.
+  Defining this macro and then building libc++ with hidden visibility gives a
+  build of libc++ which does not export any symbols, which can be useful when
+  building statically for inclusion into another library.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi AMINI via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D25932#601842, @rnk wrote:

> In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote:
>
> > We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you 
> > don't package libLTO yourself, it is already accessible from the linker: it 
> > will use the one in the toolchain when needed.
> >
> > I don't have an immediate idea to prevent this and have the linker issue an 
> > error (other than removing manually libLTO from the Xcode installation).
>
>
> So, even if clang doesn't pass -lto_library to ld64, ld64 will auto-discover 
> the bundled libLTO that happens to be next to it? That could go badly.


Right: until LLVM 3.8, clang was *never* passing the `-lto_library` option. The 
only way to have your own libLTO used by ld64 instead of the one in the Xcode 
toolchain was setting the environment variable "DYLD_LIBRARY_PATH".
Of course was has many issues, and that's what lead us to have clang passing 
this option to ld64. Initially only when the driver was invoked with -flto, but 
recently I had issues with clients that didn't use LTO themselves but were 
having static archives they depend on that were containing bitcode.

> 
> 
>> This is the motivation behind the warning I believe: we're trying to prevent 
>> this situation where a user would have clang but not his own libLTO and may 
>> encounter an unexpected issue. Even when the user does not opt-in to build 
>> his own project with LTO enabled, there can be static archive dependencies 
>> that contain bitcode.
> 
> I guess ld64 doesn't expose a flag like `-fno-lto` to disable this 
> completely? Maybe we could pass `-lto_library /dev/null` or something?

No there is no such flag, what you suggest seems to work:

  $ clang -flto main.c -Wl,-lto_library,/dev/null
  ld: could not process llvm bitcode object file, because /dev/null could not 
be loaded file '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxwgn/T/main-8e28a4.o' 
for architecture x86_64
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

Also with an non-existing path:

  $ clang -flto main.c -Wl,-lto_library,imaginary_path
  ld: could not process llvm bitcode object file, because imaginary_path could 
not be loaded file 
'/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxwgn/T/main-319618.o' for 
architecture x86_64
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rL LLVM

https://reviews.llvm.org/D25932



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

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Reid Kleckner via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D25932#601820, @mehdi_amini wrote:

> We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you 
> don't package libLTO yourself, it is already accessible from the linker: it 
> will use the one in the toolchain when needed.
>
> I don't have an immediate idea to prevent this and have the linker issue an 
> error (other than removing manually libLTO from the Xcode installation).


So, even if clang doesn't pass -lto_library to ld64, ld64 will auto-discover 
the bundled libLTO that happens to be next to it? That could go badly.

> This is the motivation behind the warning I believe: we're trying to prevent 
> this situation where a user would have clang but not his own libLTO and may 
> encounter an unexpected issue. Even when the user does not opt-in to build 
> his own project with LTO enabled, there can be static archive dependencies 
> that contain bitcode.

I guess ld64 doesn't expose a flag like `-fno-lto` to disable this completely? 
Maybe we could pass `-lto_library /dev/null` or something?


Repository:
  rL LLVM

https://reviews.llvm.org/D25932



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

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Mehdi AMINI via cfe-commits]

mehdi_amini added a comment.

We ship `clang + libLTO + ld64` bundled in the toolchain, so even if you don't 
package libLTO yourself, it is already accessible from the linker: it will use 
the one in the toolchain when needed.

I don't have an immediate idea to prevent this and have the linker issue an 
error (other than removing manually libLTO from the Xcode installation).

This is the motivation behind the warning I believe: we're trying to prevent 
this situation where a user would have clang but not his own libLTO and may 
encounter an unexpected issue. Even when the user does not opt-in to build his 
own project with LTO enabled, there can be static archive dependencies that 
contain bitcode.


Repository:
  rL LLVM

https://reviews.llvm.org/D25932



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

[PATCH] D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h

[Zaara Syeda via cfe-commits]

syzaara added inline comments.



Comment at: lib/CodeGen/CGBuiltin.cpp:8185
+
+// Need to cast the second argument from a vector of cahr to a vector
+// of long long.

tiny comment, char is misspelled as cahr


Repository:
  rL LLVM

https://reviews.llvm.org/D26546



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

[PATCH] D26934: [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS

[Shoaib Meenai via cfe-commits]

smeenai created this revision.
smeenai added reviewers: mclow.lists, EricWF.
smeenai added a subscriber: cfe-commits.

It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.


https://reviews.llvm.org/D26934

Files:
  include/__config

Index: include/__config
===
--- include/__config
+++ include/__config
@@ -510,7 +510,7 @@
 
 
 #ifdef _WIN32
-#if defined(_LIBCPP_DISABLE_DLL_IMPORT_EXPORT)
+#if defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 # define _LIBCPP_DLL_VIS
 # define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
 # define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
@@ -546,18 +546,30 @@
 #endif // _WIN32
 
 #ifndef _LIBCPP_HIDDEN
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_HIDDEN __attribute__ ((__visibility__("hidden")))
+#else
+#define _LIBCPP_HIDDEN
+#endif
 #endif
 
 #ifndef _LIBCPP_FUNC_VIS
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_FUNC_VIS __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_FUNC_VIS
+#endif
 #endif
 
 #ifndef _LIBCPP_TYPE_VIS
-#  if __has_attribute(__type_visibility__)
-#define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+#  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#if __has_attribute(__type_visibility__)
+#  define _LIBCPP_TYPE_VIS __attribute__ ((__type_visibility__("default")))
+#else
+#  define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#endif
 #  else
-#define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
+#define _LIBCPP_TYPE_VIS
 #  endif
 #endif
 
@@ -574,19 +586,23 @@
 #endif
 
 #ifndef _LIBCPP_EXCEPTION_ABI
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
+#else
+#define _LIBCPP_EXCEPTION_ABI
+#endif
 #endif
 
 #ifndef _LIBCPP_ENUM_VIS
-#  if __has_attribute(__type_visibility__)
+#  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
 #define _LIBCPP_ENUM_VIS __attribute__ ((__type_visibility__("default")))
 #  else
 #define _LIBCPP_ENUM_VIS
 #  endif
 #endif
 
 #ifndef _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
-#  if __has_attribute(__type_visibility__)
+#  if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
 #define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS __attribute__ ((__type_visibility__("default")))
 #  else
 #define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
@@ -598,15 +614,27 @@
 #endif
 
 #ifndef _LIBCPP_INLINE_VISIBILITY
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"), __always_inline__))
+#else
+#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__always_inline__))
+#endif
 #endif
 
 #ifndef _LIBCPP_ALWAYS_INLINE
+#if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #define _LIBCPP_ALWAYS_INLINE  __attribute__ ((__visibility__("hidden"), __always_inline__))
+#else
+#define _LIBCPP_ALWAYS_INLINE  __attribute__ ((__always_inline__))
+#endif
 #endif
 
 #ifndef _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY
-# define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__visibility__("default"), __always_inline__))
+# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
+#  define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__visibility__("default"), __always_inline__))
+# else
+#  define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY __attribute__((__always_inline__))
+# endif
 #endif
 
 #ifndef _LIBCPP_PREFERRED_OVERLOAD
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26896: [libcxx] Make constexpr char_traits and char_traits

[Anton Bikineev via cfe-commits]

AntonBikineev updated this revision to Diff 78773.

https://reviews.llvm.org/D26896

Files:
  include/__config
  include/__string
  
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/assign2.pass.cpp
  
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/compare.pass.cpp
  
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/find.pass.cpp
  
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/length.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opeq.string_view.pointer.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opeq.string_view.string_view.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opge.string_view.pointer.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opge.string_view.string_view.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opgt.string_view.pointer.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opgt.string_view.string_view.pass.cpp
  
test/std/strings/string.view/string.view.comparison/ople.string_view.pointer.pass.cpp
  
test/std/strings/string.view/string.view.comparison/ople.string_view.string_view.pass.cpp
  
test/std/strings/string.view/string.view.comparison/oplt.string_view.pointer.pass.cpp
  
test/std/strings/string.view/string.view.comparison/oplt.string_view.string_view.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opne.string_view.pointer.pass.cpp
  
test/std/strings/string.view/string.view.comparison/opne.string_view.string_view.pass.cpp
  test/std/strings/string.view/string.view.cons/from_literal.pass.cpp
  test/std/strings/string.view/string.view.find/find_char_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_first_not_of_char_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_first_not_of_pointer_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_first_not_of_pointer_size_size.pass.cpp
  test/std/strings/string.view/string.view.find/find_first_of_char_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_first_of_pointer_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_first_of_pointer_size_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_last_not_of_char_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_last_not_of_pointer_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_last_not_of_pointer_size_size.pass.cpp
  test/std/strings/string.view/string.view.find/find_last_of_char_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_last_of_pointer_size.pass.cpp
  
test/std/strings/string.view/string.view.find/find_last_of_pointer_size_size.pass.cpp
  test/std/strings/string.view/string.view.find/find_pointer_size.pass.cpp
  test/std/strings/string.view/string.view.find/find_pointer_size_size.pass.cpp
  test/std/strings/string.view/string.view.find/find_string_view_size.pass.cpp
  test/std/strings/string.view/string.view.find/rfind_char_size.pass.cpp
  test/std/strings/string.view/string.view.find/rfind_pointer_size.pass.cpp
  test/std/strings/string.view/string.view.find/rfind_pointer_size_size.pass.cpp
  test/std/strings/string.view/string.view.find/rfind_string_view_size.pass.cpp
  test/std/strings/string.view/string.view.ops/compare.pointer.pass.cpp
  test/std/strings/string.view/string.view.ops/compare.pointer_size.pass.cpp
  test/std/strings/string.view/string.view.ops/compare.size_size_sv.pass.cpp
  
test/std/strings/string.view/string.view.ops/compare.size_size_sv_pointer_size.pass.cpp
  
test/std/strings/string.view/string.view.ops/compare.size_size_sv_size_size.pass.cpp
  test/std/strings/string.view/string.view.ops/compare.sv.pass.cpp

Index: test/std/strings/string.view/string.view.ops/compare.sv.pass.cpp
===
--- test/std/strings/string.view/string.view.ops/compare.sv.pass.cpp
+++ test/std/strings/string.view/string.view.ops/compare.sv.pass.cpp
@@ -119,4 +119,17 @@
 static_assert ( sv2.compare(sv3)  < 0, "" );
 }
 #endif
+
+#if TEST_STD_VER > 14
+{
+typedef std::string_view SV;
+constexpr SV  sv1 { "abcde", 5 };
+constexpr SV  sv2 { "abcde", 5 };
+constexpr SV  sv3 { "edcba0", 6 };
+static_assert ( sv1.compare(sv2) == 0, "" );
+static_assert ( sv2.compare(sv1) == 0, "" );
+static_assert ( sv3.compare(sv2)  > 0, "" );
+static_assert ( sv2.compare(sv3)  < 0, "" );
+}
+#endif
 }
Index: test/std/strings/string.view/string.view.ops/compare.size_size_sv_size_size.pass.cpp
===
--- test/std/strings/string.view/string.view.ops/compare.size_size_sv_size_size.pass.cpp
+++ test/std/strings/string.view/string.view.ops/compare.size_size_sv_size_size.pass.cpp
@@ -5844,4 +5844,14 @@
 

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Nico Weber via cfe-commits]

(In addition to rnk's question: We build with -Werror, but Wliblto seems
unaffected by this. Because of that, our bots didn't catch the new warning
and we only noticed this when a human did a local build after we updated
compilers and saw a wall of warnings. It'd be good if Wliblto was affected
by -Werror too.)

On Mon, Nov 21, 2016 at 4:18 PM, Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> rnk added a comment.
>
> This added a bunch of warnings to the Chromium build, which doesn't use
> LTO today, so we had to revert our clang roll:
> https://codereview.chromium.org/2520453002/
>
> We currently don't use LTO on Mac, so we don't build or package the LTO
> plugin, and in the near term aren't planning to change that. For now, we
> really want the previous behavior: if the linker encounters a .bc file, it
> should error. How can we get that behavior today?
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D25932
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

[Reid Kleckner via cfe-commits]

rnk added a comment.

This added a bunch of warnings to the Chromium build, which doesn't use LTO 
today, so we had to revert our clang roll:
https://codereview.chromium.org/2520453002/

We currently don't use LTO on Mac, so we don't build or package the LTO plugin, 
and in the near term aren't planning to change that. For now, we really want 
the previous behavior: if the linker encounters a .bc file, it should error. 
How can we get that behavior today?


Repository:
  rL LLVM

https://reviews.llvm.org/D25932



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

[PATCH] D26896: [libcxx] Make constexpr char_traits and char_traits

[Marshall Clow via cfe-commits]

mclow.lists added a comment.

Tests look good; I'm still staring at the stuff in `<__string>`.




Comment at: include/__string:138
 template 
-inline
-const _CharT*
+_LIBCPP_CONSTEXPR_AFTER_CXX14 inline const _CharT*
 char_traits<_CharT>::find(const char_type* __s, size_t __n, const char_type& 
__a)

Let's pick an order and stick to it.

Either `_LIBCPP_CONSTEXPR_AFTER_CXX14 inline` (as we use here)
or `inline _LIBCPP_CONSTEXPR_AFTER_CXX14` (as we use on L#204)

I prefer `inline _LIBCPP_CONSTEXPR_AFTER_CXX14`.



https://reviews.llvm.org/D26896



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

[PATCH] D26560: Add a test for vcall on a null ptr.

[Peter Collingbourne via cfe-commits]

pcc accepted this revision.
pcc added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D26560



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

[PATCH] D26903: [libcxx] Add tests (but not implementation)

[Casey Carter via cfe-commits]

CaseyCarter added inline comments.



Comment at: test/std/utilities/variant/variant.relops/relops.pass.cpp:60
+inline bool operator>(MakeEmptyT const&, MakeEmptyT const&)  { assert(false); }
+inline bool operator>=(MakeEmptyT const&, MakeEmptyT const&) { assert(false); }
+

MSVC with /W4 is, uh, not found of these functions. Adding "return false;" 
after the assert shuts it up.



Comment at: test/std/utilities/variant/variant.relops/relops.pass.cpp:189
+V v2; makeEmpty(v2);
+assert(test_less(v1, v2, true, false));
+}

Bogus test: should be `assert(test_less(v1, v2, false, true));`. Maybe someone 
forgot to implement part of P0032?



Comment at: test/std/utilities/variant/variant.relops/relops.pass.cpp:195
+V v2;
+assert(test_less(v1, v2, false, true));
+}

Bogus test again: should be `assert(test_less(v1, v2, true, false));`.



Comment at: 
test/std/utilities/variant/variant.variant/variant.assign/copy.pass.cpp:149
+static_assert(!std::is_nothrow_copy_assignable::value, "");
+}
+}

All four of these are non-portable. Implementations are permitted to strengthen 
noexcept, and these are assignments that can feasibly be implemented to not 
throw.



Comment at: 
test/std/utilities/variant/variant.variant/variant.mod/emplace_index_args.pass.cpp:92
+int y = 42;
+int z = 43;
+V v(std::in_place_index<0>, -1);

y and z are unused here,



Comment at: 
test/std/utilities/variant/variant.variant/variant.mod/emplace_type_args.pass.cpp:93
+int y = 42;
+int z = 43;
+V v(std::in_place_type, -1);

y and z are unused here.



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:321
+// the variant swap is called on.
+assert(T::move_called == 1);
+assert(T::move_assign_called == 0);

Non-portable. Replace with `LIBCPP_ASSERT(T::move_called == 1); 
assert(T::move_called <= 2);`



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:328
+assert(T::swap_called == 0);
+assert(T::move_called == 2);
+assert(T::move_assign_called == 0);

Non-portable. Replace with `LIBCPP_ASSERT(T::move_called == 2); 
assert(T::move_called <= 2);`



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:349
+assert(T1::move_called == 1); // throws
+assert(T1::move_assign_called  == 0);
+assert(T2::move_called == 1);

Extra space before `==` here and on 370.



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:350
+assert(T1::move_assign_called  == 0);
+assert(T2::move_called == 1);
+assert(std::get<0>(v1).value == 42);

Non-portable. Replace with `LIBCPP_ASSERT(T2::move_called == 1); 
assert(T2::move_called <= 1);`



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:352
+assert(std::get<0>(v1).value == 42);
+assert(v2.valueless_by_exception());
+}

non-portable. s/b
```
if (T2::move_called != 0)
assert(v2.valueless_by_exception());
else
assert(std::get<1>(v2) == 100);
```




Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:367
+}
+assert(T2::move_called == 1);
+assert(T2::swap_called == 0);

This line is a dup of 369. `T1::move_called` was probably intended, in which 
case it is non-portable and should be `LIBCPP_ASSERT(T1::move_called == 1); 
assert(T1::move_called <= 1);`



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:371
+assert(T2::move_assign_called  == 0);
+assert(std::get<0>(v1).value == 42);
+assert(std::get<1>(v2).value == 100);

Non-portable. S/b:
```
if (T1::move_called != 0)
assert(v1.valueless_by_exception());
else
assert(std::get<0>(v1).value == 42);
```



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:375
+{
+using T1 = ThrowsOnSecondMove;
+using T2 = NonThrowingNonNoexceptType;

This test and the next are non-portable and I can't be bothered to fix them.



Comment at: 
test/std/utilities/variant/variant.variant/variant.swap/swap.pass.cpp:403
+{
+// testing libc++ extension. If either variant stores a nothrow move
+// constructible type v1.swap(v2) provides the strong exception safety

I shouldn't have to point out that a test with the comment "testing libc++ 
extension" is 

[PATCH] D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h

[Sean Fertile via cfe-commits]

sfertile updated this revision to Diff 78760.
sfertile added a comment.

Moved the endian related massaging from altivec.h into Clang codegen and 
clamped the input index into the valid range [0, 12].


Repository:
  rL LLVM

https://reviews.llvm.org/D26546

Files:
  include/clang/Basic/BuiltinsPPC.def
  lib/CodeGen/CGBuiltin.cpp
  lib/Headers/altivec.h
  test/CodeGen/builtins-ppc-p9vector.c

Index: test/CodeGen/builtins-ppc-p9vector.c
===
--- test/CodeGen/builtins-ppc-p9vector.c
+++ test/CodeGen/builtins-ppc-p9vector.c
@@ -1180,3 +1180,27 @@
 // CHECK-LE-NEXT: ret <4 x float>
   return vec_extract_fp32_from_shortl(vusa);
 }
+vector unsigned char test116(void) {
+// CHECK-BE: [[T1:%.+]] = call <4 x i32> @llvm.ppc.vsx.xxinsertw(<4 x i32> {{.+}}, <2 x i64> {{.+}}, i32 7)
+// CHECK-BE-NEXT: bitcast <4 x i32> [[T1]] to <16 x i8>
+// CHECK-LE: [[T1:%.+]] = shufflevector <2 x i64> {{.+}}, <2 x i64> {{.+}}, <2 x i32> 
+// CHECK-LE-NEXT: [[T2:%.+]] = call <4 x i32> @llvm.ppc.vsx.xxinsertw(<4 x i32> {{.+}}, <2 x i64> [[T1]], i32 5)
+// CHECK-LE-NEXT: bitcast <4 x i32> T2 to <16 x i8>
+  return vec_insert4b(vuia, vuca, 7);
+}
+vector unsigned char test117(void) {
+// CHECK-BE: [[T1:%.+]] = call <4 x i32> @llvm.ppc.vsx.xxinsertw(<4 x i32> {{.+}}, <2 x i64> {{.+}}, i32 5)
+// CHECK-BE-NEXT: bitcast <4 x i32> [[T1]] to <16 x i8>
+// CHECK-LE: [[T1:%.+]] = shufflevector <2 x i64> {{.+}}, <2 x i64> {{.+}}, <2 x i32> 
+// CHECK-LE-NEXT: [[T2:%.+]] = call <4 x i32> @llvm.ppc.vsx.xxinsertw(<4 x i32> {{.+}}, <2 x i64> [[T1]], i32 7)
+// CHECK-LE-NEXT: bitcast <4 x i32> T2 to <16 x i8>
+  return vec_insert4b(vsia, vuca, 5);
+}
+vector unsigned long long test118(void) {
+// CHECK-BE: call <2 x i64> @llvm.ppc.vsx.xxextractuw(<2 x i64> {{.+}}, i32 11)
+// CHECK-BE-NEXT: ret <2 x i64>
+// CHECK-LE: [[T1:%.+]] = call <2 x i64> @llvm.ppc.vsx.xxextractuw(<2 x i64> {{.+}}, i32 1)
+// CHECK-LE-NEXT: shufflevector <2 x i64> [[T1]], <2 x i64> [[T1]], <2 x i32> 
+// CHECK-LE-NEXT: ret <2 x i64>
+  return vec_extract4b(vuca, 11);
+}
Index: lib/Headers/altivec.h
===
--- lib/Headers/altivec.h
+++ lib/Headers/altivec.h
@@ -12456,6 +12456,9 @@
 
 #ifdef __POWER9_VECTOR__
 
+#define vec_insert4b __builtin_vsx_insertword
+#define vec_extract4b __builtin_vsx_extractuword
+
 /* vec_extract_exp */
 
 static __inline__ vector unsigned int __ATTRS_o_ai
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -35,6 +35,11 @@
 using namespace CodeGen;
 using namespace llvm;
 
+static
+int64_t clamp(int64_t value, int64_t low, int64_t high) {
+  return std::min(high, std::max(low, value));
+}
+
 /// getBuiltinLibFunction - Given a builtin id for a function like
 /// "__builtin_fabsf", return a Function* for "fabsf".
 llvm::Constant *CodeGenModule::getBuiltinLibFunction(const FunctionDecl *FD,
@@ -8168,6 +8173,67 @@
 llvm_unreachable("Unknown FMA operation");
 return nullptr; // Suppress no-return warning
   }
+  case PPC::BI__builtin_vsx_insertword: {
+llvm::Function *F = CGM.getIntrinsic(Intrinsic::ppc_vsx_xxinsertw);
+
+// Third argument is a compile time constant int. It must be clamped to
+// to the range [0, 12].
+ConstantInt *ArgCI = dyn_cast(Ops[2]);
+assert(ArgCI);
+int64_t index = clamp(ArgCI->getSExtValue(), 0, 12);
+
+// Need to cast the second argument from a vector of cahr to a vector
+// of long long.
+Ops[1] = Builder.CreateBitCast(Ops[1], llvm::VectorType::get(Int64Ty, 2));
+
+if(getTarget().isLittleEndian()) {
+  // Create a shuffle mask of (1, 0)
+  Constant *ShuffleElts[2];
+  ShuffleElts[0] = ConstantInt::get(Int32Ty, 1);
+  ShuffleElts[1] = ConstantInt::get(Int32Ty, 0);
+  Constant* ShuffleMask = llvm::ConstantVector::get(ShuffleElts);
+  // Reverse the double words in the second argument.
+  Ops[1] = Builder.CreateShuffleVector(Ops[1], Ops[1], ShuffleMask);
+
+  // reverse the index
+  index = 12 - index;
+}
+
+Ops[2] = ConstantInt::getSigned(Int32Ty, index);
+return Builder.CreateCall(F, Ops);
+  }
+  case PPC::BI__builtin_vsx_extractuword: {
+llvm::Function *F = CGM.getIntrinsic(Intrinsic::ppc_vsx_xxextractuw);
+
+Ops[0] = Builder.CreateBitCast(Ops[0], llvm::VectorType::get(Int64Ty, 2));
+
+// The second argument is a compile time constant int that needs to
+// be clamped to the range [0, 12].
+ConstantInt *ArgCI = dyn_cast(Ops[1]);
+assert(ArgCI);
+int64_t index = clamp(ArgCI->getSExtValue(), 0, 12);
+
+if(getTarget().isLittleEndian()) {
+  // Reverse the index
+  index = 12 - index;
+  Ops[1] = ConstantInt::getSigned(Int32Ty, index);
+
+  // Emit the call, then reverse the double words of the results vector.
+  Value *Call = Builder.CreateCall(F, 

[PATCH] D26560: Add a test for vcall on a null ptr.

[Ivan Krasin via cfe-commits]

krasin added a comment.

Ping.


https://reviews.llvm.org/D26560



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

Re: [PATCH] Warning for main returning a bool.

[Richard Smith via cfe-commits]

This looks good to me. (While we could generalize this further, this patch
is a strict improvement, and we'll probably want to treat the 'main' case
specially regardless of whether we add a more general conversion warning.)

On 21 November 2016 at 07:18, Joshua Hurwitz  wrote:

> I modified the patch to warn only when a bool literal is returned from
> main. See attached. -Josh
>
>
> On Tue, Nov 15, 2016 at 7:50 PM Richard Smith 
> wrote:
>
>> On Tue, Nov 15, 2016 at 2:55 PM, Aaron Ballman via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Tue, Nov 15, 2016 at 5:44 PM, Hal Finkel  wrote:
>> > - Original Message -
>> >> From: "Aaron Ballman" 
>> >> To: "Hal Finkel" 
>> >> Cc: "cfe-commits" , "Joshua Hurwitz" <
>> hurwi...@google.com>
>> >> Sent: Tuesday, November 15, 2016 4:42:05 PM
>> >> Subject: Re: [PATCH] Warning for main returning a bool.
>> >>
>> >> On Tue, Nov 15, 2016 at 5:22 PM, Hal Finkel  wrote:
>> >> > - Original Message -
>> >> >> From: "Aaron Ballman via cfe-commits" 
>> >> >> To: "Joshua Hurwitz" 
>> >> >> Cc: "cfe-commits" 
>> >> >> Sent: Tuesday, November 15, 2016 12:17:28 PM
>> >> >> Subject: Re: [PATCH] Warning for main returning a bool.
>> >> >>
>> >> >> On Fri, Oct 14, 2016 at 1:17 PM, Joshua Hurwitz via cfe-commits
>> >> >>  wrote:
>> >> >> > See attached.
>> >> >> >
>> >> >> > Returning a bool from main is a special case of return type
>> >> >> > mismatch. The
>> >> >> > common convention when returning a bool is that 'true' (== 1)
>> >> >> > indicates
>> >> >> > success and 'false' (== 0) failure. But since main expects a
>> >> >> > return
>> >> >> > value of
>> >> >> > 0 on success, returning a bool is usually unintended.
>> >> >>
>> >> >> I am not convinced that this is a high-value diagnostic. Returning
>> >> >> a
>> >> >> Boolean from main() may or may not be a bug (the returned value is
>> >> >> generally a convention more than anything else). Also, why Boolean
>> >> >> and
>> >> >> not, say, long long or float?
>> >> >
>> >> > I've seen this error often enough, but I think we need to be
>> >> > careful about false positives here. I recommend that we check only
>> >> > for explicit uses of boolean immediates (i.e. return true; or
>> >> > return false;) -- these are often bugs.
>> >>
>> >> I could get behind that.
>> >>
>> >> > Aaron, I disagree that the return value is just some kind of
>> >> > convention. It has a clear meaning.
>> >>
>> >> For many hosted environments, certainly. Freestanding
>> >> implementations?
>> >> Much less so, but I suppose this behavior is still reasonable enough
>> >> for them (not to mention, there may not even *be* a main() for a
>> >> freestanding implementation).
>> >>
>> >> > Furthermore, the behavior of the system can be quite different for
>> >> > a non-zero exit code than otherwise, and users who don't
>> >> > understand what's going on can find it very difficult to
>> >> > understand what's going wrong.
>> >>
>> >> That's a fair point, but my question still stands -- why only Boolean
>> >> values, and not "return 0x12345678ULL;" or "return 1.2;"?
>> >>
>> >> Combining with your idea above, if the check flagged instances where
>> >> a
>> >> literal of non-integral type (other than Boolean) is returned from
>> >> main(), that seems like good value.
>> >
>> > Agreed.
>> >
>> > FWIW, if we have a function that returns 'int' and the user tries to
>> return '1.2' we should probably warn for any function.
>>
>> Good point, we already have -Wliteral-conversion (which catches 1.2)
>> and -Wconstant-conversion (which catches 0x12345678ULL), and
>> -Wint-conversion for C programs returning awful things like string
>> literals, all of which are enabled by default. Perhaps Boolean values
>> really are the only case we don't explicitly warn about.
>>
>>
>> Wow, I'm amazed that we have no warning at all for converting, say,
>> 'true' to int (or indeed to float).
>>
>> Even with a warning for bool literal -> non-bool conversions in place, it
>> would still seem valuable to factor out a check for the corresponding case
>> in a return statement in main, since in that case we actually know what the
>> return value means, and the chance of a false positive goes way down.
>>
>> So I think that means we want two or possibly three checks here:
>>
>> 1) main returns bool literal
>> 2) -Wliteral-conversion warning for converting bool literal to another
>> type (excluding 1-bit unsigned integral bit-fields)
>> 3) and possibly: warning for implicit conversion of bool to
>> floating-point (new subgroup of -Wbool-conversion?)
>>
>> (ordered from most- to least-reasonable to enable by default).
>>
>> ~Aaron
>>
>> >
>> >  -Hal
>> >
>> >>
>> >> ~Aaron
>> >>
>> >> >
>> >> > Thanks 

[PATCH] D26922: [ObjC++] Don't enter a C++ declarator context when the current context is an Objective-C declaration

[Alex Lorenz via cfe-commits]

arphaman created this revision.
arphaman added reviewers: manmanren, ahatanak.
arphaman added a subscriber: cfe-commits.
arphaman set the repository for this revision to rL LLVM.

This patch ensures that Sema won't enter a C++ declarator context when the 
current context is an Objective-C declaration. This prevents an assertion 
failure in `EnterDeclaratorContext` that's used to ensure that current context 
will be restored correctly after exiting the declarator context. I think that 
this approach is reasonable as AFAIK we don't need to use the C++ declarator 
contexts directly in Objective-C declarations, since they're mostly used to 
define out of line variables declared in classes or namespaces which shouldn't 
be done inside an Objective-C declaration.


Repository:
  rL LLVM

https://reviews.llvm.org/D26922

Files:
  lib/Sema/SemaCXXScopeSpec.cpp
  test/SemaObjCXX/crash.mm


Index: test/SemaObjCXX/crash.mm
===
--- test/SemaObjCXX/crash.mm
+++ test/SemaObjCXX/crash.mm
@@ -25,3 +25,17 @@
 // expected-warning@-2 {{variadic templates are a C++11 extension}}
 #endif
 @end
+
+// rdar://20560175
+
+struct OuterType {
+  typedef int InnerType;
+};
+
+@protocol InvalidProperty
+@property (nonatomic) (OuterType::InnerType) invalidTypeParens;
+// expected-error@-1 {{type name requires a specifier or qualifier}}
+// expected-error@-2 {{expected ';' at end of declaration list}}
+// expected-error@-3 {{C++ requires a type specifier for all declarations}}
+// expected-error@-4 {{cannot declare variable inside @interface or @protocol}}
+@end
Index: lib/Sema/SemaCXXScopeSpec.cpp
===
--- lib/Sema/SemaCXXScopeSpec.cpp
+++ lib/Sema/SemaCXXScopeSpec.cpp
@@ -1054,7 +1054,12 @@
   // it is a complete declaration context.
   if (!DC->isDependentContext() && RequireCompleteDeclContext(SS, DC))
 return true;
-
+
+  // Don't enter a declarator context when the current context is an 
Objective-C
+  // declaration as we might no be able to restore it when exiting the scope.
+  if (isa(CurContext) || isa(CurContext))
+return true;
+
   EnterDeclaratorContext(S, DC);
 
   // Rebuild the nested name specifier for the new scope.


Index: test/SemaObjCXX/crash.mm
===
--- test/SemaObjCXX/crash.mm
+++ test/SemaObjCXX/crash.mm
@@ -25,3 +25,17 @@
 // expected-warning@-2 {{variadic templates are a C++11 extension}}
 #endif
 @end
+
+// rdar://20560175
+
+struct OuterType {
+  typedef int InnerType;
+};
+
+@protocol InvalidProperty
+@property (nonatomic) (OuterType::InnerType) invalidTypeParens;
+// expected-error@-1 {{type name requires a specifier or qualifier}}
+// expected-error@-2 {{expected ';' at end of declaration list}}
+// expected-error@-3 {{C++ requires a type specifier for all declarations}}
+// expected-error@-4 {{cannot declare variable inside @interface or @protocol}}
+@end
Index: lib/Sema/SemaCXXScopeSpec.cpp
===
--- lib/Sema/SemaCXXScopeSpec.cpp
+++ lib/Sema/SemaCXXScopeSpec.cpp
@@ -1054,7 +1054,12 @@
   // it is a complete declaration context.
   if (!DC->isDependentContext() && RequireCompleteDeclContext(SS, DC))
 return true;
-
+
+  // Don't enter a declarator context when the current context is an Objective-C
+  // declaration as we might no be able to restore it when exiting the scope.
+  if (isa(CurContext) || isa(CurContext))
+return true;
+
   EnterDeclaratorContext(S, DC);
 
   // Rebuild the nested name specifier for the new scope.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D26829: [clang] Allow lexer to handle string_view literals

[Anton Bikineev via cfe-commits]

AntonBikineev updated this revision to Diff 78739.

https://reviews.llvm.org/D26829

Files:
  include/clang/Lex/LiteralSupport.h
  lib/Lex/Lexer.cpp
  lib/Lex/LiteralSupport.cpp
  lib/Sema/SemaDeclCXX.cpp
  test/SemaCXX/cxx1z-user-defined-literals.cpp


Index: test/SemaCXX/cxx1z-user-defined-literals.cpp
===
--- test/SemaCXX/cxx1z-user-defined-literals.cpp
+++ test/SemaCXX/cxx1z-user-defined-literals.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z %s -include %s -verify
+
+#ifndef INCLUDED
+#define INCLUDED
+
+#pragma clang system_header
+namespace std {
+  using size_t = decltype(sizeof(0));
+
+  struct string_view {};
+  string_view operator""sv(const char*, size_t);
+}
+
+#else
+
+using namespace std;
+string_view s = "foo"sv;
+const char* p = "bar"sv; // expected-error {{no viable conversion}}
+char error = 'x'sv; // expected-error {{invalid suffix}} expected-error 
{{expected ';'}}
+
+#endif
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -12908,7 +12908,7 @@
 //   Literal suffix identifiers that do not start with an underscore
 //   are reserved for future standardization.
 Diag(FnDecl->getLocation(), diag::warn_user_literal_reserved)
-  << NumericLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
+  << StringLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
   }
 
   return false;
Index: lib/Lex/LiteralSupport.cpp
===
--- lib/Lex/LiteralSupport.cpp
+++ lib/Lex/LiteralSupport.cpp
@@ -1708,3 +1708,12 @@
 
   return SpellingPtr-SpellingStart;
 }
+
+/// Determine whether a suffix is a valid ud-suffix. We avoid treating reserved
+/// suffixes as ud-suffixes, because the diagnostic experience is better if we
+/// treat it as an invalid suffix.
+bool StringLiteralParser::isValidUDSuffix(const LangOptions ,
+  StringRef Suffix) {
+  return NumericLiteralParser::isValidUDSuffix(LangOpts, Suffix) ||
+ Suffix == "sv";
+}
Index: include/clang/Lex/LiteralSupport.h
===
--- include/clang/Lex/LiteralSupport.h
+++ include/clang/Lex/LiteralSupport.h
@@ -259,6 +259,8 @@
 return UDSuffixOffset;
   }
 
+  static bool isValidUDSuffix(const LangOptions , StringRef Suffix);
+
 private:
   void init(ArrayRef StringToks);
   bool CopyStringFragment(const Token , const char *TokBegin,
Index: lib/Lex/Lexer.cpp
===
--- lib/Lex/Lexer.cpp
+++ lib/Lex/Lexer.cpp
@@ -1713,9 +1713,9 @@
  getLangOpts());
 if (!isIdentifierBody(Next)) {
   // End of suffix. Check whether this is on the whitelist.
-  IsUDSuffix = (Chars == 1 && Buffer[0] == 's') ||
-   NumericLiteralParser::isValidUDSuffix(
-   getLangOpts(), StringRef(Buffer, Chars));
+  const StringRef CompleteSuffix(Buffer, Chars);
+  IsUDSuffix = StringLiteralParser::isValidUDSuffix(getLangOpts(),
+CompleteSuffix);
   break;
 }
 


Index: test/SemaCXX/cxx1z-user-defined-literals.cpp
===
--- test/SemaCXX/cxx1z-user-defined-literals.cpp
+++ test/SemaCXX/cxx1z-user-defined-literals.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z %s -include %s -verify
+
+#ifndef INCLUDED
+#define INCLUDED
+
+#pragma clang system_header
+namespace std {
+  using size_t = decltype(sizeof(0));
+
+  struct string_view {};
+  string_view operator""sv(const char*, size_t);
+}
+
+#else
+
+using namespace std;
+string_view s = "foo"sv;
+const char* p = "bar"sv; // expected-error {{no viable conversion}}
+char error = 'x'sv; // expected-error {{invalid suffix}} expected-error {{expected ';'}}
+
+#endif
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -12908,7 +12908,7 @@
 //   Literal suffix identifiers that do not start with an underscore
 //   are reserved for future standardization.
 Diag(FnDecl->getLocation(), diag::warn_user_literal_reserved)
-  << NumericLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
+  << StringLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
   }
 
   return false;
Index: lib/Lex/LiteralSupport.cpp
===
--- lib/Lex/LiteralSupport.cpp
+++ lib/Lex/LiteralSupport.cpp
@@ -1708,3 +1708,12 @@
 
   return SpellingPtr-SpellingStart;
 }
+
+/// Determine whether a suffix is a valid ud-suffix. We avoid treating reserved
+/// suffixes as ud-suffixes, because the 

[PATCH] D26442: [analyzer] Fix crash on getSVal: handle case of CompoundVal

[Alexander Shaposhnikov via cfe-commits]

alexshap added a comment.

@NoQ , @ilya-palachev - what are the plans for this ?


Repository:
  rL LLVM

https://reviews.llvm.org/D26442



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

[PATCH] D26829: [clang] Allow lexer to handle string_view literals

[Richard Smith via cfe-commits]

rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!




Comment at: lib/Lex/Lexer.cpp:1717
+  const StringRef CompleteSuffix(Buffer, Chars);
+  const LangOptions  = getLangOpts();
+  IsUDSuffix =

I don't think the `LangOpts` variable is worthwhile; remove and replace the use 
of it below with `getLangOpts()`.


https://reviews.llvm.org/D26829



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

Re: [PATCH] Warning for main returning a bool.

[David Blaikie via cfe-commits]

On Tue, Nov 15, 2016 at 4:50 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Tue, Nov 15, 2016 at 2:55 PM, Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On Tue, Nov 15, 2016 at 5:44 PM, Hal Finkel  wrote:
> > - Original Message -
> >> From: "Aaron Ballman" 
> >> To: "Hal Finkel" 
> >> Cc: "cfe-commits" , "Joshua Hurwitz" <
> hurwi...@google.com>
> >> Sent: Tuesday, November 15, 2016 4:42:05 PM
> >> Subject: Re: [PATCH] Warning for main returning a bool.
> >>
> >> On Tue, Nov 15, 2016 at 5:22 PM, Hal Finkel  wrote:
> >> > - Original Message -
> >> >> From: "Aaron Ballman via cfe-commits" 
> >> >> To: "Joshua Hurwitz" 
> >> >> Cc: "cfe-commits" 
> >> >> Sent: Tuesday, November 15, 2016 12:17:28 PM
> >> >> Subject: Re: [PATCH] Warning for main returning a bool.
> >> >>
> >> >> On Fri, Oct 14, 2016 at 1:17 PM, Joshua Hurwitz via cfe-commits
> >> >>  wrote:
> >> >> > See attached.
> >> >> >
> >> >> > Returning a bool from main is a special case of return type
> >> >> > mismatch. The
> >> >> > common convention when returning a bool is that 'true' (== 1)
> >> >> > indicates
> >> >> > success and 'false' (== 0) failure. But since main expects a
> >> >> > return
> >> >> > value of
> >> >> > 0 on success, returning a bool is usually unintended.
> >> >>
> >> >> I am not convinced that this is a high-value diagnostic. Returning
> >> >> a
> >> >> Boolean from main() may or may not be a bug (the returned value is
> >> >> generally a convention more than anything else). Also, why Boolean
> >> >> and
> >> >> not, say, long long or float?
> >> >
> >> > I've seen this error often enough, but I think we need to be
> >> > careful about false positives here. I recommend that we check only
> >> > for explicit uses of boolean immediates (i.e. return true; or
> >> > return false;) -- these are often bugs.
> >>
> >> I could get behind that.
> >>
> >> > Aaron, I disagree that the return value is just some kind of
> >> > convention. It has a clear meaning.
> >>
> >> For many hosted environments, certainly. Freestanding
> >> implementations?
> >> Much less so, but I suppose this behavior is still reasonable enough
> >> for them (not to mention, there may not even *be* a main() for a
> >> freestanding implementation).
> >>
> >> > Furthermore, the behavior of the system can be quite different for
> >> > a non-zero exit code than otherwise, and users who don't
> >> > understand what's going on can find it very difficult to
> >> > understand what's going wrong.
> >>
> >> That's a fair point, but my question still stands -- why only Boolean
> >> values, and not "return 0x12345678ULL;" or "return 1.2;"?
> >>
> >> Combining with your idea above, if the check flagged instances where
> >> a
> >> literal of non-integral type (other than Boolean) is returned from
> >> main(), that seems like good value.
> >
> > Agreed.
> >
> > FWIW, if we have a function that returns 'int' and the user tries to
> return '1.2' we should probably warn for any function.
>
> Good point, we already have -Wliteral-conversion (which catches 1.2)
> and -Wconstant-conversion (which catches 0x12345678ULL), and
> -Wint-conversion for C programs returning awful things like string
> literals, all of which are enabled by default. Perhaps Boolean values
> really are the only case we don't explicitly warn about.
>
>
> Wow, I'm amazed that we have no warning at all for converting, say, 'true'
> to int (or indeed to float).
>

Yeah, it's somewhat conspicuously missing/explicitly avoided in the
literal-conversion warning code. I think I tried to prototype fixing/adding
this many years ago - forget where/how far I got.

It'd be great to have in the general form for things like this: void
f(bool, int) -> f(3, true), etc.


>
> Even with a warning for bool literal -> non-bool conversions in place, it
> would still seem valuable to factor out a check for the corresponding case
> in a return statement in main, since in that case we actually know what the
> return value means, and the chance of a false positive goes way down.
>
> So I think that means we want two or possibly three checks here:
>
> 1) main returns bool literal
> 2) -Wliteral-conversion warning for converting bool literal to another
> type (excluding 1-bit unsigned integral bit-fields)
> 3) and possibly: warning for implicit conversion of bool to floating-point
> (new subgroup of -Wbool-conversion?)
>
> (ordered from most- to least-reasonable to enable by default).
>
> ~Aaron
>
> >
> >  -Hal
> >
> >>
> >> ~Aaron
> >>
> >> >
> >> > Thanks again,
> >> > Hal
> >> >
> >> >>
> >> >> ~Aaron
> >> >>
> >> >> >
> >> >> > ___
> >> >> > cfe-commits mailing list
> >> >> > cfe-commits@lists.llvm.org

[PATCH] D26853: Make llvm::Error generated from replacement interfaces more specific.

[Eric Liu via cfe-commits]

ioeric added a comment.

Thanks for the review!


https://reviews.llvm.org/D26853



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

[PATCH] D26853: Make llvm::Error generated from replacement interfaces more specific.

[Eric Liu via cfe-commits]

ioeric updated this revision to Diff 78733.
ioeric marked 5 inline comments as done.
ioeric added a comment.

- Addressed review comments.


https://reviews.llvm.org/D26853

Files:
  include/clang/Tooling/Core/Replacement.h
  lib/Tooling/Core/Replacement.cpp
  unittests/Tooling/RefactoringTest.cpp

Index: unittests/Tooling/RefactoringTest.cpp
===
--- unittests/Tooling/RefactoringTest.cpp
+++ unittests/Tooling/RefactoringTest.cpp
@@ -100,21 +100,71 @@
   EXPECT_TRUE(Replace2.getFilePath().empty());
 }
 
+// Checks that an llvm::Error instance contains a ReplacementError with expected
+// error code, expected new replacement, and expected existing replacement.
+static bool checkReplacementError(
+llvm::Error&& Error, replacement_error ExpectedErr,
+llvm::Optional ExpectedExisting,
+llvm::Optional ExpectedNew) {
+  if (!Error) {
+llvm::errs() << "Error is a success.";
+return false;
+  }
+  std::string ErrorMessage;
+  llvm::raw_string_ostream OS(ErrorMessage);
+  llvm::handleAllErrors(std::move(Error), [&](const ReplacementError ) {
+llvm::errs() << "Handling error...\n";
+if (ExpectedErr != RE.get())
+  OS << "Unexpected error code: " << int(RE.get()) << "\n";
+if (ExpectedExisting != RE.getExistingReplacement()) {
+  OS << "Expected Existing != Actual Existing.\n";
+  if (ExpectedExisting.hasValue())
+OS << "Expected existing replacement: " << ExpectedExisting->toString()
+   << "\n";
+  if (RE.getExistingReplacement().hasValue())
+OS << "Actual existing replacement: "
+   << RE.getExistingReplacement()->toString() << "\n";
+}
+if (ExpectedNew != RE.getNewReplacement()) {
+  OS << "Expected New != Actual New.\n";
+  if (ExpectedNew.hasValue())
+OS << "Expected new replacement: " << ExpectedNew->toString() << "\n";
+  if (RE.getNewReplacement().hasValue())
+OS << "Actual new replacement: " << RE.getNewReplacement()->toString()
+   << "\n";
+}
+  });
+  OS.flush();
+  if (ErrorMessage.empty()) return true;
+  llvm::errs() << ErrorMessage;
+  return false;
+}
+
 TEST_F(ReplacementTest, FailAddReplacements) {
   Replacements Replaces;
   Replacement Deletion("x.cc", 0, 10, "3");
   auto Err = Replaces.add(Deletion);
   EXPECT_TRUE(!Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 0, 2, "a"));
-  EXPECT_TRUE((bool)Err);
-  llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 2, 2, "a"));
-  EXPECT_TRUE((bool)Err);
-  llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("y.cc", 20, 2, ""));
-  EXPECT_TRUE((bool)Err);
-  llvm::consumeError(std::move(Err));
+
+  Replacement OverlappingReplacement("x.cc", 0, 2, "a");
+  Err = Replaces.add(OverlappingReplacement);
+  EXPECT_TRUE(checkReplacementError(std::move(Err),
+replacement_error::overlap_conflict,
+Deletion, OverlappingReplacement));
+
+  Replacement ContainedReplacement("x.cc", 2, 2, "a");
+  Err = Replaces.add(Replacement(ContainedReplacement));
+  EXPECT_TRUE(checkReplacementError(std::move(Err),
+replacement_error::overlap_conflict,
+Deletion, ContainedReplacement));
+
+  Replacement WrongPathReplacement("y.cc", 20, 2, "");
+  Err = Replaces.add(WrongPathReplacement);
+  EXPECT_TRUE(checkReplacementError(std::move(Err),
+replacement_error::wrong_file_path,
+Deletion, WrongPathReplacement));
+
   EXPECT_EQ(1u, Replaces.size());
   EXPECT_EQ(Deletion, *Replaces.begin());
 }
@@ -299,9 +349,11 @@
 
   // Make sure we find the overlap with the first entry when inserting a
   // replacement that ends exactly at the seam of the existing replacements.
-  Err = Replaces.add(Replacement("x.cc", 5, 5, "fail"));
-  EXPECT_TRUE((bool)Err);
-  llvm::consumeError(std::move(Err));
+  Replacement OverlappingReplacement("x.cc", 5, 5, "fail");
+  Err = Replaces.add(OverlappingReplacement);
+  EXPECT_TRUE(checkReplacementError(std::move(Err),
+replacement_error::overlap_conflict,
+*Replaces.begin(), OverlappingReplacement));
 
   Err = Replaces.add(Replacement("x.cc", 10, 0, ""));
   EXPECT_TRUE(!Err);
@@ -333,9 +385,11 @@
   auto Err = Replaces.add(Replacement("x.cc", 10, 0, "a"));
   EXPECT_TRUE(!Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 10, 0, "b"));
-  EXPECT_TRUE((bool)Err);
-  llvm::consumeError(std::move(Err));
+  Replacement ConflictInsertion("x.cc", 10, 0, "b");
+  Err = Replaces.add(ConflictInsertion);
+  EXPECT_TRUE(checkReplacementError(std::move(Err),
+replacement_error::insert_conflict,
+

[PATCH] D26853: Make llvm::Error generated from replacement interfaces more specific.

[Benjamin Kramer via cfe-commits]

bkramer added inline comments.



Comment at: include/clang/Tooling/Core/Replacement.h:157
+  /// \brief Constructs an error related to an existing replacement.
+  ReplacementError(replacement_error Err, const Replacement )
+  : Err(Err), ExistingReplacement(Existing) {}

Can you use pass by value and std::move here?



Comment at: include/clang/Tooling/Core/Replacement.h:162
+  /// replacement in a set of replacements.
+  ReplacementError(replacement_error Err, const Replacement ,
+   const Replacement )

Here too.



Comment at: include/clang/Tooling/Core/Replacement.h:174
+
+  llvm::Optional getNewReplacement() const {
+return NewReplacement;

This on the other hand should return a const ref.



Comment at: include/clang/Tooling/Core/Replacement.h:178
+
+  llvm::Optional getExistingReplacement() const {
+return ExistingReplacement;

This too.



Comment at: lib/Tooling/Core/Replacement.cpp:157
+return "The new insertion has the same insert location as an existing "
+   "replacement's.";
+  }

Drop the 's here.


https://reviews.llvm.org/D26853



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

[PATCH] D26916: [ObjC] Avoid a @try/@finally/@autoreleasepool fixit when parsing an expression

[Alex Lorenz via cfe-commits]

arphaman created this revision.
arphaman added reviewers: manmanren, bruno.
arphaman added a subscriber: cfe-commits.
arphaman set the repository for this revision to rL LLVM.

This patch ensures that the typo fixit for the `@try/@finally/@autoreleasepool 
{ }` directive is shown only when we're parsing an actual statement where such 
directives can actually be present.


Repository:
  rL LLVM

https://reviews.llvm.org/D26916

Files:
  lib/Parse/ParseObjc.cpp
  test/Parser/objc-at-directive-fixit.m


Index: test/Parser/objc-at-directive-fixit.m
===
--- /dev/null
+++ test/Parser/objc-at-directive-fixit.m
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-apple-macosx10.10.0 -verify 
-fobjc-exceptions %s
+// RUN: not %clang_cc1 -fsyntax-only -triple x86_64-apple-macosx10.10.0 
-fdiagnostics-parseable-fixits -fobjc-exceptions %s 2>&1 | FileCheck %s
+
+// rdar://19669565
+
+void bar(int x);
+
+void f() {
+  @try { }
+  @finally { }
+  @autoreleasepool { }
+
+  // Provide a fixit when we are parsing a standalone statement
+  @tr { }; // expected-error {{unexpected '@' in program}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:4-[[@LINE-1]]:6}:"try"
+  @finaly { }; // expected-error {{unexpected '@' in program}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:4-[[@LINE-1]]:10}:"finally"
+  @autorelpool { }; // expected-error {{unexpected '@' in program}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:4-[[@LINE-1]]:15}:"autoreleasepool"
+
+  // Ensure that no fixit is given when parsing expressions
+  // CHECK-NOT: fix-it
+  id thing = @autoreleasepool { }; // expected-error {{unexpected '@' in 
program}}
+  (void)@tr { }; // expected-error {{unexpected '@' in program}}
+  bar(@final { }); // expected-error {{unexpected '@' in program}}
+  for(@auto;;) { } // expected-error {{unexpected '@' in program}}
+  [@try]; // expected-error {{unexpected '@' in program}}
+}
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -2773,6 +2773,7 @@
 return Actions.ActOnNullStmt(Tok.getLocation());
   }
 
+  ExprStatementTokLoc = AtLoc;
   ExprResult Res(ParseExpressionWithLeadingAt(AtLoc));
   if (Res.isInvalid()) {
 // If the expression is invalid, skip ahead to the next semicolon. Not
@@ -2869,7 +2870,11 @@
   return ParseAvailabilityCheckExpr(AtLoc);
   default: {
 const char *str = nullptr;
-if (GetLookAheadToken(1).is(tok::l_brace)) {
+// Only provide the @try/@finally/@autoreleasepool fixit when we're 
sure
+// that this is a proper statement where such directives could actually
+// occur.
+if (GetLookAheadToken(1).is(tok::l_brace) &&
+ExprStatementTokLoc == AtLoc) {
   char ch = Tok.getIdentifierInfo()->getNameStart()[0];
   str =  
 ch == 't' ? "try" 


Index: test/Parser/objc-at-directive-fixit.m
===
--- /dev/null
+++ test/Parser/objc-at-directive-fixit.m
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-apple-macosx10.10.0 -verify -fobjc-exceptions %s
+// RUN: not %clang_cc1 -fsyntax-only -triple x86_64-apple-macosx10.10.0 -fdiagnostics-parseable-fixits -fobjc-exceptions %s 2>&1 | FileCheck %s
+
+// rdar://19669565
+
+void bar(int x);
+
+void f() {
+  @try { }
+  @finally { }
+  @autoreleasepool { }
+
+  // Provide a fixit when we are parsing a standalone statement
+  @tr { }; // expected-error {{unexpected '@' in program}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:4-[[@LINE-1]]:6}:"try"
+  @finaly { }; // expected-error {{unexpected '@' in program}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:4-[[@LINE-1]]:10}:"finally"
+  @autorelpool { }; // expected-error {{unexpected '@' in program}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:4-[[@LINE-1]]:15}:"autoreleasepool"
+
+  // Ensure that no fixit is given when parsing expressions
+  // CHECK-NOT: fix-it
+  id thing = @autoreleasepool { }; // expected-error {{unexpected '@' in program}}
+  (void)@tr { }; // expected-error {{unexpected '@' in program}}
+  bar(@final { }); // expected-error {{unexpected '@' in program}}
+  for(@auto;;) { } // expected-error {{unexpected '@' in program}}
+  [@try]; // expected-error {{unexpected '@' in program}}
+}
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -2773,6 +2773,7 @@
 return Actions.ActOnNullStmt(Tok.getLocation());
   }
 
+  ExprStatementTokLoc = AtLoc;
   ExprResult Res(ParseExpressionWithLeadingAt(AtLoc));
   if (Res.isInvalid()) {
 // If the expression is invalid, skip ahead to the next semicolon. Not
@@ -2869,7 +2870,11 @@
   return ParseAvailabilityCheckExpr(AtLoc);
   default: {
 const char *str = nullptr;
-if 

[clang-tools-extra] r287550 - clang-tidy: improve my test for readability-redundant-declaration

[Daniel Marjamaki via cfe-commits]

Author: danielmarjamaki
Date: Mon Nov 21 10:08:17 2016
New Revision: 287550

URL: http://llvm.org/viewvc/llvm-project?rev=287550=rev
Log:
clang-tidy: improve my test for readability-redundant-declaration


Modified:

clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp?rev=287550=287549=287550=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
Mon Nov 21 10:08:17 2016
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s readability-redundant-declaration %t -- -- 
-target x86_64-unknown-unknown
+// RUN: %check_clang_tidy %s readability-redundant-declaration %t
 
 extern int Xyz;
 extern int Xyz;
@@ -24,7 +24,7 @@ static int f() {}
 
 // Original check crashed for the code below.
 namespace std {
-  typedef long unsigned int size_t;
+  typedef decltype(sizeof(0)) size_t;
 }
 void* operator new(std::size_t) __attribute__((__externally_visible__));
 void* operator new[](std::size_t) __attribute__((__externally_visible__));


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

Re: [clang-tools-extra] r287540 - readability-redundant-declaration: Fix crash

[Aaron Ballman via cfe-commits]

On Mon, Nov 21, 2016 at 9:29 AM, Daniel Marjamaki via cfe-commits
 wrote:
> Author: danielmarjamaki
> Date: Mon Nov 21 08:29:53 2016
> New Revision: 287540
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287540=rev
> Log:
> readability-redundant-declaration: Fix crash
>
> Differential Revision: https://reviews.llvm.org/D26911
>
>
> Modified:
> 
> clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
> 
> clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
>
> Modified: 
> clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp?rev=287540=287539=287540=diff
> ==
> --- 
> clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp 
> (original)
> +++ 
> clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp 
> Mon Nov 21 08:29:53 2016
> @@ -28,6 +28,8 @@ void RedundantDeclarationCheck::check(co
>const auto *Prev = D->getPreviousDecl();
>if (!Prev)
>  return;
> +  if (!Prev->getLocation().isValid())
> +return;
>if (Prev->getLocation() == D->getLocation())
>  return;
>
>
> Modified: 
> clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp?rev=287540=287539=287540=diff
> ==
> --- 
> clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
> (original)
> +++ 
> clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
> Mon Nov 21 08:29:53 2016
> @@ -21,3 +21,10 @@ static int f();
>  // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'f' declaration
>  // CHECK-FIXES: {{^}}{{$}}
>  static int f() {}
> +
> +// Original check crashed for the code below.
> +namespace std {
> +  typedef long unsigned int size_t;

Instead of this (or your current fix that specifies the target), why
not do: typedef decltype(sizeof(0)) size_t; ?

~Aaron

> +}
> +void* operator new(std::size_t) __attribute__((__externally_visible__));
> +void* operator new[](std::size_t) __attribute__((__externally_visible__));
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r287546 - clang-tidy: Attempt to fix build bot failure with mismatching size_t platform type.

[Daniel Marjamaki via cfe-commits]

Author: danielmarjamaki
Date: Mon Nov 21 09:46:40 2016
New Revision: 287546

URL: http://llvm.org/viewvc/llvm-project?rev=287546=rev
Log:
clang-tidy: Attempt to fix build bot failure with mismatching size_t platform 
type.

Modified:

clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp?rev=287546=287545=287546=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
Mon Nov 21 09:46:40 2016
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy %s readability-redundant-declaration %t
+// RUN: %check_clang_tidy %s readability-redundant-declaration %t -- -- 
-target x86_64-unknown-unknown
 
 extern int Xyz;
 extern int Xyz;


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

[clang-tools-extra] r287544 - [include-fixer plugin] Make the plugin emit proper fixits in case multiple errors are found.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Mon Nov 21 09:28:50 2016
New Revision: 287544

URL: http://llvm.org/viewvc/llvm-project?rev=287544=rev
Log:
[include-fixer plugin] Make the plugin emit proper fixits in case multiple 
errors are found.

The standalone tool only fixes the first one and we managed to bake that
assumption into the code :(

Also fix a crash when no header is found at all.

Modified:
clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
clang-tools-extra/trunk/include-fixer/IncludeFixer.h
clang-tools-extra/trunk/test/include-fixer/yamldb_plugin.cpp

Modified: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp?rev=287544=287543=287544=diff
==
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp Mon Nov 21 09:28:50 
2016
@@ -62,7 +62,8 @@ public:
   IncludeFixerContext
   getIncludeFixerContext(const clang::SourceManager ,
  clang::HeaderSearch ) const {
-return SemaSource.getIncludeFixerContext(SourceManager, HeaderSearch);
+return SemaSource.getIncludeFixerContext(SourceManager, HeaderSearch,
+ SemaSource.getMatchedSymbols());
   }
 
 private:
@@ -156,9 +157,10 @@ bool IncludeFixerSemaSource::MaybeDiagno
   T.getUnqualifiedType().getAsString(context.getPrintingPolicy());
   DEBUG(llvm::dbgs() << "Query missing complete type '" << QueryString << "'");
   // Pass an empty range here since we don't add qualifier in this case.
-  query(QueryString, "", tooling::Range());
+  std::vector MatchedSymbols =
+  query(QueryString, "", tooling::Range());
 
-  if (GenerateDiagnostics) {
+  if (!MatchedSymbols.empty() && GenerateDiagnostics) {
 TypoCorrection Correction;
 FileID FID = CI->getSourceManager().getFileID(Loc);
 StringRef Code = CI->getSourceManager().getBufferData(FID);
@@ -167,7 +169,8 @@ bool IncludeFixerSemaSource::MaybeDiagno
 addDiagnosticsForContext(
 Correction,
 getIncludeFixerContext(CI->getSourceManager(),
-   CI->getPreprocessor().getHeaderSearchInfo()),
+   CI->getPreprocessor().getHeaderSearchInfo(),
+   MatchedSymbols),
 Code, StartOfFile, CI->getASTContext());
 for (const PartialDiagnostic  : Correction.getExtraDiagnostics())
   CI->getSema().Diag(Loc, PD);
@@ -273,17 +276,19 @@ clang::TypoCorrection IncludeFixerSemaSo
   }
 
   DEBUG(llvm::dbgs() << "TypoScopeQualifiers: " << TypoScopeString << "\n");
-  query(QueryString, TypoScopeString, SymbolRange);
+  std::vector MatchedSymbols =
+  query(QueryString, TypoScopeString, SymbolRange);
 
   clang::TypoCorrection Correction(Typo.getName());
   Correction.setCorrectionRange(SS, Typo);
-  if (GenerateDiagnostics) {
+  if (!MatchedSymbols.empty() && GenerateDiagnostics) {
 FileID FID = SM.getFileID(Typo.getLoc());
 StringRef Code = SM.getBufferData(FID);
 SourceLocation StartOfFile = SM.getLocForStartOfFile(FID);
 addDiagnosticsForContext(
 Correction,
-getIncludeFixerContext(SM, 
CI->getPreprocessor().getHeaderSearchInfo()),
+getIncludeFixerContext(SM, CI->getPreprocessor().getHeaderSearchInfo(),
+   MatchedSymbols),
 Code, StartOfFile, CI->getASTContext());
   }
   return Correction;
@@ -316,7 +321,8 @@ std::string IncludeFixerSemaSource::mini
 /// Get the include fixer context for the queried symbol.
 IncludeFixerContext IncludeFixerSemaSource::getIncludeFixerContext(
 const clang::SourceManager ,
-clang::HeaderSearch ) const {
+clang::HeaderSearch ,
+ArrayRef MatchedSymbols) const {
   std::vector SymbolCandidates;
   for (const auto  : MatchedSymbols) {
 std::string FilePath = Symbol.getFilePath().str();
@@ -332,8 +338,9 @@ IncludeFixerContext IncludeFixerSemaSour
   return IncludeFixerContext(FilePath, QuerySymbolInfos, SymbolCandidates);
 }
 
-bool IncludeFixerSemaSource::query(StringRef Query, StringRef ScopedQualifiers,
-   tooling::Range Range) {
+std::vector
+IncludeFixerSemaSource::query(StringRef Query, StringRef ScopedQualifiers,
+  tooling::Range Range) {
   assert(!Query.empty() && "Empty query!");
 
   // Save all instances of an unidentified symbol.
@@ -347,7 +354,7 @@ bool IncludeFixerSemaSource::query(Strin
 Query == QuerySymbolInfos.front().RawIdentifier) {
   QuerySymbolInfos.push_back({Query.str(), ScopedQualifiers, Range});
 }
-return false;
+return {};
   }
 
   DEBUG(llvm::dbgs() << "Looking up '" << Query << "' at ");
@@ -375,12 +382,16 @@ bool IncludeFixerSemaSource::query(Strin
   // It's unsafe to do nested search for the identifier with scoped namespace
   // 

Re: [PATCH] Warning for main returning a bool.

[Joshua Hurwitz via cfe-commits]

I modified the patch to warn only when a bool literal is returned from
main. See attached. -Josh

On Tue, Nov 15, 2016 at 7:50 PM Richard Smith  wrote:

> On Tue, Nov 15, 2016 at 2:55 PM, Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On Tue, Nov 15, 2016 at 5:44 PM, Hal Finkel  wrote:
> > - Original Message -
> >> From: "Aaron Ballman" 
> >> To: "Hal Finkel" 
> >> Cc: "cfe-commits" , "Joshua Hurwitz" <
> hurwi...@google.com>
> >> Sent: Tuesday, November 15, 2016 4:42:05 PM
> >> Subject: Re: [PATCH] Warning for main returning a bool.
> >>
> >> On Tue, Nov 15, 2016 at 5:22 PM, Hal Finkel  wrote:
> >> > - Original Message -
> >> >> From: "Aaron Ballman via cfe-commits" 
> >> >> To: "Joshua Hurwitz" 
> >> >> Cc: "cfe-commits" 
> >> >> Sent: Tuesday, November 15, 2016 12:17:28 PM
> >> >> Subject: Re: [PATCH] Warning for main returning a bool.
> >> >>
> >> >> On Fri, Oct 14, 2016 at 1:17 PM, Joshua Hurwitz via cfe-commits
> >> >>  wrote:
> >> >> > See attached.
> >> >> >
> >> >> > Returning a bool from main is a special case of return type
> >> >> > mismatch. The
> >> >> > common convention when returning a bool is that 'true' (== 1)
> >> >> > indicates
> >> >> > success and 'false' (== 0) failure. But since main expects a
> >> >> > return
> >> >> > value of
> >> >> > 0 on success, returning a bool is usually unintended.
> >> >>
> >> >> I am not convinced that this is a high-value diagnostic. Returning
> >> >> a
> >> >> Boolean from main() may or may not be a bug (the returned value is
> >> >> generally a convention more than anything else). Also, why Boolean
> >> >> and
> >> >> not, say, long long or float?
> >> >
> >> > I've seen this error often enough, but I think we need to be
> >> > careful about false positives here. I recommend that we check only
> >> > for explicit uses of boolean immediates (i.e. return true; or
> >> > return false;) -- these are often bugs.
> >>
> >> I could get behind that.
> >>
> >> > Aaron, I disagree that the return value is just some kind of
> >> > convention. It has a clear meaning.
> >>
> >> For many hosted environments, certainly. Freestanding
> >> implementations?
> >> Much less so, but I suppose this behavior is still reasonable enough
> >> for them (not to mention, there may not even *be* a main() for a
> >> freestanding implementation).
> >>
> >> > Furthermore, the behavior of the system can be quite different for
> >> > a non-zero exit code than otherwise, and users who don't
> >> > understand what's going on can find it very difficult to
> >> > understand what's going wrong.
> >>
> >> That's a fair point, but my question still stands -- why only Boolean
> >> values, and not "return 0x12345678ULL;" or "return 1.2;"?
> >>
> >> Combining with your idea above, if the check flagged instances where
> >> a
> >> literal of non-integral type (other than Boolean) is returned from
> >> main(), that seems like good value.
> >
> > Agreed.
> >
> > FWIW, if we have a function that returns 'int' and the user tries to
> return '1.2' we should probably warn for any function.
>
> Good point, we already have -Wliteral-conversion (which catches 1.2)
> and -Wconstant-conversion (which catches 0x12345678ULL), and
> -Wint-conversion for C programs returning awful things like string
> literals, all of which are enabled by default. Perhaps Boolean values
> really are the only case we don't explicitly warn about.
>
>
> Wow, I'm amazed that we have no warning at all for converting, say, 'true'
> to int (or indeed to float).
>
> Even with a warning for bool literal -> non-bool conversions in place, it
> would still seem valuable to factor out a check for the corresponding case
> in a return statement in main, since in that case we actually know what the
> return value means, and the chance of a false positive goes way down.
>
> So I think that means we want two or possibly three checks here:
>
> 1) main returns bool literal
> 2) -Wliteral-conversion warning for converting bool literal to another
> type (excluding 1-bit unsigned integral bit-fields)
> 3) and possibly: warning for implicit conversion of bool to floating-point
> (new subgroup of -Wbool-conversion?)
>
> (ordered from most- to least-reasonable to enable by default).
>
> ~Aaron
>
> >
> >  -Hal
> >
> >>
> >> ~Aaron
> >>
> >> >
> >> > Thanks again,
> >> > Hal
> >> >
> >> >>
> >> >> ~Aaron
> >> >>
> >> >> >
> >> >> > ___
> >> >> > cfe-commits mailing list
> >> >> > cfe-commits@lists.llvm.org
> >> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >> >> >
> >> >> ___
> >> >> cfe-commits mailing list
> >> >> cfe-commits@lists.llvm.org
> >> >> 

Re: [clang-tools-extra] r287540 - readability-redundant-declaration: Fix crash

[Renato Golin via cfe-commits]

On 21 November 2016 at 14:29, Daniel Marjamaki via cfe-commits
 wrote:
> Author: danielmarjamaki
> Date: Mon Nov 21 08:29:53 2016
> New Revision: 287540
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287540=rev
> Log:
> readability-redundant-declaration: Fix crash

Introduced another... :)

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/728

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

Re: r287343 - [OpenCL] Introduce ReadPipeType and WritePipeType.

[Yaron Keren via cfe-commits]

Hi Joey,

In order for  ReadPipeType and WritePipeType to work with LLVM type system
(isa, dyn_cast), you need to modify the existing TypeClass::Pipe kind
into TypeClass::ReadPipe
and TypeClass::WritePipe, have Pipe::classof recognize both kinds and have
ReadPipe::classof and WritePipe::classof recognize their respective kinds.

See rule 4 in http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

Good example is
how ConstantArrayType, IncompleteArrayType, VariableArrayType,
DependentSizedArrayType inherit
from ArrayType.

Yaron



2016-11-18 16:10 GMT+02:00 Joey Gouly via cfe-commits <
cfe-commits@lists.llvm.org>:

> Author: joey
> Date: Fri Nov 18 08:10:54 2016
> New Revision: 287343
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287343=rev
> Log:
> [OpenCL] Introduce ReadPipeType and WritePipeType.
>
> This allows Sema to diagnose passing a read_only pipe to a
> write_only pipe argument.
>
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/AST/Type.h
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/AST/TypePrinter.cpp
> cfe/trunk/lib/Sema/SemaType.cpp
> cfe/trunk/lib/Sema/TreeTransform.h
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/lib/Serialization/ASTWriter.cpp
> cfe/trunk/test/Misc/ast-dump-pipe.cl
> cfe/trunk/test/SemaOpenCL/access-qualifier.cl
> cfe/trunk/test/SemaOpenCL/invalid-pipes-cl2.0.cl
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/AST/ASTContext.h?rev=287343=287342=287343=diff
> 
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Fri Nov 18 08:10:54 2016
> @@ -135,7 +135,8 @@ class ASTContext : public RefCountedBase
>mutable llvm::FoldingSet AutoTypes;
>mutable llvm::FoldingSet AtomicTypes;
>llvm::FoldingSet AttributedTypes;
> -  mutable llvm::FoldingSet PipeTypes;
> +  mutable llvm::FoldingSet ReadPipeTypes;
> +  mutable llvm::FoldingSet WritePipeTypes;
>
>mutable llvm::FoldingSet QualifiedTemplateNames;
>mutable llvm::FoldingSet DependentTemplateNames;
> @@ -1120,8 +1121,10 @@ public:
>/// blocks.
>QualType getBlockDescriptorType() const;
>
> -  /// \brief Return pipe type for the specified type.
> -  QualType getPipeType(QualType T) const;
> +  /// \brief Return a read_only pipe type for the specified type.
> +  QualType getReadPipeType(QualType T) const;
> +  /// \brief Return a write_only pipe type for the specified type.
> +  QualType getWritePipeType(QualType T) const;
>
>/// Gets the struct used to keep track of the extended descriptor for
>/// pointer to blocks.
>
> Modified: cfe/trunk/include/clang/AST/Type.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/AST/Type.h?rev=287343=287342=287343=diff
> 
> ==
> --- cfe/trunk/include/clang/AST/Type.h (original)
> +++ cfe/trunk/include/clang/AST/Type.h Fri Nov 18 08:10:54 2016
> @@ -5285,18 +5285,18 @@ class AtomicType : public Type, public l
>
>  /// PipeType - OpenCL20.
>  class PipeType : public Type, public llvm::FoldingSetNode {
> +protected:
>QualType ElementType;
> +  bool isRead;
>
> -  PipeType(QualType elemType, QualType CanonicalPtr) :
> +  PipeType(QualType elemType, QualType CanonicalPtr, bool isRead) :
>  Type(Pipe, CanonicalPtr, elemType->isDependentType(),
>   elemType->isInstantiationDependentType(),
>   elemType->isVariablyModifiedType(),
>   elemType->containsUnexpandedParameterPack()),
> -ElementType(elemType) {}
> -  friend class ASTContext;  // ASTContext creates these.
> +ElementType(elemType), isRead(isRead) {}
>
>  public:
> -
>QualType getElementType() const { return ElementType; }
>
>bool isSugared() const { return false; }
> @@ -5311,11 +5311,23 @@ public:
>  ID.AddPointer(T.getAsOpaquePtr());
>}
>
> -
>static bool classof(const Type *T) {
>  return T->getTypeClass() == Pipe;
>}
>
> +  bool isReadOnly() const { return isRead; }
> +};
> +
> +class ReadPipeType : public PipeType {
> +  ReadPipeType(QualType elemType, QualType CanonicalPtr) :
> +PipeType(elemType, CanonicalPtr, true) {}
> +  friend class ASTContext;  // ASTContext creates these.
> +};
> +
> +class WritePipeType : public PipeType {
> +  WritePipeType(QualType elemType, QualType CanonicalPtr) :
> +PipeType(elemType, CanonicalPtr, false) {}
> +  friend class ASTContext;  // ASTContext creates these.
>  };
>
>  /// A qualifier set is used to build a set of qualifiers.
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/Sema.h?rev=287343=287342=287343=diff
> 

[PATCH] D26911: readability-redundant-declarations: Fix crash

[Daniel Marjamäki via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL287540: readability-redundant-declaration: Fix crash 
(authored by danielmarjamaki).

Changed prior to commit:
  https://reviews.llvm.org/D26911?vs=78706=78715#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D26911

Files:
  clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
  clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp


Index: 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
@@ -28,6 +28,8 @@
   const auto *Prev = D->getPreviousDecl();
   if (!Prev)
 return;
+  if (!Prev->getLocation().isValid())
+return;
   if (Prev->getLocation() == D->getLocation())
 return;
 
Index: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
===
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
@@ -21,3 +21,10 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'f' declaration
 // CHECK-FIXES: {{^}}{{$}}
 static int f() {}
+
+// Original check crashed for the code below.
+namespace std {
+  typedef long unsigned int size_t;
+}
+void* operator new(std::size_t) __attribute__((__externally_visible__));
+void* operator new[](std::size_t) __attribute__((__externally_visible__));


Index: clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
@@ -28,6 +28,8 @@
   const auto *Prev = D->getPreviousDecl();
   if (!Prev)
 return;
+  if (!Prev->getLocation().isValid())
+return;
   if (Prev->getLocation() == D->getLocation())
 return;
 
Index: clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
@@ -21,3 +21,10 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'f' declaration
 // CHECK-FIXES: {{^}}{{$}}
 static int f() {}
+
+// Original check crashed for the code below.
+namespace std {
+  typedef long unsigned int size_t;
+}
+void* operator new(std::size_t) __attribute__((__externally_visible__));
+void* operator new[](std::size_t) __attribute__((__externally_visible__));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r287540 - readability-redundant-declaration: Fix crash

[Daniel Marjamaki via cfe-commits]

Author: danielmarjamaki
Date: Mon Nov 21 08:29:53 2016
New Revision: 287540

URL: http://llvm.org/viewvc/llvm-project?rev=287540=rev
Log:
readability-redundant-declaration: Fix crash

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


Modified:
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp?rev=287540=287539=287540=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp 
(original)
+++ 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp 
Mon Nov 21 08:29:53 2016
@@ -28,6 +28,8 @@ void RedundantDeclarationCheck::check(co
   const auto *Prev = D->getPreviousDecl();
   if (!Prev)
 return;
+  if (!Prev->getLocation().isValid())
+return;
   if (Prev->getLocation() == D->getLocation())
 return;
 

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp?rev=287540=287539=287540=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
Mon Nov 21 08:29:53 2016
@@ -21,3 +21,10 @@ static int f();
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'f' declaration
 // CHECK-FIXES: {{^}}{{$}}
 static int f() {}
+
+// Original check crashed for the code below.
+namespace std {
+  typedef long unsigned int size_t;
+}
+void* operator new(std::size_t) __attribute__((__externally_visible__));
+void* operator new[](std::size_t) __attribute__((__externally_visible__));


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

[PATCH] D26911: readability-redundant-declarations: Fix crash

[Haojian Wu via cfe-commits]

hokein accepted this revision.
hokein added a reviewer: hokein.
hokein added a comment.
This revision is now accepted and ready to land.

LGTM with a nit.




Comment at: clang-tidy/readability/RedundantDeclarationCheck.cpp:33
 return;
+  if (!Prev->getLocation().isValid())
+return;

Maybe put this statement in front of `if (Prev->getLocation() == 
D->getLocation())`?


Repository:
  rL LLVM

https://reviews.llvm.org/D26911



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

[PATCH] D26636: patch for llvm/clang bug 25965, suppress warning diagnostic on float-to-bool conversion when in condition context

[Melanie Blower via cfe-commits]

mibintc added a comment.

Does anyone have time to do a code review for this patch?


https://reviews.llvm.org/D26636



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

[PATCH] D22910: Add support for CXXOperatorCallExpr in Expr::HasSideEffects

[Andi via cfe-commits]

Abpostelnicu added a comment.

Can someone please show me an example on how to write a test for this patch?


https://reviews.llvm.org/D22910



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

[PATCH] D26909: [ClangFormat] Do not insert #include into code after #include block in the beginning of the file.

[Eric Liu via cfe-commits]

ioeric added a comment.

@djasper This is not very urgent. Feel free to leave it until you are back from 
vacation :)


https://reviews.llvm.org/D26909



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

[PATCH] D26909: [ClangFormat] Do not insert #include into code after #include block in the beginning of the file.

[Eric Liu via cfe-commits]

ioeric created this revision.
ioeric added a reviewer: djasper.
ioeric added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

This avoid inserting/deleting #include into/from:

- raw string literals containing #include.
- #if block.
- Special #include among declarations (e.g. functions).


https://reviews.llvm.org/D26909

Files:
  lib/Format/Format.cpp
  unittests/Format/CleanupTest.cpp

Index: unittests/Format/CleanupTest.cpp
===
--- unittests/Format/CleanupTest.cpp
+++ unittests/Format/CleanupTest.cpp
@@ -839,6 +839,64 @@
   EXPECT_EQ(Expected, apply(Code, Replaces));
 }
 
+TEST_F(CleanUpReplacementsTest, NoInsertionAfterCode) {
+  std::string Code = "#include \"a.h\"\n"
+ "void f() {}\n"
+ "#include \"b.h\"\n";
+  std::string Expected = "#include \"a.h\"\n"
+ "#include \"c.h\"\n"
+ "void f() {}\n"
+ "#include \"b.h\"\n";
+  tooling::Replacements Replaces = toReplacements(
+  {createInsertion("#include \"c.h\"")});
+  EXPECT_EQ(Expected, apply(Code, Replaces));
+}
+
+TEST_F(CleanUpReplacementsTest, NoInsertionAfterOtherDirective) {
+  std::string Code = "#include \"a.h\"\n"
+ "#ifdef X\n"
+ "#include \"b.h\"\n"
+ "#endif\n";
+  std::string Expected = "#include \"a.h\"\n"
+ "#include \"c.h\"\n"
+ "#ifdef X\n"
+ "#include \"b.h\"\n"
+ "#endif\n";
+  tooling::Replacements Replaces = toReplacements(
+  {createInsertion("#include \"c.h\"")});
+  EXPECT_EQ(Expected, apply(Code, Replaces));
+}
+
+TEST_F(CleanUpReplacementsTest, CanInsertAfterLongSystemInclude) {
+  std::string Code = "#include \"a.h\"\n"
+ "// comment\n\n"
+ "#include \n";
+  std::string Expected = "#include \"a.h\"\n"
+ "// comment\n\n"
+ "#include \n"
+ "#include \n";
+  tooling::Replacements Replaces =
+  toReplacements({createInsertion("#include ")});
+  EXPECT_EQ(Expected, apply(Code, Replaces));
+}
+
+TEST_F(CleanUpReplacementsTest, CanInsertAfterComment) {
+  std::string Code = "#include \"a.h\"\n"
+ "// Comment\n"
+ "/* Comment */\n"
+ "// Comment\n"
+ "#include \"b.h\"\n";
+  std::string Expected = "#include \"a.h\"\n"
+ "// Comment\n"
+ "/* Comment */\n"
+ "// Comment\n"
+ "#include \"b.h\"\n"
+ "#include \"c.h\"\n";
+  tooling::Replacements Replaces =
+  toReplacements({createInsertion("#include \"c.h\"")});
+  EXPECT_EQ(Expected, apply(Code, Replaces));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1514,10 +1514,23 @@
   return Replace.getOffset() == UINT_MAX && Replace.getLength() == 1;
 }
 
-void skipComments(Lexer , Token ) {
-  while (Tok.is(tok::comment))
-if (Lex.LexFromRawLexer(Tok))
-  return;
+// Returns the offset after skipping a sequence of tokens, matched by \p
+// GetOffsetAfterSequence, from the start of the code.
+// \p GetOffsetAfterSequence should be a function that matches a sequence of
+// tokens and returns an offset after the sequence.
+unsigned getOffsetAfterTokenSequence(
+StringRef FileName, StringRef Code, const FormatStyle ,
+std::function
+GetOffsetAfterSequense) {
+  std::unique_ptr Env =
+  Environment::CreateVirtualEnvironment(Code, FileName, /*Ranges=*/{});
+  const SourceManager  = Env->getSourceManager();
+  Lexer Lex(Env->getFileID(), SourceMgr.getBuffer(Env->getFileID()), SourceMgr,
+getFormattingLangOpts(Style));
+  Token Tok;
+  // Get the first token.
+  Lex.LexFromRawLexer(Tok);
+  return GetOffsetAfterSequense(SourceMgr, Lex, Tok);
 }
 
 // Check if a sequence of tokens is like "# ". If it is,
@@ -1527,31 +1540,80 @@
   bool Matched = Tok.is(tok::hash) && !Lex.LexFromRawLexer(Tok) &&
  Tok.is(tok::raw_identifier) &&
  Tok.getRawIdentifier() == Name && !Lex.LexFromRawLexer(Tok) &&
- Tok.is(tok::raw_identifier);
+ tok::raw_identifier;
   if (Matched)
 Lex.LexFromRawLexer(Tok);
   return Matched;
 }
 
+void skipComments(Lexer , Token ) {
+  while (Tok.is(tok::comment))
+if (Lex.LexFromRawLexer(Tok))
+  return;
+}
+
+// Returns the offset after header guard directives and any comments
+// before/after header guards. If no header guard presents in the code, this
+// will returns the offset 

[PATCH] D25660: [Analyzer] Checker for iterators dereferenced beyond their range.

[Balogh , Ádám via cfe-commits]

baloghadamsoftware added inline comments.



Comment at: test/Analysis/Inputs/system-header-simulator-for-iterators.h:62
+  ForwardIterator2 first2, ForwardIterator2 last2);
+}

Maybe we should merge this file with the system-header-simulator-cxx.h? It 
already contains a vector type but no iterators.


https://reviews.llvm.org/D25660



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

Re: [libcxx] r287435 - Fix stdint/cstdint modules

[Eric Fiselier via cfe-commits]

Hi Alex,

Sorry about the breakage. It's reverted in r287531.

/Eric

On Mon, Nov 21, 2016 at 3:59 AM, Alex L  wrote:

> Hello Eric,
>
> I think that this commit (r287435) might have broken the green dragon
> stage 2 ASAN + UBSAN buildbot:
>
> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/2643/
>
> I'm not sure why exactly the tests fail, since ASAN/UBSAN isn't triggering
> anything, and it's just a module error. The other bots have passed these
> tests successfully. Do you happen to know what might be causing the test
> failures?
>
> Thanks,
> Alex
>
> On 19 November 2016 at 03:29, Eric Fiselier via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ericwf
>> Date: Fri Nov 18 21:29:03 2016
>> New Revision: 287435
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=287435=rev
>> Log:
>> Fix stdint/cstdint modules
>>
>> Added:
>> libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
>> libcxx/trunk/test/libcxx/modules/cstdint_exports.sh.cpp
>> libcxx/trunk/test/libcxx/modules/inttypes_h_exports.sh.cpp
>> libcxx/trunk/test/libcxx/modules/stdint_h_exports.sh.cpp
>> Modified:
>> libcxx/trunk/include/module.modulemap
>>
>> Modified: libcxx/trunk/include/module.modulemap
>> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/mod
>> ule.modulemap?rev=287435=287434=287435=diff
>> 
>> ==
>> --- libcxx/trunk/include/module.modulemap (original)
>> +++ libcxx/trunk/include/module.modulemap Fri Nov 18 21:29:03 2016
>> @@ -21,47 +21,20 @@ module std [system] {
>>  module inttypes_h {
>>header "inttypes.h"
>>export stdint_h
>> -/*
>> -  export_macros
>> -PRId8, PRId16, PRId32, PRId64, PRIdFAST8, PRIdFAST16,
>> PRIdFAST32, PRIdFAST64, PRIdLEAST8, PRIdLEAST16, PRIdLEAST32, PRIdLEAST64,
>> PRIdMAX, PRIdPTR,
>> -PRIi8, PRIi16, PRIi32, PRIi64, PRIiFAST8, PRIiFAST16,
>> PRIiFAST32, PRIiFAST64, PRIiLEAST8, PRIiLEAST16, PRIiLEAST32, PRIiLEAST64,
>> PRIiMAX, PRIiPTR,
>> -PRIo8, PRIo16, PRIo32, PRIo64, PRIoFAST8, PRIoFAST16,
>> PRIoFAST32, PRIoFAST64, PRIoLEAST8, PRIoLEAST16, PRIoLEAST32, PRIoLEAST64,
>> PRIoMAX, PRIoPTR,
>> -PRIu8, PRIu16, PRIu32, PRIu64, PRIuFAST8, PRIuFAST16,
>> PRIuFAST32, PRIuFAST64, PRIuLEAST8, PRIuLEAST16, PRIuLEAST32, PRIuLEAST64,
>> PRIuMAX, PRIuPTR,
>> -PRIx8, PRIx16, PRIx32, PRIx64, PRIxFAST8, PRIxFAST16,
>> PRIxFAST32, PRIxFAST64, PRIxLEAST8, PRIxLEAST16, PRIxLEAST32, PRIxLEAST64,
>> PRIxMAX, PRIxPTR,
>> -PRIX8, PRIX16, PRIX32, PRIX64, PRIXFAST8, PRIXFAST16,
>> PRIXFAST32, PRIXFAST64, PRIXLEAST8, PRIXLEAST16, PRIXLEAST32, PRIXLEAST64,
>> PRIXMAX, PRIXPTR,
>> -SCNd8, SCNd16, SCNd32, SCNd64, SCNdFAST8, SCNdFAST16,
>> SCNdFAST32, SCNdFAST64, SCNdLEAST8, SCNdLEAST16, SCNdLEAST32, SCNdLEAST64,
>> SCNdMAX, SCNdPTR,
>> -SCNi8, SCNi16, SCNi32, SCNi64, SCNiFAST8, SCNiFAST16,
>> SCNiFAST32, SCNiFAST64, SCNiLEAST8, SCNiLEAST16, SCNiLEAST32, SCNiLEAST64,
>> SCNiMAX, SCNiPTR,
>> -SCNo8, SCNo16, SCNo32, SCNo64, SCNoFAST8, SCNoFAST16,
>> SCNoFAST32, SCNoFAST64, SCNoLEAST8, SCNoLEAST16, SCNoLEAST32, SCNoLEAST64,
>> SCNoMAX, SCNoPTR,
>> -SCNu8, SCNu16, SCNu32, SCNu64, SCNuFAST8, SCNuFAST16,
>> SCNuFAST32, SCNuFAST64, SCNuLEAST8, SCNuLEAST16, SCNuLEAST32, SCNuLEAST64,
>> SCNuMAX, SCNuPTR,
>> -SCNx8, SCNx16, SCNx32, SCNx64, SCNxFAST8, SCNxFAST16,
>> SCNxFAST32, SCNxFAST64, SCNxLEAST8, SCNxLEAST16, SCNxLEAST32, SCNxLEAST64,
>> SCNxMAX, SCNxPTR,
>> -SCNX8, SCNX16, SCNX32, SCNX64, SCNXFAST8, SCNXFAST16,
>> SCNXFAST32, SCNXFAST64, SCNXLEAST8, SCNXLEAST16, SCNXLEAST32, SCNXLEAST64,
>> SCNXMAX, SCNXPTR
>> -*/
>>export *
>>  }
>>  //  provided by compiler.
>>  //  provided by compiler or C library.
>>  module locale_h {
>>header "locale.h"
>> -/*
>> -  export_macros LC_ALL LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC
>> LC_TIME
>> -*/
>>export *
>>  }
>>  module math_h {
>>header "math.h"
>> -/*
>> -  export_macros FP_FAST_FMA, FP_FAST_FMAF, FP_FAST_FMAL, FP_ILOGBO,
>> FP_ILOGBNAN,
>> -FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL,
>> FP_ZERO,
>> -HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN,
>> -MATH_ERRNO, MATH_ERREXCEPT, math_errhandling
>> -*/
>>export *
>>  }
>>  module setjmp_h {
>>header "setjmp.h"
>> -/*
>> -  export_macros setjmp
>> -*/
>>export *
>>  }
>>  // FIXME:  is missing.
>> @@ -72,30 +45,22 @@ module std [system] {
>>// 's __need_* macros require textual inclusion.
>>textual header "stddef.h"
>>  }
>> -//  provided by compiler or C library.
>> +module stdint_h {
>> +  header "stdint.h"
>> +  export *
>> +}
>>  module stdio_h {
>>// 's __need_* macros require textual inclusion.
>>textual header "stdio.h"
>> -/*

[libcxx] r287531 - Revert r287435 because of OS X test failures

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Mon Nov 21 05:26:10 2016
New Revision: 287531

URL: http://llvm.org/viewvc/llvm-project?rev=287531=rev
Log:
Revert r287435 because of OS X test failures

Removed:
libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
libcxx/trunk/test/libcxx/modules/cstdint_exports.sh.cpp
libcxx/trunk/test/libcxx/modules/inttypes_h_exports.sh.cpp
libcxx/trunk/test/libcxx/modules/stdint_h_exports.sh.cpp
Modified:
libcxx/trunk/include/module.modulemap

Modified: libcxx/trunk/include/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/module.modulemap?rev=287531=287530=287531=diff
==
--- libcxx/trunk/include/module.modulemap (original)
+++ libcxx/trunk/include/module.modulemap Mon Nov 21 05:26:10 2016
@@ -21,20 +21,47 @@ module std [system] {
 module inttypes_h {
   header "inttypes.h"
   export stdint_h
+/*
+  export_macros
+PRId8, PRId16, PRId32, PRId64, PRIdFAST8, PRIdFAST16, PRIdFAST32, 
PRIdFAST64, PRIdLEAST8, PRIdLEAST16, PRIdLEAST32, PRIdLEAST64, PRIdMAX, PRIdPTR,
+PRIi8, PRIi16, PRIi32, PRIi64, PRIiFAST8, PRIiFAST16, PRIiFAST32, 
PRIiFAST64, PRIiLEAST8, PRIiLEAST16, PRIiLEAST32, PRIiLEAST64, PRIiMAX, PRIiPTR,
+PRIo8, PRIo16, PRIo32, PRIo64, PRIoFAST8, PRIoFAST16, PRIoFAST32, 
PRIoFAST64, PRIoLEAST8, PRIoLEAST16, PRIoLEAST32, PRIoLEAST64, PRIoMAX, PRIoPTR,
+PRIu8, PRIu16, PRIu32, PRIu64, PRIuFAST8, PRIuFAST16, PRIuFAST32, 
PRIuFAST64, PRIuLEAST8, PRIuLEAST16, PRIuLEAST32, PRIuLEAST64, PRIuMAX, PRIuPTR,
+PRIx8, PRIx16, PRIx32, PRIx64, PRIxFAST8, PRIxFAST16, PRIxFAST32, 
PRIxFAST64, PRIxLEAST8, PRIxLEAST16, PRIxLEAST32, PRIxLEAST64, PRIxMAX, PRIxPTR,
+PRIX8, PRIX16, PRIX32, PRIX64, PRIXFAST8, PRIXFAST16, PRIXFAST32, 
PRIXFAST64, PRIXLEAST8, PRIXLEAST16, PRIXLEAST32, PRIXLEAST64, PRIXMAX, PRIXPTR,
+SCNd8, SCNd16, SCNd32, SCNd64, SCNdFAST8, SCNdFAST16, SCNdFAST32, 
SCNdFAST64, SCNdLEAST8, SCNdLEAST16, SCNdLEAST32, SCNdLEAST64, SCNdMAX, SCNdPTR,
+SCNi8, SCNi16, SCNi32, SCNi64, SCNiFAST8, SCNiFAST16, SCNiFAST32, 
SCNiFAST64, SCNiLEAST8, SCNiLEAST16, SCNiLEAST32, SCNiLEAST64, SCNiMAX, SCNiPTR,
+SCNo8, SCNo16, SCNo32, SCNo64, SCNoFAST8, SCNoFAST16, SCNoFAST32, 
SCNoFAST64, SCNoLEAST8, SCNoLEAST16, SCNoLEAST32, SCNoLEAST64, SCNoMAX, SCNoPTR,
+SCNu8, SCNu16, SCNu32, SCNu64, SCNuFAST8, SCNuFAST16, SCNuFAST32, 
SCNuFAST64, SCNuLEAST8, SCNuLEAST16, SCNuLEAST32, SCNuLEAST64, SCNuMAX, SCNuPTR,
+SCNx8, SCNx16, SCNx32, SCNx64, SCNxFAST8, SCNxFAST16, SCNxFAST32, 
SCNxFAST64, SCNxLEAST8, SCNxLEAST16, SCNxLEAST32, SCNxLEAST64, SCNxMAX, SCNxPTR,
+SCNX8, SCNX16, SCNX32, SCNX64, SCNXFAST8, SCNXFAST16, SCNXFAST32, 
SCNXFAST64, SCNXLEAST8, SCNXLEAST16, SCNXLEAST32, SCNXLEAST64, SCNXMAX, SCNXPTR
+*/
   export *
 }
 //  provided by compiler.
 //  provided by compiler or C library.
 module locale_h {
   header "locale.h"
+/*
+  export_macros LC_ALL LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC LC_TIME
+*/
   export *
 }
 module math_h {
   header "math.h"
+/*
+  export_macros FP_FAST_FMA, FP_FAST_FMAF, FP_FAST_FMAL, FP_ILOGBO, 
FP_ILOGBNAN,
+FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO,
+HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN,
+MATH_ERRNO, MATH_ERREXCEPT, math_errhandling
+*/
   export *
 }
 module setjmp_h {
   header "setjmp.h"
+/*
+  export_macros setjmp
+*/
   export *
 }
 // FIXME:  is missing.
@@ -45,22 +72,30 @@ module std [system] {
   // 's __need_* macros require textual inclusion.
   textual header "stddef.h"
 }
-module stdint_h {
-  header "stdint.h"
-  export *
-}
+//  provided by compiler or C library.
 module stdio_h {
   // 's __need_* macros require textual inclusion.
   textual header "stdio.h"
+/*
+  export_macros BUFSIZ, EOF, FILENAME_MAX, FOPEN_MAX, L_tmpnam, NULL,
+SEEK_CUR, SEEK_END, SEEK_SET, TMP_MAX, _IOFBF, _IOLBF,
+stdin, stdout, stderr
+*/
   export *
 }
 module stdlib_h {
   // 's __need_* macros require textual inclusion.
   textual header "stdlib.h"
+/*
+  export_macros RAND_MAX
+*/
   export *
 }
 module string_h {
   header "string.h"
+/*
+  export_macros NULL
+*/
   export *
 }
 // FIXME:  is missing.
@@ -68,10 +103,16 @@ module std [system] {
 module wchar_h {
   // 's __need_* macros require textual inclusion.
   textual header "wchar.h"
+/*
+  export_macros NULL, WCHAR_MAX, WCHAR_MIN, WEOF
+*/
   export *
 }
 module wctype_h {
   header "wctype.h"
+/*
+  export_macros WEOF
+*/
   export *
 }
   }
@@ -107,19 +148,67 @@ module std [system] {
 }
 module cerrno {
   header "cerrno"
+/*
+  export_macros

[PATCH] D26664: [ObjC] Prevent infinite loops when iterating over redeclaration of a method that was declared in an invalid interface

[Alex Lorenz via cfe-commits]

arphaman added a comment.

I managed to get rid of the extra function and simplify the check thanks to 
suggestions from Erik.


Repository:
  rL LLVM

https://reviews.llvm.org/D26664



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

[PATCH] D26664: [ObjC] Prevent infinite loops when iterating over redeclaration of a method that was declared in an invalid interface

[Alex Lorenz via cfe-commits]

This revision was automatically updated to reflect the committed changes.
arphaman marked 6 inline comments as done.
Closed by commit rL287530: [ObjC] Prevent infinite loops when iterating over 
redeclaration (authored by arphaman).

Changed prior to commit:
  https://reviews.llvm.org/D26664?vs=77980=78699#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D26664

Files:
  cfe/trunk/lib/AST/DeclObjC.cpp
  cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m


Index: cfe/trunk/lib/AST/DeclObjC.cpp
===
--- cfe/trunk/lib/AST/DeclObjC.cpp
+++ cfe/trunk/lib/AST/DeclObjC.cpp
@@ -870,6 +870,12 @@
 }
   }
 
+  // Ensure that the discovered method redeclaration has a valid declaration
+  // context. Used to prevent infinite loops when iterating redeclarations in
+  // a partially invalid AST.
+  if (Redecl && cast(Redecl->getDeclContext())->isInvalidDecl())
+Redecl = nullptr;
+
   if (!Redecl && isRedeclaration()) {
 // This is the last redeclaration, go back to the first method.
 return cast(CtxD)->getMethod(getSelector(),
Index: cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
===
--- cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
+++ cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wdocumentation -Wno-objc-root-class 
%s
+// rdar://29220965
+
+@interface InvalidInterface { // expected-note {{previous definition is here}}
+  int *_property;
+}
+
+@end
+
+/*!
+ */
+
+@interface InvalidInterface // expected-error {{duplicate interface definition 
for class 'InvalidInterface'}}
+@property int *property;
+
+-(void) method;
+@end
+
+@implementation InvalidInterface
+-(void) method { }
+@end


Index: cfe/trunk/lib/AST/DeclObjC.cpp
===
--- cfe/trunk/lib/AST/DeclObjC.cpp
+++ cfe/trunk/lib/AST/DeclObjC.cpp
@@ -870,6 +870,12 @@
 }
   }
 
+  // Ensure that the discovered method redeclaration has a valid declaration
+  // context. Used to prevent infinite loops when iterating redeclarations in
+  // a partially invalid AST.
+  if (Redecl && cast(Redecl->getDeclContext())->isInvalidDecl())
+Redecl = nullptr;
+
   if (!Redecl && isRedeclaration()) {
 // This is the last redeclaration, go back to the first method.
 return cast(CtxD)->getMethod(getSelector(),
Index: cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
===
--- cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
+++ cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wdocumentation -Wno-objc-root-class %s
+// rdar://29220965
+
+@interface InvalidInterface { // expected-note {{previous definition is here}}
+  int *_property;
+}
+
+@end
+
+/*!
+ */
+
+@interface InvalidInterface // expected-error {{duplicate interface definition for class 'InvalidInterface'}}
+@property int *property;
+
+-(void) method;
+@end
+
+@implementation InvalidInterface
+-(void) method { }
+@end
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r287530 - [ObjC] Prevent infinite loops when iterating over redeclaration

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Mon Nov 21 05:16:30 2016
New Revision: 287530

URL: http://llvm.org/viewvc/llvm-project?rev=287530=rev
Log:
[ObjC] Prevent infinite loops when iterating over redeclaration
of a method that was declared in an invalid interface

This commit fixes an infinite loop that occurs when clang tries to iterate over
redeclaration of a method that was declared in an invalid @interface. The
existing validity checks don't catch this as that @interface is a duplicate of
a previously declared valid @interface declaration, so we have to verify that
the found redeclaration is in a valid declaration context.

rdar://29220965

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

Added:
cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
Modified:
cfe/trunk/lib/AST/DeclObjC.cpp

Modified: cfe/trunk/lib/AST/DeclObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclObjC.cpp?rev=287530=287529=287530=diff
==
--- cfe/trunk/lib/AST/DeclObjC.cpp (original)
+++ cfe/trunk/lib/AST/DeclObjC.cpp Mon Nov 21 05:16:30 2016
@@ -870,6 +870,12 @@ ObjCMethodDecl *ObjCMethodDecl::getNextR
 }
   }
 
+  // Ensure that the discovered method redeclaration has a valid declaration
+  // context. Used to prevent infinite loops when iterating redeclarations in
+  // a partially invalid AST.
+  if (Redecl && cast(Redecl->getDeclContext())->isInvalidDecl())
+Redecl = nullptr;
+
   if (!Redecl && isRedeclaration()) {
 // This is the last redeclaration, go back to the first method.
 return cast(CtxD)->getMethod(getSelector(),

Added: cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m?rev=287530=auto
==
--- cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m (added)
+++ cfe/trunk/test/SemaObjC/method-redecls-invalid-interface.m Mon Nov 21 
05:16:30 2016
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wdocumentation -Wno-objc-root-class 
%s
+// rdar://29220965
+
+@interface InvalidInterface { // expected-note {{previous definition is here}}
+  int *_property;
+}
+
+@end
+
+/*!
+ */
+
+@interface InvalidInterface // expected-error {{duplicate interface definition 
for class 'InvalidInterface'}}
+@property int *property;
+
+-(void) method;
+@end
+
+@implementation InvalidInterface
+-(void) method { }
+@end


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

[PATCH] D26234: [Frontend] Add a predefined macro that describes the Objective-C bool type

[Alex Lorenz via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL287529: [Frontend] Add a predefined macro that describes the 
Objective-C bool type (authored by arphaman).

Changed prior to commit:
  https://reviews.llvm.org/D26234?vs=76680=78698#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D26234

Files:
  cfe/trunk/lib/Frontend/InitPreprocessor.cpp
  cfe/trunk/test/Frontend/objc-bool-is-bool.m


Index: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
===
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp
@@ -591,6 +591,9 @@
 Builder.defineMacro("OBJC_ZEROCOST_EXCEPTIONS");
 }
 
+Builder.defineMacro("__OBJC_BOOL_IS_BOOL",
+Twine(TI.useSignedCharForObjCBool() ? "0" : "1"));
+
 if (LangOpts.getGC() != LangOptions::NonGC)
   Builder.defineMacro("__OBJC_GC__");
 
Index: cfe/trunk/test/Frontend/objc-bool-is-bool.m
===
--- cfe/trunk/test/Frontend/objc-bool-is-bool.m
+++ cfe/trunk/test/Frontend/objc-bool-is-bool.m
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -E -dM -triple=armv7k-apple-watchos %s | 
FileCheck --check-prefix=BOOL %s
+// RUN: %clang_cc1 -fsyntax-only -E -dM -triple=x86_64-apple-darwin16 %s | 
FileCheck --check-prefix=CHAR %s
+// RUN: %clang_cc1 -x c -fsyntax-only -E -dM -triple=x86_64-apple-darwin16 %s 
| FileCheck --check-prefix=NONE %s
+
+// rdar://21170440
+
+// BOOL: #define __OBJC_BOOL_IS_BOOL 1
+// BOOL-NOT: #define __OBJC_BOOL_IS_BOOL 0
+
+// CHAR: #define __OBJC_BOOL_IS_BOOL 0
+// CHAR-NOT: #define __OBJC_BOOL_IS_BOOL 1
+
+// NONE-NOT: __OBJC_BOOL_IS_BOOL


Index: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
===
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp
@@ -591,6 +591,9 @@
 Builder.defineMacro("OBJC_ZEROCOST_EXCEPTIONS");
 }
 
+Builder.defineMacro("__OBJC_BOOL_IS_BOOL",
+Twine(TI.useSignedCharForObjCBool() ? "0" : "1"));
+
 if (LangOpts.getGC() != LangOptions::NonGC)
   Builder.defineMacro("__OBJC_GC__");
 
Index: cfe/trunk/test/Frontend/objc-bool-is-bool.m
===
--- cfe/trunk/test/Frontend/objc-bool-is-bool.m
+++ cfe/trunk/test/Frontend/objc-bool-is-bool.m
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -E -dM -triple=armv7k-apple-watchos %s | FileCheck --check-prefix=BOOL %s
+// RUN: %clang_cc1 -fsyntax-only -E -dM -triple=x86_64-apple-darwin16 %s | FileCheck --check-prefix=CHAR %s
+// RUN: %clang_cc1 -x c -fsyntax-only -E -dM -triple=x86_64-apple-darwin16 %s | FileCheck --check-prefix=NONE %s
+
+// rdar://21170440
+
+// BOOL: #define __OBJC_BOOL_IS_BOOL 1
+// BOOL-NOT: #define __OBJC_BOOL_IS_BOOL 0
+
+// CHAR: #define __OBJC_BOOL_IS_BOOL 0
+// CHAR-NOT: #define __OBJC_BOOL_IS_BOOL 1
+
+// NONE-NOT: __OBJC_BOOL_IS_BOOL
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r287529 - [Frontend] Add a predefined macro that describes the Objective-C bool type

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Mon Nov 21 05:05:15 2016
New Revision: 287529

URL: http://llvm.org/viewvc/llvm-project?rev=287529=rev
Log:
[Frontend] Add a predefined macro that describes the Objective-C bool type

This commit adds a new predefined macro named __OBJC_BOOL_IS_BOOL that describes
the Objective-C boolean type: its value is zero if the Objective-C boolean uses
the signed character type, otherwise its value is one as the Objective-C boolean
uses the builtin boolean type.

rdar://21170440

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

Added:
cfe/trunk/test/Frontend/objc-bool-is-bool.m
Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=287529=287528=287529=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Mon Nov 21 05:05:15 2016
@@ -591,6 +591,9 @@ static void InitializePredefinedMacros(c
 Builder.defineMacro("OBJC_ZEROCOST_EXCEPTIONS");
 }
 
+Builder.defineMacro("__OBJC_BOOL_IS_BOOL",
+Twine(TI.useSignedCharForObjCBool() ? "0" : "1"));
+
 if (LangOpts.getGC() != LangOptions::NonGC)
   Builder.defineMacro("__OBJC_GC__");
 

Added: cfe/trunk/test/Frontend/objc-bool-is-bool.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/objc-bool-is-bool.m?rev=287529=auto
==
--- cfe/trunk/test/Frontend/objc-bool-is-bool.m (added)
+++ cfe/trunk/test/Frontend/objc-bool-is-bool.m Mon Nov 21 05:05:15 2016
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -E -dM -triple=armv7k-apple-watchos %s | 
FileCheck --check-prefix=BOOL %s
+// RUN: %clang_cc1 -fsyntax-only -E -dM -triple=x86_64-apple-darwin16 %s | 
FileCheck --check-prefix=CHAR %s
+// RUN: %clang_cc1 -x c -fsyntax-only -E -dM -triple=x86_64-apple-darwin16 %s 
| FileCheck --check-prefix=NONE %s
+
+// rdar://21170440
+
+// BOOL: #define __OBJC_BOOL_IS_BOOL 1
+// BOOL-NOT: #define __OBJC_BOOL_IS_BOOL 0
+
+// CHAR: #define __OBJC_BOOL_IS_BOOL 0
+// CHAR-NOT: #define __OBJC_BOOL_IS_BOOL 1
+
+// NONE-NOT: __OBJC_BOOL_IS_BOOL


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

Re: [libcxx] r287435 - Fix stdint/cstdint modules

[Alex L via cfe-commits]

Hello Eric,

I think that this commit (r287435) might have broken the green dragon stage
2 ASAN + UBSAN buildbot:

http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/2643/

I'm not sure why exactly the tests fail, since ASAN/UBSAN isn't triggering
anything, and it's just a module error. The other bots have passed these
tests successfully. Do you happen to know what might be causing the test
failures?

Thanks,
Alex

On 19 November 2016 at 03:29, Eric Fiselier via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ericwf
> Date: Fri Nov 18 21:29:03 2016
> New Revision: 287435
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287435=rev
> Log:
> Fix stdint/cstdint modules
>
> Added:
> libcxx/trunk/test/libcxx/modules/cinttypes_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/cstdint_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/inttypes_h_exports.sh.cpp
> libcxx/trunk/test/libcxx/modules/stdint_h_exports.sh.cpp
> Modified:
> libcxx/trunk/include/module.modulemap
>
> Modified: libcxx/trunk/include/module.modulemap
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/
> module.modulemap?rev=287435=287434=287435=diff
> 
> ==
> --- libcxx/trunk/include/module.modulemap (original)
> +++ libcxx/trunk/include/module.modulemap Fri Nov 18 21:29:03 2016
> @@ -21,47 +21,20 @@ module std [system] {
>  module inttypes_h {
>header "inttypes.h"
>export stdint_h
> -/*
> -  export_macros
> -PRId8, PRId16, PRId32, PRId64, PRIdFAST8, PRIdFAST16, PRIdFAST32,
> PRIdFAST64, PRIdLEAST8, PRIdLEAST16, PRIdLEAST32, PRIdLEAST64, PRIdMAX,
> PRIdPTR,
> -PRIi8, PRIi16, PRIi32, PRIi64, PRIiFAST8, PRIiFAST16, PRIiFAST32,
> PRIiFAST64, PRIiLEAST8, PRIiLEAST16, PRIiLEAST32, PRIiLEAST64, PRIiMAX,
> PRIiPTR,
> -PRIo8, PRIo16, PRIo32, PRIo64, PRIoFAST8, PRIoFAST16, PRIoFAST32,
> PRIoFAST64, PRIoLEAST8, PRIoLEAST16, PRIoLEAST32, PRIoLEAST64, PRIoMAX,
> PRIoPTR,
> -PRIu8, PRIu16, PRIu32, PRIu64, PRIuFAST8, PRIuFAST16, PRIuFAST32,
> PRIuFAST64, PRIuLEAST8, PRIuLEAST16, PRIuLEAST32, PRIuLEAST64, PRIuMAX,
> PRIuPTR,
> -PRIx8, PRIx16, PRIx32, PRIx64, PRIxFAST8, PRIxFAST16, PRIxFAST32,
> PRIxFAST64, PRIxLEAST8, PRIxLEAST16, PRIxLEAST32, PRIxLEAST64, PRIxMAX,
> PRIxPTR,
> -PRIX8, PRIX16, PRIX32, PRIX64, PRIXFAST8, PRIXFAST16, PRIXFAST32,
> PRIXFAST64, PRIXLEAST8, PRIXLEAST16, PRIXLEAST32, PRIXLEAST64, PRIXMAX,
> PRIXPTR,
> -SCNd8, SCNd16, SCNd32, SCNd64, SCNdFAST8, SCNdFAST16, SCNdFAST32,
> SCNdFAST64, SCNdLEAST8, SCNdLEAST16, SCNdLEAST32, SCNdLEAST64, SCNdMAX,
> SCNdPTR,
> -SCNi8, SCNi16, SCNi32, SCNi64, SCNiFAST8, SCNiFAST16, SCNiFAST32,
> SCNiFAST64, SCNiLEAST8, SCNiLEAST16, SCNiLEAST32, SCNiLEAST64, SCNiMAX,
> SCNiPTR,
> -SCNo8, SCNo16, SCNo32, SCNo64, SCNoFAST8, SCNoFAST16, SCNoFAST32,
> SCNoFAST64, SCNoLEAST8, SCNoLEAST16, SCNoLEAST32, SCNoLEAST64, SCNoMAX,
> SCNoPTR,
> -SCNu8, SCNu16, SCNu32, SCNu64, SCNuFAST8, SCNuFAST16, SCNuFAST32,
> SCNuFAST64, SCNuLEAST8, SCNuLEAST16, SCNuLEAST32, SCNuLEAST64, SCNuMAX,
> SCNuPTR,
> -SCNx8, SCNx16, SCNx32, SCNx64, SCNxFAST8, SCNxFAST16, SCNxFAST32,
> SCNxFAST64, SCNxLEAST8, SCNxLEAST16, SCNxLEAST32, SCNxLEAST64, SCNxMAX,
> SCNxPTR,
> -SCNX8, SCNX16, SCNX32, SCNX64, SCNXFAST8, SCNXFAST16, SCNXFAST32,
> SCNXFAST64, SCNXLEAST8, SCNXLEAST16, SCNXLEAST32, SCNXLEAST64, SCNXMAX,
> SCNXPTR
> -*/
>export *
>  }
>  //  provided by compiler.
>  //  provided by compiler or C library.
>  module locale_h {
>header "locale.h"
> -/*
> -  export_macros LC_ALL LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC
> LC_TIME
> -*/
>export *
>  }
>  module math_h {
>header "math.h"
> -/*
> -  export_macros FP_FAST_FMA, FP_FAST_FMAF, FP_FAST_FMAL, FP_ILOGBO,
> FP_ILOGBNAN,
> -FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO,
> -HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, NAN,
> -MATH_ERRNO, MATH_ERREXCEPT, math_errhandling
> -*/
>export *
>  }
>  module setjmp_h {
>header "setjmp.h"
> -/*
> -  export_macros setjmp
> -*/
>export *
>  }
>  // FIXME:  is missing.
> @@ -72,30 +45,22 @@ module std [system] {
>// 's __need_* macros require textual inclusion.
>textual header "stddef.h"
>  }
> -//  provided by compiler or C library.
> +module stdint_h {
> +  header "stdint.h"
> +  export *
> +}
>  module stdio_h {
>// 's __need_* macros require textual inclusion.
>textual header "stdio.h"
> -/*
> -  export_macros BUFSIZ, EOF, FILENAME_MAX, FOPEN_MAX, L_tmpnam, NULL,
> -SEEK_CUR, SEEK_END, SEEK_SET, TMP_MAX, _IOFBF, _IOLBF,
> -stdin, stdout, stderr
> -*/
>export *
>  }
>  module stdlib_h {
>// 's __need_* 

[PATCH] D26858: [AArch64] Don't constrain the assembler when using -mgeneral-regs-only

[James Molloy via cfe-commits]

jmolloy accepted this revision.
jmolloy added a comment.
This revision is now accepted and ready to land.

It's a bit awkward that you need to copy the LastOpt loop from below, but I 
can't see a simpler way to do this.

LGTM.


https://reviews.llvm.org/D26858



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

[PATCH] D26606: Protect tests for std::uninitialized_{copy, fill} under libcpp-no-exceptions

[James Molloy via cfe-commits]

jmolloy added a comment.

Hi,

This looks fairly obviously correct to me, but perhaps someone more familiar 
with libcxx should look too: Asiri?

James


https://reviews.llvm.org/D26606



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

[PATCH] D26606: Protect tests for std::uninitialized_{copy, fill} under libcpp-no-exceptions

[Roger Ferrer Ibanez via cfe-commits]

rogfer01 added a comment.

Ping? :)


https://reviews.llvm.org/D26606



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