[PATCH] D28315: Update tools to use new getStyle API

[Antonio Maiorano via Phabricator via cfe-commits]

amaiorano added a comment.

In https://reviews.llvm.org/D28315#641032, @amaiorano wrote:

> In https://reviews.llvm.org/D28315#639559, @ioeric wrote:
>
> > I ran `ninja check-all` with https://reviews.llvm.org/D28081 and 
> > https://reviews.llvm.org/D28315 (in Linux), and some lit tests failed, 
> > namely:
> >
> >   Clang :: Format/style-on-command-line.cpp
>
>
> This was the test that is explicitly disabled on Windows. I enabled it 
> locally and modified the test to match the modified output and expected 
> non-zero result (patch forth-coming once I understand what's up with the 
> failed tests you mention below...)
>
> >   Clang Tools :: clang-apply-replacements/basic.cpp
> >   Clang Tools :: clang-apply-replacements/conflict.cpp
> >   Clang Tools :: clang-apply-replacements/crlf.cpp
> >   Clang Tools :: clang-apply-replacements/format.cpp
> >   Clang Tools :: clang-rename/ClassReplacements.cpp
> > 
> >   Error message I am seeing: `Expected must be checked before access or 
> > destruction.`
> >   
> >   Could you double check? Thanks!
>
> These tests pass for me. For example, when I run llvm-lit explicitly on 
> clang-apply-replacements/basic.cpp, I get:
>
>   C:\code\llvm-build-msvc\Debug\bin>llvm-lit.py -a -v 
> c:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp
>   -- Testing: 1 tests, 1 threads --
>   PASS: Clang Tools :: clang-apply-replacements/basic.cpp (1 of 1)
>   Script:
>   --
>   mkdir -p 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
>   grep -Ev "// *[A-Z-]+:" 
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h
>  > 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h
>   sed 
> "s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
>  
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file1.yaml
>  > 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/file1.yaml
>   sed 
> "s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
>  
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file2.yaml
>  > 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/file2.yaml
>   clang-apply-replacements 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
>   FileCheck 
> -input-file=C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h
>  
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h
>   ls -1 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
>  | FileCheck 
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp 
> --check-prefix=YAML
>   grep -Ev "// *[A-Z-]+:" 
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h
>  > 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h
>   clang-apply-replacements -remove-change-desc-files 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
>   ls -1 
> C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
>  | FileCheck 
> C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp 
> --check-prefix=NO_YAML
>   --
>   Exit Code: 0
>  
>   Command Output (stdout):
>   --
>   $ "mkdir" "-p" 
> "C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic"
>   $ "grep" "-Ev" "// *[A-Z-]+:" 
> "C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h"
>   $ "sed" 
> "s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
>  
> "C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file1.yaml"
>   $ "sed" 
> "s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
>  
> "C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file2.yaml"
>   $ "clang-apply-replacements" 
> "C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic"
>   $ "FileCheck" 
> "-input-file=C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h"
>  
> "C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h"
>   $ "ls" "-1" 
> "C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic"
>   $ "FileCheck" 
> 

[PATCH] D24969: [Sema] Use the instantiated name of destructors in FindInstantiatedDecl and RebuildMemberExpr

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

Richard, does the updated patch look OK?


https://reviews.llvm.org/D24969



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

[PATCH] D28018: AMD family 17h (znver1) enablement

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291544: AMD family 17h (znver1) enablement (authored by 
ctopper).

Changed prior to commit:
  https://reviews.llvm.org/D28018?vs=83626=83779#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28018

Files:
  cfe/trunk/lib/Basic/Targets.cpp
  cfe/trunk/test/Driver/x86-march.c
  cfe/trunk/test/Frontend/x86-target-cpu.c
  cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Index: cfe/trunk/lib/Basic/Targets.cpp
===
--- cfe/trunk/lib/Basic/Targets.cpp
+++ cfe/trunk/lib/Basic/Targets.cpp
@@ -2663,6 +2663,12 @@
 CK_BDVER4,
 //@}
 
+/// \name zen
+/// Zen architecture processors.
+//@{
+CK_ZNVER1,
+//@}
+
 /// This specification is deprecated and will be removed in the future.
 /// Users should prefer \see CK_K8.
 // FIXME: Warn on this when the CPU is set to it.
@@ -2744,6 +2750,7 @@
 .Case("bdver2", CK_BDVER2)
 .Case("bdver3", CK_BDVER3)
 .Case("bdver4", CK_BDVER4)
+.Case("znver1", CK_ZNVER1)
 .Case("x86-64", CK_x86_64)
 .Case("geode", CK_Geode)
 .Default(CK_Generic);
@@ -2943,6 +2950,7 @@
 case CK_BDVER2:
 case CK_BDVER3:
 case CK_BDVER4:
+case CK_ZNVER1:
 case CK_x86_64:
   return true;
 }
@@ -3190,6 +3198,33 @@
 setFeatureEnabledImpl(Features, "cx16", true);
 setFeatureEnabledImpl(Features, "fxsr", true);
 break;
+  case CK_ZNVER1:
+setFeatureEnabledImpl(Features, "adx", true);
+setFeatureEnabledImpl(Features, "aes", true);
+setFeatureEnabledImpl(Features, "avx2", true);
+setFeatureEnabledImpl(Features, "bmi", true);
+setFeatureEnabledImpl(Features, "bmi2", true);
+setFeatureEnabledImpl(Features, "clflushopt", true);
+setFeatureEnabledImpl(Features, "cx16", true);
+setFeatureEnabledImpl(Features, "f16c", true);
+setFeatureEnabledImpl(Features, "fma", true);
+setFeatureEnabledImpl(Features, "fsgsbase", true);
+setFeatureEnabledImpl(Features, "fxsr", true);
+setFeatureEnabledImpl(Features, "lzcnt", true);
+setFeatureEnabledImpl(Features, "mwaitx", true);
+setFeatureEnabledImpl(Features, "movbe", true);
+setFeatureEnabledImpl(Features, "pclmul", true);
+setFeatureEnabledImpl(Features, "popcnt", true);
+setFeatureEnabledImpl(Features, "prfchw", true);
+setFeatureEnabledImpl(Features, "rdrnd", true);
+setFeatureEnabledImpl(Features, "rdseed", true);
+setFeatureEnabledImpl(Features, "sha", true);
+setFeatureEnabledImpl(Features, "sse4a", true);
+setFeatureEnabledImpl(Features, "xsave", true);
+setFeatureEnabledImpl(Features, "xsavec", true);
+setFeatureEnabledImpl(Features, "xsaveopt", true);
+setFeatureEnabledImpl(Features, "xsaves", true);
+break;
   case CK_BDVER4:
 setFeatureEnabledImpl(Features, "avx2", true);
 setFeatureEnabledImpl(Features, "bmi2", true);
@@ -3741,6 +3776,9 @@
   case CK_BDVER4:
 defineCPUMacros(Builder, "bdver4");
 break;
+  case CK_ZNVER1:
+defineCPUMacros(Builder, "znver1");
+break;
   case CK_Geode:
 defineCPUMacros(Builder, "geode");
 break;
Index: cfe/trunk/test/Preprocessor/predefined-arch-macros.c
===
--- cfe/trunk/test/Preprocessor/predefined-arch-macros.c
+++ cfe/trunk/test/Preprocessor/predefined-arch-macros.c
@@ -1849,6 +1849,88 @@
 // CHECK_BDVER4_M64: #define __tune_bdver4__ 1
 // CHECK_BDVER4_M64: #define __x86_64 1
 // CHECK_BDVER4_M64: #define __x86_64__ 1
+// RUN: %clang -march=znver1 -m32 -E -dM %s -o - 2>&1 \
+// RUN: -target i386-unknown-linux \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_ZNVER1_M32
+// CHECK_ZNVER1_M32-NOT: #define __3dNOW_A__ 1
+// CHECK_ZNVER1_M32-NOT: #define __3dNOW__ 1
+// CHECK_ZNVER1_M32: #define __ADX__ 1
+// CHECK_ZNVER1_M32: #define __AES__ 1
+// CHECK_ZNVER1_M32: #define __AVX2__ 1
+// CHECK_ZNVER1_M32: #define __AVX__ 1
+// CHECK_ZNVER1_M32: #define __BMI2__ 1
+// CHECK_ZNVER1_M32: #define __BMI__ 1
+// CHECK_ZNVER1_M32: #define __F16C__ 1
+// CHECK_ZNVER1_M32: #define __FMA__ 1
+// CHECK_ZNVER1_M32: #define __FSGSBASE__ 1
+// CHECK_ZNVER1_M32: #define __LZCNT__ 1
+// CHECK_ZNVER1_M32: #define __MMX__ 1
+// CHECK_ZNVER1_M32: #define __PCLMUL__ 1
+// CHECK_ZNVER1_M32: #define __POPCNT__ 1
+// CHECK_ZNVER1_M32: #define __PRFCHW__ 1
+// CHECK_ZNVER1_M32: #define __RDRND__ 1
+// CHECK_ZNVER1_M32: #define __RDSEED__ 1
+// CHECK_ZNVER1_M32: #define __SHA__ 1
+// CHECK_ZNVER1_M32: #define __SSE2_MATH__ 1
+// CHECK_ZNVER1_M32: #define __SSE2__ 1
+// CHECK_ZNVER1_M32: #define __SSE3__ 1
+// CHECK_ZNVER1_M32: #define __SSE4A__ 1
+// CHECK_ZNVER1_M32: #define __SSE4_1__ 1
+// CHECK_ZNVER1_M32: #define __SSE4_2__ 1
+// CHECK_ZNVER1_M32: #define __SSE_MATH__ 1
+// CHECK_ZNVER1_M32: #define __SSE__ 1
+// CHECK_ZNVER1_M32: #define __SSSE3__ 

r291545 - [X86] Add recent CPU strings to some of the tests that check other cpu names.

[Craig Topper via cfe-commits]

Author: ctopper
Date: Tue Jan 10 00:02:16 2017
New Revision: 291545

URL: http://llvm.org/viewvc/llvm-project?rev=291545=rev
Log:
[X86] Add recent CPU strings to some of the tests that check other cpu names.

Modified:
cfe/trunk/test/Driver/x86-march.c
cfe/trunk/test/Frontend/x86-target-cpu.c

Modified: cfe/trunk/test/Driver/x86-march.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/x86-march.c?rev=291545=291544=291545=diff
==
--- cfe/trunk/test/Driver/x86-march.c (original)
+++ cfe/trunk/test/Driver/x86-march.c Tue Jan 10 00:02:16 2017
@@ -36,6 +36,30 @@
 // RUN:   | FileCheck %s -check-prefix=broadwell
 // broadwell: "-target-cpu" "broadwell"
 //
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=skylake 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=skylake
+// skylake: "-target-cpu" "skylake"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=skylake-avx512 
2>&1 \
+// RUN:   | FileCheck %s -check-prefix=skylake-avx512
+// skylake-avx512: "-target-cpu" "skylake-avx512"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=skx 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=skx
+// skx: "-target-cpu" "skx"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=knl 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=knl
+// knl: "-target-cpu" "knl"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=cannonlake 
2>&1 \
+// RUN:   | FileCheck %s -check-prefix=cannonlake
+// cannonlake: "-target-cpu" "cannonlake"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=lakemont 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=lakemont
+// lakemont: "-target-cpu" "lakemont"
+//
 // RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=bonnell 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=bonnell
 // bonnell: "-target-cpu" "bonnell"

Modified: cfe/trunk/test/Frontend/x86-target-cpu.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/x86-target-cpu.c?rev=291545=291544=291545=diff
==
--- cfe/trunk/test/Frontend/x86-target-cpu.c (original)
+++ cfe/trunk/test/Frontend/x86-target-cpu.c Tue Jan 10 00:02:16 2017
@@ -9,6 +9,11 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu ivybridge 
-verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu haswell -verify 
%s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu broadwell 
-verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu skylake -verify 
%s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu skylake-avx512 
-verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu skx -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu cannonlake 
-verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu knl -verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu bonnell -verify 
%s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu silvermont 
-verify %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -target-cpu k8 -verify %s


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

r291544 - AMD family 17h (znver1) enablement

[Craig Topper via cfe-commits]

Author: ctopper
Date: Tue Jan 10 00:02:12 2017
New Revision: 291544

URL: http://llvm.org/viewvc/llvm-project?rev=291544=rev
Log:
AMD family 17h (znver1) enablement

Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is 
used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.

This is linked to llvm review item https://reviews.llvm.org/D28017

Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.

Reviewers: RKSimon, craig.topper

Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits

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

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Driver/x86-march.c
cfe/trunk/test/Frontend/x86-target-cpu.c
cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=291544=291543=291544=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Tue Jan 10 00:02:12 2017
@@ -2663,6 +2663,12 @@ class X86TargetInfo : public TargetInfo
 CK_BDVER4,
 //@}
 
+/// \name zen
+/// Zen architecture processors.
+//@{
+CK_ZNVER1,
+//@}
+
 /// This specification is deprecated and will be removed in the future.
 /// Users should prefer \see CK_K8.
 // FIXME: Warn on this when the CPU is set to it.
@@ -2744,6 +2750,7 @@ class X86TargetInfo : public TargetInfo
 .Case("bdver2", CK_BDVER2)
 .Case("bdver3", CK_BDVER3)
 .Case("bdver4", CK_BDVER4)
+.Case("znver1", CK_ZNVER1)
 .Case("x86-64", CK_x86_64)
 .Case("geode", CK_Geode)
 .Default(CK_Generic);
@@ -2943,6 +2950,7 @@ public:
 case CK_BDVER2:
 case CK_BDVER3:
 case CK_BDVER4:
+case CK_ZNVER1:
 case CK_x86_64:
   return true;
 }
@@ -3190,6 +3198,33 @@ bool X86TargetInfo::initFeatureMap(
 setFeatureEnabledImpl(Features, "cx16", true);
 setFeatureEnabledImpl(Features, "fxsr", true);
 break;
+  case CK_ZNVER1:
+setFeatureEnabledImpl(Features, "adx", true);
+setFeatureEnabledImpl(Features, "aes", true);
+setFeatureEnabledImpl(Features, "avx2", true);
+setFeatureEnabledImpl(Features, "bmi", true);
+setFeatureEnabledImpl(Features, "bmi2", true);
+setFeatureEnabledImpl(Features, "clflushopt", true);
+setFeatureEnabledImpl(Features, "cx16", true);
+setFeatureEnabledImpl(Features, "f16c", true);
+setFeatureEnabledImpl(Features, "fma", true);
+setFeatureEnabledImpl(Features, "fsgsbase", true);
+setFeatureEnabledImpl(Features, "fxsr", true);
+setFeatureEnabledImpl(Features, "lzcnt", true);
+setFeatureEnabledImpl(Features, "mwaitx", true);
+setFeatureEnabledImpl(Features, "movbe", true);
+setFeatureEnabledImpl(Features, "pclmul", true);
+setFeatureEnabledImpl(Features, "popcnt", true);
+setFeatureEnabledImpl(Features, "prfchw", true);
+setFeatureEnabledImpl(Features, "rdrnd", true);
+setFeatureEnabledImpl(Features, "rdseed", true);
+setFeatureEnabledImpl(Features, "sha", true);
+setFeatureEnabledImpl(Features, "sse4a", true);
+setFeatureEnabledImpl(Features, "xsave", true);
+setFeatureEnabledImpl(Features, "xsavec", true);
+setFeatureEnabledImpl(Features, "xsaveopt", true);
+setFeatureEnabledImpl(Features, "xsaves", true);
+break;
   case CK_BDVER4:
 setFeatureEnabledImpl(Features, "avx2", true);
 setFeatureEnabledImpl(Features, "bmi2", true);
@@ -3741,6 +3776,9 @@ void X86TargetInfo::getTargetDefines(con
   case CK_BDVER4:
 defineCPUMacros(Builder, "bdver4");
 break;
+  case CK_ZNVER1:
+defineCPUMacros(Builder, "znver1");
+break;
   case CK_Geode:
 defineCPUMacros(Builder, "geode");
 break;

Modified: cfe/trunk/test/Driver/x86-march.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/x86-march.c?rev=291544=291543=291544=diff
==
--- cfe/trunk/test/Driver/x86-march.c (original)
+++ cfe/trunk/test/Driver/x86-march.c Tue Jan 10 00:02:12 2017
@@ -103,3 +103,7 @@
 // RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=btver2 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=btver2
 // btver2: "-target-cpu" "btver2"
+//
+// RUN: %clang -target x86_64-unknown-unknown -c -### %s -march=znver1 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=znver1
+// znver1: "-target-cpu" "znver1"

Modified: cfe/trunk/test/Frontend/x86-target-cpu.c
URL: 

[PATCH] D28081: Make GetStyle return Expected instead of FormatStyle

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexshap added inline comments.



Comment at: lib/Format/Format.cpp:424
 
+llvm::Error make_string_error(const llvm::Twine ) {
+  return llvm::make_error(Message,

amaiorano wrote:
> ioeric wrote:
> > Maybe make this `inline`?
> Yes.
regarding this function and some other helper functions in this file: 
1. why aren't they static ? 
(if this stuff is not used outside of this .cpp -  but yeah, i assume i'm 
missing smth)
2. http://llvm.org/docs/CodingStandards.html naming conventions are
"Function names should be verb phrases (as they represent actions), and 
command-like function should be imperative. The name should be camel case, and 
start with a lower case letter (e.g. openFile() or isFoo())"  


https://reviews.llvm.org/D28081



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

[PATCH] D28315: Update tools to use new getStyle API

[Antonio Maiorano via Phabricator via cfe-commits]

amaiorano added a comment.

In https://reviews.llvm.org/D28315#639559, @ioeric wrote:

> I ran `ninja check-all` with https://reviews.llvm.org/D28081 and 
> https://reviews.llvm.org/D28315 (in Linux), and some lit tests failed, namely:
>
>   Clang :: Format/style-on-command-line.cpp


This was the test that is explicitly disabled on Windows. I enabled it locally 
and modified the test to match the modified output and expected non-zero result 
(patch forth-coming once I understand what's up with the failed tests you 
mention below...)

>   Clang Tools :: clang-apply-replacements/basic.cpp
>   Clang Tools :: clang-apply-replacements/conflict.cpp
>   Clang Tools :: clang-apply-replacements/crlf.cpp
>   Clang Tools :: clang-apply-replacements/format.cpp
>   Clang Tools :: clang-rename/ClassReplacements.cpp
> 
>   Error message I am seeing: `Expected must be checked before access or 
> destruction.`
>   
>   Could you double check? Thanks!

These tests pass for me. For example, when I run llvm-lit explicitly on 
clang-apply-replacements/basic.cpp, I get:

  C:\code\llvm-build-msvc\Debug\bin>llvm-lit.py -a -v 
c:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp
  -- Testing: 1 tests, 1 threads --
  PASS: Clang Tools :: clang-apply-replacements/basic.cpp (1 of 1)
  Script:
  --
  mkdir -p 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
  grep -Ev "// *[A-Z-]+:" 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h
 > 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h
  sed 
"s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file1.yaml
 > 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/file1.yaml
  sed 
"s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file2.yaml
 > 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/file2.yaml
  clang-apply-replacements 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
  FileCheck 
-input-file=C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h
 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h
  ls -1 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
 | FileCheck 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp 
--check-prefix=YAML
  grep -Ev "// *[A-Z-]+:" 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h
 > 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h
  clang-apply-replacements -remove-change-desc-files 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
  ls -1 
C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic
 | FileCheck 
C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp 
--check-prefix=NO_YAML
  --
  Exit Code: 0
  
  Command Output (stdout):
  --
  $ "mkdir" "-p" 
"C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic"
  $ "grep" "-Ev" "// *[A-Z-]+:" 
"C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h"
  $ "sed" 
"s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
 
"C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file1.yaml"
  $ "sed" 
"s#\$(path)#C:/code/llvm-build-msvc/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/basic#"
 
"C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/file2.yaml"
  $ "clang-apply-replacements" 
"C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic"
  $ "FileCheck" 
"-input-file=C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic/basic.h"
 
"C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h"
  $ "ls" "-1" 
"C:\code\llvm-build-msvc\tools\clang\tools\extra\test\clang-apply-replacements\Output/Inputs/basic"
  $ "FileCheck" 
"C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements\basic.cpp" 
"--check-prefix=YAML"
  $ "grep" "-Ev" "// *[A-Z-]+:" 
"C:\code\llvm\tools\clang\tools\extra\test\clang-apply-replacements/Inputs/basic/basic.h"
  $ "clang-apply-replacements" "-remove-change-desc-files" 

[PATCH] D28255: [OpenMP] support the 'is_device_ptr' clause with 'target parallel for' pragma

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291540: [OpenMP] Support the 'is_device_ptr' clause with 
'target parallel for' pragma (authored by kli).

Changed prior to commit:
  https://reviews.llvm.org/D28255?vs=82951=83774#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28255

Files:
  cfe/trunk/include/clang/Basic/OpenMPKinds.def
  cfe/trunk/lib/Sema/SemaOpenMP.cpp
  cfe/trunk/test/OpenMP/target_parallel_for_is_device_ptr_ast_print.cpp
  cfe/trunk/test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp

Index: cfe/trunk/include/clang/Basic/OpenMPKinds.def
===
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def
@@ -483,7 +483,6 @@
 OPENMP_TARGET_PARALLEL_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target parallel for'.
-// TODO: add target clauses 'is_device_ptr'
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(if)
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(device)
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(map)
@@ -502,6 +501,7 @@
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(schedule)
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(ordered)
 OPENMP_TARGET_PARALLEL_FOR_CLAUSE(linear)
+OPENMP_TARGET_PARALLEL_FOR_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target update'.
 // TODO More clauses for 'target update' directive.
Index: cfe/trunk/test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp
===
--- cfe/trunk/test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp
+++ cfe/trunk/test/OpenMP/target_parallel_for_is_device_ptr_messages.cpp
@@ -0,0 +1,311 @@
+// RUN: %clang_cc1 -std=c++11 -verify -fopenmp %s
+
+struct ST {
+  int *a;
+};
+typedef int arr[10];
+typedef ST STarr[10];
+typedef struct {
+  int a;
+} S;
+struct SA {
+  const int d = 5;
+  const int da[5] = { 0 };
+  ST e;
+  ST g[10];
+  STarr  = g;
+  int i;
+  int  = i;
+  int *k = 
+  int * = k;
+  int aa[10];
+  arr  = aa;
+  S *ps;
+  void func(int arg) {
+#pragma omp target parallel for is_device_ptr // expected-error {{expected '(' after 'is_device_ptr'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr( // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected expression}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr() // expected-error {{expected expression}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(alloc) // expected-error {{use of undeclared identifier 'alloc'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(arg // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(i) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(j) // expected-error {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(k) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(z) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(aa) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(raa) // OK
+for (int ii=0; ii<10; ii++)
+  ;   
+#pragma omp target parallel for is_device_ptr(e) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(g) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(rg) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(k,i,j) // expected-error2 {{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(d) // expected-error{{expected pointer, array, reference to pointer, or reference to array in 'is_device_ptr clause'}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(da) // OK
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for map(ps) is_device_ptr(ps) // expected-error{{variable already marked as mapped in current construct}} expected-note{{used here}}
+for (int ii=0; ii<10; ii++)
+  ;
+#pragma omp target parallel for is_device_ptr(ps) 

[PATCH] D28402: [OpenMP] support the 'is_device_ptr' clause with 'target parallel for simd' pragma

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291537: [OpenMP] Support the 'is_device_ptr' clause with 
'target parallel for simd'… (authored by kli).

Changed prior to commit:
  https://reviews.llvm.org/D28402?vs=83372=83772#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28402

Files:
  cfe/trunk/include/clang/Basic/OpenMPKinds.def
  cfe/trunk/lib/Sema/SemaOpenMP.cpp
  cfe/trunk/test/OpenMP/target_parallel_for_simd_is_device_ptr_ast_print.cpp
  cfe/trunk/test/OpenMP/target_parallel_for_simd_is_device_ptr_messages.cpp

Index: cfe/trunk/lib/Sema/SemaOpenMP.cpp
===
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp
@@ -7451,7 +7451,8 @@
 CurrDir == OMPD_target_teams ||
 CurrDir == OMPD_target_teams_distribute ||
 CurrDir == OMPD_target_teams_distribute_parallel_for ||
-CurrDir == OMPD_target_teams_distribute_parallel_for_simd) {
+CurrDir == OMPD_target_teams_distribute_parallel_for_simd ||
+CurrDir == OMPD_target_parallel_for_simd) {
   OpenMPClauseKind ConflictKind;
   if (DSAStack->checkMappableExprComponentListsForDecl(
   VD, /*CurrentRegionOnly=*/true,
@@ -7712,7 +7713,8 @@
   CurrDir == OMPD_target_teams ||
   CurrDir == OMPD_target_teams_distribute ||
   CurrDir == OMPD_target_teams_distribute_parallel_for ||
-  CurrDir == OMPD_target_teams_distribute_parallel_for_simd) {
+  CurrDir == OMPD_target_teams_distribute_parallel_for_simd ||
+  CurrDir == OMPD_target_parallel_for_simd) {
 OpenMPClauseKind ConflictKind;
 if (DSAStack->checkMappableExprComponentListsForDecl(
 VD, /*CurrentRegionOnly=*/true,
Index: cfe/trunk/include/clang/Basic/OpenMPKinds.def
===
--- cfe/trunk/include/clang/Basic/OpenMPKinds.def
+++ cfe/trunk/include/clang/Basic/OpenMPKinds.def
@@ -633,7 +633,6 @@
 OPENMP_DISTRIBUTE_SIMD_CLAUSE(reduction)
 
 // Clauses allowed for OpenMP directive 'target parallel for simd'.
-// TODO: add target clauses 'is_device_ptr'
 OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(if)
 OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(device)
 OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(map)
@@ -655,6 +654,7 @@
 OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(safelen)
 OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(simdlen)
 OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(aligned)
+OPENMP_TARGET_PARALLEL_FOR_SIMD_CLAUSE(is_device_ptr)
 
 // Clauses allowed for OpenMP directive 'target simd'.
 OPENMP_TARGET_SIMD_CLAUSE(if)
Index: cfe/trunk/test/OpenMP/target_parallel_for_simd_is_device_ptr_ast_print.cpp
===
--- cfe/trunk/test/OpenMP/target_parallel_for_simd_is_device_ptr_ast_print.cpp
+++ cfe/trunk/test/OpenMP/target_parallel_for_simd_is_device_ptr_ast_print.cpp
@@ -0,0 +1,318 @@
+// RUN: %clang_cc1 -verify -fopenmp -std=c++11 -ast-print %s | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+struct ST {
+  int *a;
+};
+typedef int arr[10];
+typedef ST STarr[10];
+struct SA {
+  const int da[5] = { 0 };
+  ST g[10];
+  STarr  = g;
+  int i;
+  int  = i;
+  int *k = 
+  int * = k;
+  int aa[10];
+  arr  = aa;
+  void func(int arg) {
+#pragma omp target parallel for simd is_device_ptr(k)
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(z)
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(aa) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(raa) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(g) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(rg) // OK
+  for (int i=0; i<100; i++)
+;
+#pragma omp target parallel for simd is_device_ptr(da) // OK
+  for (int i=0; i<100; i++)
+;
+  return;
+ }
+};
+// CHECK: struct SA
+// CHECK-NEXT: const int da[5] = {0};
+// CHECK-NEXT: ST g[10];
+// CHECK-NEXT: STarr  = this->g;
+// CHECK-NEXT: int i;
+// CHECK-NEXT: int  = this->i;
+// CHECK-NEXT: int *k = >j;
+// CHECK-NEXT: int * = this->k;
+// CHECK-NEXT: int aa[10];
+// CHECK-NEXT: arr  = this->aa;
+// CHECK-NEXT: func(
+// CHECK-NEXT: #pragma omp target parallel for simd is_device_ptr(this->k)
+// CHECK-NEXT: for (int i = 0; i < 100; i++)
+// CHECK-NEXT: ;
+// CHECK-NEXT: #pragma omp target parallel for simd is_device_ptr(this->z)
+// CHECK-NEXT: for (int i = 0; i < 100; i++)
+// CHECK-NEXT: ;
+// CHECK-NEXT: #pragma omp target parallel for simd is_device_ptr(this->aa)
+// CHECK-NEXT: for (int i = 0; i < 100; i++)
+// CHECK-NEXT: ;
+// CHECK-NEXT: 

[libcxx] r291536 - threading_support: delete the critical section

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Mon Jan  9 22:18:47 2017
New Revision: 291536

URL: http://llvm.org/viewvc/llvm-project?rev=291536=rev
Log:
threading_support: delete the critical section

Although the CriticalSection itself doesnt need to be destroyed, there
may be debug data associated with it.  Plug a possible small leak.

Modified:
libcxx/trunk/include/__threading_support

Modified: libcxx/trunk/include/__threading_support
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__threading_support?rev=291536=291535=291536=diff
==
--- libcxx/trunk/include/__threading_support (original)
+++ libcxx/trunk/include/__threading_support Mon Jan  9 22:18:47 2017
@@ -385,7 +385,7 @@ int __libcpp_recursive_mutex_unlock(__li
 
 int __libcpp_recursive_mutex_destroy(__libcpp_recursive_mutex_t *__m)
 {
-  static_cast(__m);
+  DeleteCriticalSection(__m);
   return 0;
 }
 


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

[PATCH] D28018: AMD family 17h (znver1) enablement

[Craig Topper via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D28018



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

[PATCH] D24688: Introduce "hosted" module flag.

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

Thanks, I'll investigate function attributes then!


https://reviews.llvm.org/D24688



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

[PATCH] D28495: [analyzer] Support inlining of '[self classMethod]' and '[[self class] classMethod]'

[Devin Coughlin via Phabricator via cfe-commits]

dcoughlin added inline comments.



Comment at: lib/StaticAnalyzer/Core/CallEvent.cpp:972
+  Receiver == getSelfSVal().getAsRegion())
+return RuntimeDefinition(findDefiningRedecl(E->getMethodDecl()));
+

Here is a case where dispatching via the compile-time type of E is not safe:

```
#import 

void clang_analyzer_eval(int);

@interface Parent : NSObject
+ (int)a;
+ (int)b;
@end

@interface Child : Parent
@end

@interface Other : NSObject
+(void)run;
@end

int main(int argc, const char * argv[]) {
  @autoreleasepool {
[Other run];
  }
  return 0;
}

@implementation Other
+(void)run {
  int result = [Child a];

  clang_analyzer_eval(result == 12);
  printf("result is %d\n", result);
}
@end

@implementation Parent
+ (int)a; {
  return [self b];
}
+ (int)b; {
  return 12;
}
@end

@implementation Child
+ (int)b; {
  return 100;
}
@end
```

Running this code will print 'result is 100' but the clang_analyzer_eval() will 
incorrectly yield 'TRUE'.

What do you think about adding a new SVal for ObjC 'Class' values that know 
what interface declaration they come from? Then 'self' in a class method would 
be filled in with something meaningful in `ObjCMethodCall::getReceiverSVal()` 
and we could do proper dynamic dispatch for class methods just like we do for 
instance methods now.



Comment at: lib/StaticAnalyzer/Core/CallEvent.cpp:977
+  // limiting as the test cases in 
Analysis/inlining/InlineObjCClassMethod.m
+  // shows. A better way would be to accosiate the meta type with the 
symbol
+  // using the dynamic type info tracking and use it here.

accosiate-->associate



Comment at: test/Analysis/inlining/InlineObjCClassMethod.m:269
+  unsigned result0 = [self returns10];
+  clang_analyzer_eval(result0 == 10); // expected-warning{{TRUE}}
+}

I think it would be good to duplicate some of these tests in 
`-(void)instanceMethod` since calling `[self class]` is most-commonly used in 
instance methods:
```
  unsigned result2 = [[self class] returns30];
  clang_analyzer_eval(result2 == 30); // expected-warning{{TRUE}}
  unsigned result3 = [[super class] returns30];
  clang_analyzer_eval(result3 == 100); // expected-warning{{UNKNOWN}}
```


https://reviews.llvm.org/D28495



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

[PATCH] D24688: Introduce "hosted" module flag.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

In https://reviews.llvm.org/D24688#638836, @mehdi_amini wrote:

> In https://reviews.llvm.org/D24688#638835, @pcc wrote:
>
> > Didn't we figure out in the end that this could be a function attribute 
> > instead?
>
>
> We did? You wrote in PR30403: "I had a brief look at what it would take to 
> have a per-function TLI, and I'm not convinced that it would be worth the 
> effort."


That was before I figured out (see 
http://lists.llvm.org/pipermail/llvm-dev/2016-September/105035.html) that it 
would not be sound to have mixed freestanding/hosted mean hosted.  Specifically:

> Here's one
>  scenario where we may break: suppose I LTO-link an implementation of memset
>  compiled with -ffreestanding with a program compiled with -fhosted. With
>  the proposed rule, the loop idiom recognizer may transform the body of the
>  memset function into a self-call.

You later wrote that we should try not to default to freestanding: 
http://lists.llvm.org/pipermail/llvm-dev/2016-September/105083.html

And I think I agree with that.

To me that all makes it more reasonable to pursue a per-function approach.

Later on (I don't think it happened on the mailing list or the bug, maybe on 
IRC) we had another look at GlobalOpt (referenced in PR30403 comment 6) and 
figured out that we can in fact find a function context.


https://reviews.llvm.org/D24688



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

r291528 - Don't classify variable template names as type templates.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jan  9 20:15:49 2017
New Revision: 291528

URL: http://llvm.org/viewvc/llvm-project?rev=291528=rev
Log:
Don't classify variable template names as type templates.

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaCXX/cxx1y-variable-templates_top_level.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=291528=291527=291528=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Jan  9 20:15:49 2017
@@ -1044,7 +1044,8 @@ Corrected:
   }
 
   // We can have a type template here if we're classifying a template argument.
-  if (isa(FirstDecl) && !isa(FirstDecl))
+  if (isa(FirstDecl) && !isa(FirstDecl) &&
+  !isa(FirstDecl))
 return NameClassification::TypeTemplate(
 TemplateName(cast(FirstDecl)));
 

Modified: cfe/trunk/test/SemaCXX/cxx1y-variable-templates_top_level.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx1y-variable-templates_top_level.cpp?rev=291528=291527=291528=diff
==
--- cfe/trunk/test/SemaCXX/cxx1y-variable-templates_top_level.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx1y-variable-templates_top_level.cpp Mon Jan  9 
20:15:49 2017
@@ -464,3 +464,8 @@ template  Variadic_t;
 auto variadic2 = Variadic;
 #endif
+
+namespace VexingParse {
+  template  int var; // expected-note {{declared here}}
+  int x(var); // expected-error {{cannot refer to variable template 'var' 
without a template argument list}}
+}


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

[PATCH] D28505: CGDecl: Skip static variable initializers in unreachable code

[Richard Smith via Phabricator via cfe-commits]

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

Yes, this is correct; per [stmt.dcl]/5, the destructor only runs if the object 
was constructed.


Repository:
  rL LLVM

https://reviews.llvm.org/D28505



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

[PATCH] D28348: [analyzer] Taught the analyzer about Glib API to check Memory-leak

[Leslie Zhai via Phabricator via cfe-commits]

xiangzhai updated this revision to Diff 83758.
xiangzhai marked 2 inline comments as done.
xiangzhai added a comment.

make II_g_*malloc*_n sense


Repository:
  rL LLVM

https://reviews.llvm.org/D28348

Files:
  lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  test/Analysis/gmalloc.c

Index: test/Analysis/gmalloc.c
===
--- test/Analysis/gmalloc.c
+++ test/Analysis/gmalloc.c
@@ -0,0 +1,169 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,unix.Malloc -analyzer-store=region -verify %s
+
+#include "Inputs/system-header-simulator.h"
+
+typedef void* gpointer;
+typedef const void* gconstpointer;
+typedef unsigned long gsize;
+typedef unsigned int guint;
+
+gpointer g_malloc(gsize n_bytes);
+gpointer g_malloc0(gsize n_bytes);
+gpointer g_realloc(gpointer mem, gsize n_bytes);
+gpointer g_try_malloc(gsize n_bytes);
+gpointer g_try_malloc0(gsize n_bytes);
+gpointer g_try_realloc(gpointer mem, gsize n_bytes);
+gpointer g_malloc_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_malloc0_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_realloc_n(gpointer mem, gsize n_blocks, gsize n_block_bytes);
+gpointer g_try_malloc_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_try_malloc0_n(gsize n_blocks, gsize n_block_bytes);
+gpointer g_try_realloc_n(gpointer mem, gsize n_blocks, gsize n_block_bytes);
+void g_free(gpointer mem);
+gpointer g_memdup(gconstpointer mem, guint byte_size);
+
+static const gsize n_bytes = 1024;
+
+void f1() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char));
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char));
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char));
+
+  g_free(g1);
+  g_free(g2);
+  g_free(g2); // expected-warning{{Attempt to free released memory}}
+}
+
+void f2() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char));
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char));
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char));
+
+  g_free(g1);
+  g_free(g2);
+  g_free(g3);
+  g3 = g_memdup(g3, n_bytes); // expected-warning{{Use of memory after it is freed}}
+}
+
+void f3() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2); // expected-warning{{Potential leak of memory pointed to by 'g4'}}
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g6'}}
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g5'}}
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g8'}}
+
+  g_free(g1); // expected-warning{{Potential leak of memory pointed to by 'g7'}}
+  g_free(g2);
+  g_free(g3);
+}
+
+void f4() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  gpointer g5 = g_malloc_n(n_bytes, sizeof(char));
+  gpointer g6 = g_malloc0_n(n_bytes, sizeof(char));
+  g5 = g_realloc_n(g5, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g6'}}
+  gpointer g7 = g_try_malloc_n(n_bytes, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g5'}}
+  gpointer g8 = g_try_malloc0_n(n_bytes, sizeof(char));
+  g7 = g_try_realloc_n(g7, n_bytes * 2, sizeof(char)); // expected-warning{{Potential leak of memory pointed to by 'g8'}}
+
+  g_free(g1); // expected-warning{{Potential leak of memory pointed to by 'g7'}}
+  g_free(g2);
+  g_free(g3);
+  g_free(g4);
+}
+
+void f5() {
+  gpointer g1 = g_malloc(n_bytes);
+  gpointer g2 = g_malloc0(n_bytes);
+  g1 = g_realloc(g1, n_bytes * 2);
+  gpointer g3 = g_try_malloc(n_bytes);
+  gpointer g4 = g_try_malloc0(n_bytes);
+  g3 = g_try_realloc(g3, n_bytes * 2);
+  

r291525 - [NFC] Rename RAII ExpressionEvaluationContext variable from Unevaluated to ConstantEvaluated when parsing a constant expression.

[Faisal Vali via cfe-commits]

Author: faisalv
Date: Mon Jan  9 19:29:41 2017
New Revision: 291525

URL: http://llvm.org/viewvc/llvm-project?rev=291525=rev
Log:
[NFC] Rename RAII ExpressionEvaluationContext variable from Unevaluated to 
ConstantEvaluated when parsing a constant expression.

This renaming makes it consistent with the context it actually sets: 
Sema::ConstantEvaluated.

Modified:
cfe/trunk/lib/Parse/ParseExpr.cpp

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=291525=291524=291525=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Mon Jan  9 19:29:41 2017
@@ -198,7 +198,7 @@ ExprResult Parser::ParseConstantExpressi
   //   An expression is potentially evaluated unless it appears where an
   //   integral constant expression is required (see 5.19) [...].
   // C++98 and C++11 have no such rule, but this is only a defect in C++98.
-  EnterExpressionEvaluationContext Unevaluated(Actions,
+  EnterExpressionEvaluationContext ConstantEvaluated(Actions,
Sema::ConstantEvaluated);
 
   ExprResult LHS(ParseCastExpression(false, false, isTypeCast));


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

RE: [PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Robinson, Paul via cfe-commits]

(Re-add cfe-commits; otherwise same)

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Duncan P. N. Exon Smith via cfe-commits
> Sent: Monday, January 09, 2017 4:10 PM
> To: reviews+d28404+public+53e0f4655ef79...@reviews.llvm.org
> Cc: nhaeh...@gmail.com; wei.di...@amd.com; jholewin...@nvidia.com; Richard
> Smith; cfe-commits; Peter Collingbourne
> Subject: Re: [PATCH] D28404: IRGen: Add optnone attribute on function
> during O0
> 
> This seems like a massive rehash of a discussion Peter Collingbourne and I
> had about passing -O0 to the linker for -flto=full.  I had previously
> thought of LTO as "link time optimization", but in practice it's useful
> for (and required for correctness of some) non-optimization IR passes.
> 
> In other words, the basic question seems to be: "Should LTO support non-
> optimization use cases?"  I tend (now) to think it should -- having
> "optimization" in its name is an historical artifact -- because adding
> another way to run IR passes at link-time seems redundant.  Whereas, Paul,
> it seems like you disagree?

I am persuaded that there are non-optimization-based uses for clumps of
bitcode modules linked together.  (We could redefine the TLA if we like;
LTO = Link Time Operation?)

I am equally convinced that we have no good story for propagating a
variety of optimization- and codegen-related options to the top-level
LTO processor.  This is most especially true when different CUs might
reasonably have different options.  -O0 is the example at hand, but 
this problem seems to keep coming up and we keep hacking in ways to get 
the thing we think we need in the moment.

> 
> (Also, this discussion seems higher level than just the patch at hand...
> maybe llvm-dev would be more appropriate?)

I'd be fine with that.
--paulr
> 
> > On 2017-Jan-09, at 16:03, Paul Robinson via Phabricator
>  wrote:
> >
> > probinson added a comment.
> >
> > In https://reviews.llvm.org/D28404#640588, @mehdi_amini wrote:
> >
> >> Actually, as mentioned before, I could be fine with making `O0`
> incompatible with LTO, however security features like CFI (or other sort
> of whole-program analyses/instrumentations) requires LTO.
> >
> >
> > Well, "requires LTO" is overstating the case, AFAICT from the link you
> gave me.  Doesn't depend on //optimization// at all.  It depends on some
> interprocedural analyses given some particular scope/visibility boundary,
> which it is convenient to define as a set of linked bitcode modules, that
> by some happy chance is the same set of linked bitcode modules that LTO
> will operate on.
> >
> > If it's important to support combining a bitcode version of my-
> application with your-bitcode-library for this CFI or whatever, and you
> also want to let me have my-application be unoptimized while your-bitcode-
> library gets optimized, NOW we have a use-case.  (Maybe that's what you
> had in mind earlier, but for some reason I wasn't able to extract that out
> of any prior comments.  No matter.)
> >
> > I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds
> welcome) which would set the default for the pragma to 'off'.  How is that
> different than what you wanted for `-O0`?  It is defined in terms of an
> existing pragma, which is WAY easier to explain and WAY easier to
> implement.  And, it still lets us say that `-c -O0 -flto` is a mistake, if
> that seems like a useful thing to say.
> >
> > Does that seem reasonable?  Fit your understanding of the needs?
> >
> >
> > https://reviews.llvm.org/D28404
> >
> >
> >
> 
> ___
> 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] D28505: CGDecl: Skip static variable initializers in unreachable code

[Matthias Braun via Phabricator via cfe-commits]

MatzeB created this revision.
MatzeB added a reviewer: rsmith.
MatzeB added a subscriber: cfe-commits.
MatzeB set the repository for this revision to rL LLVM.
Herald added a subscriber: mcrosier.

This fixes http://llvm.org/PR31054

I don't know whether that is the correct fix: Are we actually allowed to skip 
the destructor registration if the static variable is unreachable?


Repository:
  rL LLVM

https://reviews.llvm.org/D28505

Files:
  lib/CodeGen/CGDecl.cpp
  test/CodeGenCXX/pr31054.cpp


Index: test/CodeGenCXX/pr31054.cpp
===
--- /dev/null
+++ test/CodeGenCXX/pr31054.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -311,7 +311,7 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.


Index: test/CodeGenCXX/pr31054.cpp
===
--- /dev/null
+++ test/CodeGenCXX/pr31054.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+
+struct A { ~A(); };
+void func() {
+  return;
+  static A k;
+}
+
+// Test that we did not crash, by checking whether function was created.
+// CHECK-LABEL: define void @_Z4funcv() #0 {
+// CHECK: ret void
+// CHECK: }
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -311,7 +311,7 @@
   if (!Init) {
 if (!getLangOpts().CPlusPlus)
   CGM.ErrorUnsupported(D.getInit(), "constant l-value expression");
-else if (Builder.GetInsertBlock()) {
+else if (HaveInsertPoint()) {
   // Since we have a static initializer, this global variable can't
   // be constant.
   GV->setConstant(false);
@@ -352,7 +352,7 @@
   GV->setConstant(CGM.isTypeConstant(D.getType(), true));
   GV->setInitializer(Init);
 
-  if (hasNontrivialDestruction(D.getType())) {
+  if (hasNontrivialDestruction(D.getType()) && HaveInsertPoint()) {
 // We have a constant initializer, but a nontrivial destructor. We still
 // need to perform a guarded "initialization" in order to register the
 // destructor.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

[Hamza Sood via Phabricator via cfe-commits]

hamzasood added a comment.

In https://reviews.llvm.org/D28365#640859, @rnk wrote:

> In https://reviews.llvm.org/D28365#640825, @hamzasood wrote:
>
> > In https://reviews.llvm.org/D28365#640775, @rnk wrote:
> >
> > > Can we revert the linker environment change from this patch? It'll be 
> > > easier to review separately.
> >
> >
> > Sure. But that'll break compiling for x86 on Visual Studio 2017, is that 
> > okay?
>
>
> Yeah, that's fine, you can't break what doesn't work yet. :)


Ha, good point. Does that include the environment stuff in Command too or just 
the linker?


https://reviews.llvm.org/D28365



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640682, @mehdi_amini wrote:

> > I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds 
> > welcome) which would set the default for the pragma to 'off'.  How is that 
> > different than what you wanted for `-O0`?  It is defined in terms of an 
> > existing pragma, which is WAY easier to explain and WAY easier to 
> > implement.  And, it still lets us say that `-c -O0 -flto` is a mistake, if 
> > that seems like a useful thing to say.
>
> Well -O0 being actually "disable optimization", I found "way easier" to 
> handle everything the same way (pragma, command line, etc.). I kind of find 
> it confusing for the user to differentiate `-O0` from `-foptimize=off`. What 
> is supposed to change between the two?


There is a pedantic difference, rooted in the still-true factoid that O0 != 
optnone.
If we redefine LTO as "Link Time Operation" (rather than Optimization; see my 
reply to Duncan)  then `-O0 -flto` is no longer an oxymoron, but using the 
attribute to imply the optimization level is still not good fidelity to what 
the user asked for.


https://reviews.llvm.org/D28404



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

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D28365#640825, @hamzasood wrote:

> In https://reviews.llvm.org/D28365#640775, @rnk wrote:
>
> > Can we revert the linker environment change from this patch? It'll be 
> > easier to review separately.
>
>
> Sure. But that'll break compiling for x86 on Visual Studio 2017, is that okay?


Yeah, that's fine, you can't break what doesn't work yet. :)


https://reviews.llvm.org/D28365



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

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

[Hamza Sood via Phabricator via cfe-commits]

hamzasood added a comment.

In https://reviews.llvm.org/D28365#640775, @rnk wrote:

> Can we revert the linker environment change from this patch? It'll be easier 
> to review separately.


Sure. But that'll break compiling for x86 on Visual Studio 2017, is that okay?


https://reviews.llvm.org/D28365



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

Re: [libcxx] r291466 - [Chrono][Darwin] Make steady_clock use CLOCK_UPTIME_RAW

[Bruno Cardoso Lopes via cfe-commits]

Ops. Fixed in r291517!

On Mon, Jan 9, 2017 at 2:13 PM, Reid Kleckner  wrote:
> This appears to have broken the Chromium build:
> https://build.chromium.org/p/chromium.fyi/builders/ClangToTMac/builds/12620/steps/gclient%20runhooks/logs/stdio
> FAILED: projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o
> /Applications/Xcode8.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -D_DEBUG -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Iprojects/libcxx/lib
> -I/b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/lib -Iinclude
> -I/b/c/b/ClangToTMac/src/third_party/llvm/include
> -I/b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/include
> -DLLVM_FORCE_HEAD_REVISION -fPIC -fvisibility-inlines-hidden -Wall -W
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers  -Wno-long-long -Wcovered-switch-default
> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
> -Werror=date-time -std=c++11 -fcolor-diagnostics -O3  -isysroot
> /Applications/Xcode8.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
> -mmacosx-version-min=10.11-UNDEBUG -std=c++11 -nostdinc++
> -fvisibility-inlines-hidden -Wall -Wextra -W -Wwrite-strings
> -Wno-unused-parameter -Wno-long-long -Werror=return-type
> -Wno-user-defined-literals -Wno-covered-switch-default -Wno-error -fPIC -MMD
> -MT projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o -MF
> projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o.d -o
> projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o -c
> /b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/src/chrono.cpp
> /b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/src/chrono.cpp:102:5:
> error: use of undeclared identifier 'gettimeofday'
> gettimeofday(, 0);
> ^
>
> The interesting flag in there is probably -mmacosx-version-min=10.11. Any
> thoughts on what's going wrong?
>
> On Mon, Jan 9, 2017 at 11:21 AM, Bruno Cardoso Lopes via cfe-commits
>  wrote:
>>
>> Author: bruno
>> Date: Mon Jan  9 13:21:48 2017
>> New Revision: 291466
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=291466=rev
>> Log:
>> [Chrono][Darwin] Make steady_clock use CLOCK_UPTIME_RAW
>>
>> Use CLOCK_UPTIME_RAW in case clock_gettime is available on Darwin.
>>
>> On Apple platforms only CLOCK_UPTIME_RAW or mach_absolute_time are able
>> to time functions in the nanosecond range. Thus, they are the only
>> acceptable implementations of steady_clock.
>>
>> Differential Revision: https://reviews.llvm.org/D27429
>>
>> rdar://problem/29449467
>>
>> Modified:
>> libcxx/trunk/src/chrono.cpp
>>
>> Modified: libcxx/trunk/src/chrono.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/chrono.cpp?rev=291466=291465=291466=diff
>>
>> ==
>> --- libcxx/trunk/src/chrono.cpp (original)
>> +++ libcxx/trunk/src/chrono.cpp Mon Jan  9 13:21:48 2017
>> @@ -12,6 +12,28 @@
>>  #include "system_error"  // __throw_system_error
>>  #include // clock_gettime, CLOCK_MONOTONIC and
>> CLOCK_REALTIME
>>
>> +#if (__APPLE__)
>> +#if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
>> +#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101200
>> +#define _LIBCXX_USE_CLOCK_GETTIME
>> +#endif
>> +#elif defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__)
>> +#if __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ >= 10
>> +#define _LIBCXX_USE_CLOCK_GETTIME
>> +#endif
>> +#elif defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__)
>> +#if __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ >= 10
>> +#define _LIBCXX_USE_CLOCK_GETTIME
>> +#endif
>> +#elif defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__)
>> +#if __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ >= 3
>> +#define _LIBCXX_USE_CLOCK_GETTIME
>> +#endif
>> +#endif // __ENVIRONMENT_.*_VERSION_MIN_REQUIRED__
>> +#else
>> +#define _LIBCXX_USE_CLOCK_GETTIME
>> +#endif // __APPLE__
>> +
>>  #if defined(_LIBCPP_WIN32API)
>>  #define WIN32_LEAN_AND_MEAN
>>  #define VC_EXTRA_LEAN
>> @@ -70,16 +92,16 @@ system_clock::now() _NOEXCEPT
>> static_cast<__int64>(ft.dwLowDateTime)};
>>return time_point(duration_cast(d - nt_to_unix_epoch));
>>  #else
>> -#ifdef CLOCK_REALTIME
>> +#if defined(_LIBCXX_USE_CLOCK_GETTIME) && defined(CLOCK_REALTIME)
>>  struct timespec tp;
>>  if (0 != clock_gettime(CLOCK_REALTIME, ))
>>  __throw_system_error(errno, "clock_gettime(CLOCK_REALTIME)
>> failed");
>>  return time_point(seconds(tp.tv_sec) + microseconds(tp.tv_nsec /
>> 1000));
>> -#else  // !CLOCK_REALTIME
>> +#else
>>  timeval tv;
>>  gettimeofday(, 0);
>>  return time_point(seconds(tv.tv_sec) + microseconds(tv.tv_usec));
>> -#endif  // CLOCK_REALTIME
>> +#endif // 

[libcxx] r291517 - [Chrono][Darwin] Include header for gettimeofday

[Bruno Cardoso Lopes via cfe-commits]

Author: bruno
Date: Mon Jan  9 18:51:02 2017
New Revision: 291517

URL: http://llvm.org/viewvc/llvm-project?rev=291517=rev
Log:
[Chrono][Darwin] Include header for gettimeofday

Followup on r291466 and include the proper header. This fixes:
https://build.chromium.org/p/chromium.fyi/builders/ClangToTMac/builds/12620/steps/gclient%20runhooks/logs/stdio

Modified:
libcxx/trunk/src/chrono.cpp

Modified: libcxx/trunk/src/chrono.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/chrono.cpp?rev=291517=291516=291517=diff
==
--- libcxx/trunk/src/chrono.cpp (original)
+++ libcxx/trunk/src/chrono.cpp Mon Jan  9 18:51:02 2017
@@ -42,7 +42,7 @@
 #include 
 #endif
 #else
-#if !defined(CLOCK_REALTIME)
+#if !defined(CLOCK_REALTIME) || !defined(_LIBCXX_USE_CLOCK_GETTIME)
 #include // for gettimeofday and timeval
 #endif // !defined(CLOCK_REALTIME)
 #endif // defined(_LIBCPP_WIN32API)


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

[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

[Erik Nyquist via Phabricator via cfe-commits]

enyquist added a comment.

Hey bmharper :) I've got a review open that conflicts with this one, just 
having a look to see what I'll need to refactor
(https://reviews.llvm.org/D28462).

In fact, I have a question-- the conflict is specifically in 
WhitespaceManager.cpp. Since I needed to detect PP macros containing changes in 
scope depth (code blocks surrounded by curly braces, macro parameter lists, 
etc), I was having the same problem as you-- AlignTokens was bailing out 
whenever the scope depth changed.

In my case, I just added a new parameter to AlignTokens, 
MaxNestingLevelIncrease, indicating how much the level can increase before we 
stop alignment, making the allowable scope-depth configurable. For example, 
calling AlignTokens with this flag set to 2 will cause alignment to continue up 
until we increase scope by two levels.

Now, my question- from what I can tell of your changes, it looks like my code 
can actually be simpler when this gets merged. The state of AlignTokens will be 
maintained across changing scope depths, and I won't need to modify AlignTokens 
so that it can survive something like "#define foo(x) ((x * 2) + 2)". Is  this 
correct?


https://reviews.llvm.org/D21279



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

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D28365#639253, @hamzasood wrote:

> - Added an option to set the environment in a clang::driver::Command, which 
> makes the environment modifying introduced in the last update a bit more 
> reliable.
>
>   @rnk I looked into using the new MSVC toolchain layout to get a version 
> number without opening an exe, but it doesn't look like it'll be possible. 
> The version number in the toolchain path is the MSVC version number (e.g. 
> Visual Studio 2015 ships with MSVC 14). The version numbers that Clang use 
> are the compiler version numbers (e.g. cl.exe v19 for Visual Studio 2015). As 
> far as I'm aware, there's no mapping between the two.


True, you're right. It's definitely out of scope for this change anyway.

---

Can we revert the linker environment change from this patch? It'll be easier to 
review separately.




Comment at: include/clang/Basic/DiagnosticDriverKinds.td:282
+def err_drv_msvc_not_found : Error<
+  "unable to find a Visual Studio installation. "
+  "Try re-running Clang from a devleoper command prompt">;

It would be nice if we had guidelines on writing clang diagnostics somewhere. I 
think they are supposed to be sentence fragments, and we typically add another 
sentence fragment with a semi-colon. I'd reword it like this for consistency:
  unable to find a Visual Studio installation; try running Clang from a 
developer command prompt



Comment at: include/clang/Basic/DiagnosticDriverKinds.td:283
+  "unable to find a Visual Studio installation. "
+  "Try re-running Clang from a devleoper command prompt">;
 }

typo on developer



Comment at: lib/Driver/Job.cpp:306-308
+  // Convert the environment vector into a vector of char pointers so we can
+  // get it as char**, as required by llvm::sys::ExecuteAndWait.
+  // SmallString::c_str isn't const, hence the const_cast.

Let's not do this, let's store a `std::vector`. We can get the 
right lifetime with `Args.MakeArgString`.


https://reviews.llvm.org/D28365



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

[PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In https://reviews.llvm.org/D20136#640689, @amccarth wrote:

> > and folks have to manually add mincore.lib to their link.
>
> I could load the library dynamically on demand and use GetProcAddress, but I 
> suspect that would further degrade the performance.  I could probably write 
> my own code to find the version in the binary, but I doubt that crosses the 
> reward/work threshold.


`#pragma comment(lib, "mincore")`, maybe?


Repository:
  rL LLVM

https://reviews.llvm.org/D20136



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

r291513 - [coroutines] Sema: Allow co_return all by itself.

[Gor Nishanov via cfe-commits]

Author: gornishanov
Date: Mon Jan  9 18:08:31 2017
New Revision: 291513

URL: http://llvm.org/viewvc/llvm-project?rev=291513=rev
Log:
[coroutines] Sema: Allow co_return all by itself.

Reviewers: rsmith, EricWF

Subscribers: mehdi_amini, llvm-commits, EricWF

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaCoroutine.cpp
cfe/trunk/test/SemaCXX/coroutines.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=291513=291512=291513=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Jan  9 18:08:31 
2017
@@ -8720,10 +8720,6 @@ def err_coroutine_invalid_func_context :
   "|a copy assignment operator|a move assignment operator|the 'main' function"
   "|a constexpr function|a function with a deduced return type"
   "|a varargs function}0">;
-def ext_coroutine_without_co_await_co_yield : ExtWarn<
-  "'co_return' used in a function "
-  "that uses neither 'co_await' nor 'co_yield'">,
-  InGroup>;
 def err_implied_std_coroutine_traits_not_found : Error<
   "you need to include  before defining a coroutine">;
 def err_malformed_std_coroutine_traits : Error<

Modified: cfe/trunk/lib/Sema/SemaCoroutine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCoroutine.cpp?rev=291513=291512=291513=diff
==
--- cfe/trunk/lib/Sema/SemaCoroutine.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCoroutine.cpp Mon Jan  9 18:08:31 2017
@@ -578,17 +578,6 @@ void Sema::CheckCompletedCoroutineBody(F
 isa(First) ? 1 : 2);
   }
 
-  bool AnyCoawaits = false;
-  bool AnyCoyields = false;
-  for (auto *CoroutineStmt : Fn->CoroutineStmts) {
-AnyCoawaits |= isa(CoroutineStmt);
-AnyCoyields |= isa(CoroutineStmt);
-  }
-
-  if (!AnyCoawaits && !AnyCoyields)
-Diag(Fn->CoroutineStmts.front()->getLocStart(),
- diag::ext_coroutine_without_co_await_co_yield);
-
   SourceLocation Loc = FD->getLocation();
 
   // Form a declaration statement for the promise declaration, so that AST

Modified: cfe/trunk/test/SemaCXX/coroutines.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/coroutines.cpp?rev=291513=291512=291513=diff
==
--- cfe/trunk/test/SemaCXX/coroutines.cpp (original)
+++ cfe/trunk/test/SemaCXX/coroutines.cpp Mon Jan  9 18:08:31 2017
@@ -154,12 +154,11 @@ void mixed_await() {
 }
 
 void only_coreturn(void_tag) {
-  co_return; // expected-warning {{'co_return' used in a function that uses 
neither 'co_await' nor 'co_yield'}}
+  co_return; // OK
 }
 
 void mixed_coreturn(void_tag, bool b) {
   if (b)
-// expected-warning@+1 {{'co_return' used in a function that uses neither}}
 co_return; // expected-note {{use of 'co_return'}}
   else
 return; // expected-error {{not allowed in coroutine}}


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

[PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

[Adrian McCarthy via Phabricator via cfe-commits]

amccarth added a comment.

> and folks have to manually add mincore.lib to their link.

I could load the library dynamically on demand and use GetProcAddress, but I 
suspect that would further degrade the performance.  I could probably write my 
own code to find the version in the binary, but I doubt that crosses the 
reward/work threshold.


Repository:
  rL LLVM

https://reviews.llvm.org/D20136



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

Re: [PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Duncan P. N. Exon Smith via cfe-commits]

This seems like a massive rehash of a discussion Peter Collingbourne and I had 
about passing -O0 to the linker for -flto=full.  I had previously thought of 
LTO as "link time optimization", but in practice it's useful for (and required 
for correctness of some) non-optimization IR passes.

In other words, the basic question seems to be: "Should LTO support 
non-optimization use cases?"  I tend (now) to think it should -- having 
"optimization" in its name is an historical artifact -- because adding another 
way to run IR passes at link-time seems redundant.  Whereas, Paul, it seems 
like you disagree?

(Also, this discussion seems higher level than just the patch at hand... maybe 
llvm-dev would be more appropriate?)

> On 2017-Jan-09, at 16:03, Paul Robinson via Phabricator 
>  wrote:
> 
> probinson added a comment.
> 
> In https://reviews.llvm.org/D28404#640588, @mehdi_amini wrote:
> 
>> Actually, as mentioned before, I could be fine with making `O0` incompatible 
>> with LTO, however security features like CFI (or other sort of whole-program 
>> analyses/instrumentations) requires LTO.
> 
> 
> Well, "requires LTO" is overstating the case, AFAICT from the link you gave 
> me.  Doesn't depend on //optimization// at all.  It depends on some 
> interprocedural analyses given some particular scope/visibility boundary, 
> which it is convenient to define as a set of linked bitcode modules, that by 
> some happy chance is the same set of linked bitcode modules that LTO will 
> operate on.
> 
> If it's important to support combining a bitcode version of my-application 
> with your-bitcode-library for this CFI or whatever, and you also want to let 
> me have my-application be unoptimized while your-bitcode-library gets 
> optimized, NOW we have a use-case.  (Maybe that's what you had in mind 
> earlier, but for some reason I wasn't able to extract that out of any prior 
> comments.  No matter.)
> 
> I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds 
> welcome) which would set the default for the pragma to 'off'.  How is that 
> different than what you wanted for `-O0`?  It is defined in terms of an 
> existing pragma, which is WAY easier to explain and WAY easier to implement.  
> And, it still lets us say that `-c -O0 -flto` is a mistake, if that seems 
> like a useful thing to say.
> 
> Does that seem reasonable?  Fit your understanding of the needs?
> 
> 
> https://reviews.llvm.org/D28404
> 
> 
> 

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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.



> I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds 
> welcome) which would set the default for the pragma to 'off'.  How is that 
> different than what you wanted for `-O0`?  It is defined in terms of an 
> existing pragma, which is WAY easier to explain and WAY easier to implement.  
> And, it still lets us say that `-c -O0 -flto` is a mistake, if that seems 
> like a useful thing to say.

Well -O0 being actually "disable optimization", I found "way easier" to handle 
everything the same way (pragma, command line, etc.). I kind of find it 
confusing for the user to differentiate `-O0` from `-foptimize=off`. What is 
supposed to change between the two?


https://reviews.llvm.org/D28404



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640588, @mehdi_amini wrote:

> Actually, as mentioned before, I could be fine with making `O0` incompatible 
> with LTO, however security features like CFI (or other sort of whole-program 
> analyses/instrumentations) requires LTO.


Well, "requires LTO" is overstating the case, AFAICT from the link you gave me. 
 Doesn't depend on //optimization// at all.  It depends on some interprocedural 
analyses given some particular scope/visibility boundary, which it is 
convenient to define as a set of linked bitcode modules, that by some happy 
chance is the same set of linked bitcode modules that LTO will operate on.

If it's important to support combining a bitcode version of my-application with 
your-bitcode-library for this CFI or whatever, and you also want to let me have 
my-application be unoptimized while your-bitcode-library gets optimized, NOW we 
have a use-case.  (Maybe that's what you had in mind earlier, but for some 
reason I wasn't able to extract that out of any prior comments.  No matter.)

I'm now thinking along the lines of a `-foptimize-off` flag (bikesheds welcome) 
which would set the default for the pragma to 'off'.  How is that different 
than what you wanted for `-O0`?  It is defined in terms of an existing pragma, 
which is WAY easier to explain and WAY easier to implement.  And, it still lets 
us say that `-c -O0 -flto` is a mistake, if that seems like a useful thing to 
say.

Does that seem reasonable?  Fit your understanding of the needs?


https://reviews.llvm.org/D28404



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

[libcxx] r291508 - [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

[Michal Gorny via cfe-commits]

Author: mgorny
Date: Mon Jan  9 17:41:38 2017
New Revision: 291508

URL: http://llvm.org/viewvc/llvm-project?rev=291508=rev
Log:
[cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.


Modified:
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=291508=291507=291508=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Mon Jan  9 17:41:38 
2017
@@ -38,7 +38,18 @@ macro(find_llvm_parts)
 set(LLVM_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include")
 set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
 set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source 
tree")
-set(LLVM_CMAKE_PATH 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+
+# --cmakedir is supported since llvm r291218 (4.0 release)
+execute_process(
+  COMMAND ${LLVM_CONFIG_PATH} --cmakedir
+  RESULT_VARIABLE HAD_ERROR
+  OUTPUT_VARIABLE CONFIG_OUTPUT)
+if(NOT HAD_ERROR)
+  string(STRIP "${CONFIG_OUTPUT}" LLVM_CMAKE_PATH)
+else()
+  set(LLVM_CMAKE_PATH
+  "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+endif()
   else()
 set(LLVM_FOUND OFF)
 message(WARNING "UNSUPPORTED LIBCXX CONFIGURATION DETECTED: "


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

[libcxxabi] r291506 - [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

[Michal Gorny via cfe-commits]

Author: mgorny
Date: Mon Jan  9 17:31:05 2017
New Revision: 291506

URL: http://llvm.org/viewvc/llvm-project?rev=291506=rev
Log:
[cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.

Modified:
libcxxabi/trunk/CMakeLists.txt

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=291506=291505=291506=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Mon Jan  9 17:31:05 2017
@@ -49,8 +49,19 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
 set(LLVM_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include")
 set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
 set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source 
tree")
-set(LLVM_CMAKE_PATH 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
 set(LLVM_LIT_PATH "${LLVM_PATH}/utils/lit/lit.py")
+
+# --cmakedir is supported since llvm r291218 (4.0 release)
+execute_process(
+  COMMAND ${LLVM_CONFIG_PATH} --cmakedir
+  RESULT_VARIABLE HAD_ERROR
+  OUTPUT_VARIABLE CONFIG_OUTPUT)
+if(NOT HAD_ERROR)
+  string(STRIP "${CONFIG_OUTPUT}" LLVM_CMAKE_PATH)
+else()
+  set(LLVM_CMAKE_PATH
+  "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+endif()
   else()
 message(FATAL_ERROR "llvm-config not found and LLVM_MAIN_SRC_DIR not 
defined. "
 "Reconfigure with 
-DLLVM_CONFIG_PATH=path/to/llvm-config "


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

[libunwind] r291505 - [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

[Michal Gorny via cfe-commits]

Author: mgorny
Date: Mon Jan  9 17:27:04 2017
New Revision: 291505

URL: http://llvm.org/viewvc/llvm-project?rev=291505=rev
Log:
[cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.

Modified:
libunwind/trunk/CMakeLists.txt

Modified: libunwind/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/CMakeLists.txt?rev=291505=291504=291505=diff
==
--- libunwind/trunk/CMakeLists.txt (original)
+++ libunwind/trunk/CMakeLists.txt Mon Jan  9 17:27:04 2017
@@ -43,8 +43,19 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
 set(LLVM_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include")
 set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
 set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source 
tree")
-set(LLVM_CMAKE_PATH 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
 set(LLVM_LIT_PATH "${LLVM_PATH}/utils/lit/lit.py")
+
+# --cmakedir is supported since llvm r291218 (4.0 release)
+execute_process(
+  COMMAND ${LLVM_CONFIG_PATH} --cmakedir
+  RESULT_VARIABLE HAD_ERROR
+  OUTPUT_VARIABLE CONFIG_OUTPUT)
+if(NOT HAD_ERROR)
+  string(STRIP "${CONFIG_OUTPUT}" LLVM_CMAKE_PATH)
+else()
+  set(LLVM_CMAKE_PATH
+  "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+endif()
   else()
 message(FATAL_ERROR "llvm-config not found and LLVM_MAIN_SRC_DIR not 
defined. "
 "Reconfigure with -DLLVM_CONFIG=path/to/llvm-config "


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

[PATCH] D20136: Get default -fms-compatibility-version from cl.exe's version

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

One consequence from this that I just realized is that linking a binary 
depending on clang stuff with (morally):

  c++ -o foo foo.o $($LLVMBUILD/bin/llvm-config --ldflags) -lclangFrontend 
-lclangDriver -lclangParse -lclangSema -lclangSerialization -lclangAnalysis 
-lclangAST -lclangEdit -lclangLex -lclangBasic $($LLVMBUILD/bin/llvm-config 
--libs) $($LLVMBUILD/bin/llvm-config --system-libs)

now fails with

  clangDriver.lib(MSVCToolChain.cpp.obj) : error LNK2019: unresolved external 
symbol GetFileVersionInfoSizeW referenced in
   function "private: class clang::VersionTuple __cdecl 
clang::driver::toolchains::MSVCToolChain::getMSVCVersionFromExe(vo
  id)const " 
(?getMSVCVersionFromExe@MSVCToolChain@toolchains@driver@clang@@AEBA?AVVersionTuple@4@XZ)
  clangDriver.lib(MSVCToolChain.cpp.obj) : error LNK2019: unresolved external 
symbol GetFileVersionInfoW referenced in fun
  ction "private: class clang::VersionTuple __cdecl 
clang::driver::toolchains::MSVCToolChain::getMSVCVersionFromExe(void)c
  onst " 
(?getMSVCVersionFromExe@MSVCToolChain@toolchains@driver@clang@@AEBA?AVVersionTuple@4@XZ)
  clangDriver.lib(MSVCToolChain.cpp.obj) : error LNK2019: unresolved external 
symbol VerQueryValueW referenced in function
   "private: class clang::VersionTuple __cdecl 
clang::driver::toolchains::MSVCToolChain::getMSVCVersionFromExe(void)const
  " 
(?getMSVCVersionFromExe@MSVCToolChain@toolchains@driver@clang@@AEBA?AVVersionTuple@4@XZ)
  pptest.exe : fatal error LNK1120: 3 unresolved externals

and folks have to manually add mincore.lib to their link. `llvm-config 
--system-libs` takes care of things like this for LLVM, but we don't have a 
`clang-config` as far as I know (does anybody know why not?). So folks now have 
to manually pass more libraries than just the clang libraries. Not a big deal, 
but I figured I'd point it out.


Repository:
  rL LLVM

https://reviews.llvm.org/D20136



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

Actually, as mentioned before, I could be fine with making `O0` incompatible 
with LTO, however security features like CFI (or other sort of whole-program 
analyses/instrumentations) requires LTO.


https://reviews.llvm.org/D28404



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

[PATCH] D28495: [analyzer] Support inlining of '[self classMethod]' and '[[self class] classMethod]'

[Anna Zaks via Phabricator via cfe-commits]

zaks.anna created this revision.
zaks.anna added reviewers: dergachev.a, dcoughlin.
zaks.anna added a subscriber: cfe-commits.

https://reviews.llvm.org/D28495

Files:
  lib/StaticAnalyzer/Core/CallEvent.cpp
  test/Analysis/inlining/InlineObjCClassMethod.m

Index: test/Analysis/inlining/InlineObjCClassMethod.m
===
--- test/Analysis/inlining/InlineObjCClassMethod.m
+++ test/Analysis/inlining/InlineObjCClassMethod.m
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -analyze -analyzer-checker=core,debug.ExprInspection -analyzer-config ipa=dynamic-bifurcate -verify %s
 
 void clang_analyzer_checkInlined(int);
+void clang_analyzer_eval(int);
 
 // Test inlining of ObjC class methods.
 
@@ -194,7 +195,9 @@
 @implementation SelfUsedInParent
 + (int)getNum {return 5;}
 + (int)foo {
-  return [self getNum];
+  int r = [self getNum];
+  clang_analyzer_eval(r == 5); // expected-warning{{TRUE}}
+  return r;
 }
 @end
 @interface SelfUsedInParentChild : SelfUsedInParent
@@ -229,8 +232,41 @@
 + (void)forwardDeclaredVariadicMethod:(int)x, ... {
   clang_analyzer_checkInlined(0); // no-warning
 }
+@end
+
+@interface SelfClassTestParent : NSObject
+-(unsigned)returns10;
++(unsigned)returns20;
++(unsigned)returns30;
+@end
 
+@implementation SelfClassTestParent
+-(unsigned)returns10 { return 100; }
++(unsigned)returns20 { return 100; }
++(unsigned)returns30 { return 100; }
 @end
 
+@interface SelfClassTest : SelfClassTestParent
+-(unsigned)returns10;
++(unsigned)returns20;
++(unsigned)returns30;
+@end
 
+@implementation SelfClassTest
+-(unsigned)returns10 { return 10; }
++(unsigned)returns20 { return 20; }
++(unsigned)returns30 { return 30; }
++(void)classMethod {
+  unsigned result1 = [self returns20];
+  clang_analyzer_eval(result1 == 20); // expected-warning{{TRUE}}
+  unsigned result2 = [[self class] returns30];
+  clang_analyzer_eval(result2 == 30); // expected-warning{{TRUE}}
+  unsigned result3 = [[super class] returns30];
+  clang_analyzer_eval(result3 == 100); // expected-warning{{UNKNOWN}}
+}
+-(void)instanceMethod {
+  unsigned result0 = [self returns10];
+  clang_analyzer_eval(result0 == 10); // expected-warning{{TRUE}}
+}
+@end
 
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -896,6 +896,38 @@
   llvm_unreachable("The while loop should always terminate.");
 }
 
+static const ObjCMethodDecl *findDefiningRedecl(const ObjCMethodDecl *MD) {
+  if (!MD)
+return MD;
+
+  // Find the redeclaration that defines the method.
+  if (!MD->hasBody()) {
+for (auto I : MD->redecls())
+  if (I->hasBody())
+MD = cast(I);
+  }
+  return MD;
+}
+
+static bool isCallToSelfClass(const ObjCMessageExpr *ME) {
+  const Expr* InstRec = ME->getInstanceReceiver();
+  if (!InstRec)
+return false;
+  const auto *InstRecIg = dyn_cast(InstRec->IgnoreParenImpCasts());
+
+  // Check that receiver is called 'self'.
+  if (!InstRecIg || !InstRecIg->getFoundDecl() ||
+  !InstRecIg->getFoundDecl()->getName().equals("self"))
+return false;
+
+  // Check that the method name is 'class'.
+  if (ME->getSelector().getNumArgs() != 0 ||
+  !ME->getSelector().getNameForSlot(0).equals("class"))
+return false;
+
+  return true;
+}
+
 RuntimeDefinition ObjCMethodCall::getRuntimeDefinition() const {
   const ObjCMessageExpr *E = getOriginExpr();
   assert(E);
@@ -910,6 +942,7 @@
 const MemRegion *Receiver = nullptr;
 
 if (!SupersType.isNull()) {
+  // The receiver is guaranteed to be 'super' in this case.
   // Super always means the type of immediate predecessor to the method
   // where the call occurs.
   ReceiverT = cast(SupersType);
@@ -921,15 +954,35 @@
   DynamicTypeInfo DTI = getDynamicTypeInfo(getState(), Receiver);
   QualType DynType = DTI.getType();
   CanBeSubClassed = DTI.canBeASubClass();
-  ReceiverT = dyn_cast(DynType);
+  ReceiverT = dyn_cast(DynType.getCanonicalType());
 
   if (ReceiverT && CanBeSubClassed)
 if (ObjCInterfaceDecl *IDecl = ReceiverT->getInterfaceDecl())
   if (!canBeOverridenInSubclass(IDecl, Sel))
 CanBeSubClassed = false;
 }
 
-// Lookup the method implementation.
+// Handle special cases of '[self classMethod]' and
+// '[[self class] classMethod]', which are treated by the compiler as
+// instance (not class) messages. We will statically dispatch to those.
+if (auto *PT = dyn_cast_or_null(ReceiverT)) {
+  // For [self classMethod], return the compiler visible declaration.
+  if (PT->getObjectType()->isObjCClass() &&
+  Receiver == getSelfSVal().getAsRegion())
+return RuntimeDefinition(findDefiningRedecl(E->getMethodDecl()));
+
+  // Similarly, handle [[self class] classMethod].
+  // TODO: We are currently doing a syntactic match for this pattern with 

[libcxx] r291497 - Adorn __call_once_proxy with `inline` and `_LIBCPP_INLINE_VISIBILITY`

[Justin Bogner via cfe-commits]

Author: bogner
Date: Mon Jan  9 17:07:12 2017
New Revision: 291497

URL: http://llvm.org/viewvc/llvm-project?rev=291497=rev
Log:
Adorn __call_once_proxy with `inline` and `_LIBCPP_INLINE_VISIBILITY`

As per discussion with mclow and EricWF on irc, this is small and
simple enough to deserve being inlined.

Modified:
libcxx/trunk/include/mutex

Modified: libcxx/trunk/include/mutex
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/mutex?rev=291497=291496=291497=diff
==
--- libcxx/trunk/include/mutex (original)
+++ libcxx/trunk/include/mutex Mon Jan  9 17:07:12 2017
@@ -559,6 +559,7 @@ public:
 #endif
 
 template 
+inline _LIBCPP_INLINE_VISIBILITY
 void
 __call_once_proxy(void* __vp)
 {


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

r291495 - [cmake] Obtain LLVM_CMAKE_PATH from llvm-config

[Michal Gorny via cfe-commits]

Author: mgorny
Date: Mon Jan  9 17:06:39 2017
New Revision: 291495

URL: http://llvm.org/viewvc/llvm-project?rev=291495=rev
Log:
[cmake] Obtain LLVM_CMAKE_PATH from llvm-config

Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.

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

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=291495=291494=291495=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Mon Jan  9 17:06:39 2017
@@ -16,7 +16,8 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   "--libdir"
   "--includedir"
   "--prefix"
-  "--src-root")
+  "--src-root"
+  "--cmakedir")
 execute_process(
   COMMAND ${CONFIG_COMMAND}
   RESULT_VARIABLE HAD_ERROR
@@ -41,6 +42,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
   list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
   list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
+  list(GET CONFIG_OUTPUT 6 LLVM_CMAKE_PATH)
 
   if(NOT MSVC_IDE)
 set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
@@ -58,7 +60,6 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")


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

[PATCH] D26900: [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

As discussed on IRC, I will commit the unconditional versions for projects that 
require the same version of LLVM (clang, lldb, lld) and the version with 
fallback for others (runtimes).


https://reviews.llvm.org/D26900



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

[PATCH] D26900: [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

[Michał Górny via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291495: [cmake] Obtain LLVM_CMAKE_PATH from llvm-config 
(authored by mgorny).

Changed prior to commit:
  https://reviews.llvm.org/D26900?vs=83527=83718#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D26900

Files:
  cfe/trunk/CMakeLists.txt


Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -16,7 +16,8 @@
   "--libdir"
   "--includedir"
   "--prefix"
-  "--src-root")
+  "--src-root"
+  "--cmakedir")
 execute_process(
   COMMAND ${CONFIG_COMMAND}
   RESULT_VARIABLE HAD_ERROR
@@ -41,6 +42,7 @@
   list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
   list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
   list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
+  list(GET CONFIG_OUTPUT 6 LLVM_CMAKE_PATH)
 
   if(NOT MSVC_IDE)
 set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
@@ -58,7 +60,6 @@
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")


Index: cfe/trunk/CMakeLists.txt
===
--- cfe/trunk/CMakeLists.txt
+++ cfe/trunk/CMakeLists.txt
@@ -16,7 +16,8 @@
   "--libdir"
   "--includedir"
   "--prefix"
-  "--src-root")
+  "--src-root"
+  "--cmakedir")
 execute_process(
   COMMAND ${CONFIG_COMMAND}
   RESULT_VARIABLE HAD_ERROR
@@ -41,6 +42,7 @@
   list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
   list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
   list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
+  list(GET CONFIG_OUTPUT 6 LLVM_CMAKE_PATH)
 
   if(NOT MSVC_IDE)
 set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
@@ -58,7 +60,6 @@
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
 list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640362, @probinson wrote:

> In https://reviews.llvm.org/D28404#640314, @mehdi_amini wrote:
>
> > I don't follow: IMO if I generate a module with optnone and pipe it to `opt 
> > -O3` I expect no function IR to be touched. If it is not the case it is a 
> > bug.
>
>
> Your opinion and expectation are not supported by the IR spec.  Optnone skips 
> "most" optimization passes.  It is not practical (or was not, at the time) to 
> make the -O3 pipeline behave exactly the same as the -O0 pipeline, and also 
> not actually necessary to support the purpose for which 'optnone' was 
> invented.
>
> If you have a goal of making 'optnone' functions use the actual -O0 pipeline, 
> while non-optnone functions use the optimizing pipeline, more power to you 
> and you will need to take up that particular design challenge with Chandler 
> first.


Oh, maybe you are thinking of eliminating the -O0 pipeline?  Because if -O0 
implies optnone then it's kinda-sorta the same thing as the optimization 
pipeline operating on nothing but optnone functions?  I'd think that would make 
-O0 compilations slow down, which would not be a feature.


https://reviews.llvm.org/D28404



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

r291493 - Add a test for diagnose_if.

[George Burgess IV via cfe-commits]

Author: gbiv
Date: Mon Jan  9 16:43:16 2017
New Revision: 291493

URL: http://llvm.org/viewvc/llvm-project?rev=291493=rev
Log:
Add a test for diagnose_if.

Forgot to add this file as a part of r291418.

Added:
cfe/trunk/test/SemaCXX/diagnose_if-ext.cpp

Added: cfe/trunk/test/SemaCXX/diagnose_if-ext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/diagnose_if-ext.cpp?rev=291493=auto
==
--- cfe/trunk/test/SemaCXX/diagnose_if-ext.cpp (added)
+++ cfe/trunk/test/SemaCXX/diagnose_if-ext.cpp Mon Jan  9 16:43:16 2017
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -Wpedantic -fsyntax-only %s -verify
+
+void foo() __attribute__((diagnose_if(1, "", "error"))); // 
expected-warning{{'diagnose_if' is a clang extension}}
+void foo(int a) __attribute__((diagnose_if(a, "", "error"))); // 
expected-warning{{'diagnose_if' is a clang extension}}
+// FIXME: When diagnose_if gets a CXX11 spelling, this should be enabled.
+#if 0
+[[clang::diagnose_if(a, "", "error")]] void foo(double a);
+#endif


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

Re: Patch for Bug 22877

[Akira Hatanaka via cfe-commits]

Perhaps you can check more explicitly that the destructor is called inside the 
loop?

// CHECK: [[regex for LOOP_BODY]]:
// CHECK: call void @_ZN3fooC1Ev
// CHECK-NOT: br
// CHECK: call void @_ZN3barC1E3foo
// CHECK-NOT: br
// CHECK: call void @_ZN3fooD1Ev
// CHECK: br [[LOOP_BODY]]

> On Jan 8, 2017, at 11:34 PM, Arthur Eubanks via cfe-commits 
>  wrote:
> 
> Hi,
> 
> This is my first commit, please feel free to critique any of the code/new 
> test since I'm not quite sure if this is in the correct format.
> The patch is for the bug https://llvm.org/bugs/show_bug.cgi?id=22877 
>  regarding cleaning up default 
> arguments in constructors while initializing an array.
> It doesn't break any old tests.
> 
> Thanks,
> Arthur Eubanks
> 
> 
> ___
> 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] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

Basically, I don't see why having clang always emit a real .o at -O0 would be a 
problem.
I haven't gotten through the other-CFI documentation yet though.


https://reviews.llvm.org/D28404



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

[libcxx] r291492 - Swap two lines in __mutex_base. On systems with high clock rates, we could mistakenly return no_timeout when a mutex had timed out if we got a tick between these two lines. Thanks t

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Jan  9 16:32:11 2017
New Revision: 291492

URL: http://llvm.org/viewvc/llvm-project?rev=291492=rev
Log:
Swap two lines in __mutex_base. On systems with high clock rates, we could 
mistakenly return no_timeout when a mutex had timed out if we got a tick 
between these two lines.  Thanks to Brian Cain for the bug report.

Modified:
libcxx/trunk/include/__mutex_base

Modified: libcxx/trunk/include/__mutex_base
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__mutex_base?rev=291492=291491=291492=diff
==
--- libcxx/trunk/include/__mutex_base (original)
+++ libcxx/trunk/include/__mutex_base Mon Jan  9 16:32:11 2017
@@ -410,8 +410,8 @@ condition_variable::wait_for(unique_lock
 typedef time_point __sys_tpf;
 typedef time_point __sys_tpi;
 __sys_tpf _Max = __sys_tpi::max();
-system_clock::time_point __s_now = system_clock::now();
 steady_clock::time_point __c_now = steady_clock::now();
+system_clock::time_point __s_now = system_clock::now();
 if (_Max - __d > __s_now)
 __do_timed_wait(__lk, __s_now + __ceil(__d));
 else


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

[PATCH] D27872: [APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, IEEEdouble)

[Tim Shen via Phabricator via cfe-commits]

timshen marked an inline comment as done.
timshen added inline comments.



Comment at: llvm/include/llvm/ADT/APFloat.h:791
   void makeNaN(bool SNaN, bool Neg, const APInt *fill) {
-getIEEE().makeNaN(SNaN, Neg, fill);
+if (usesLayout(getSemantics()))
+  return U.IEEE.makeNaN(SNaN, Neg, fill);

hfinkel wrote:
> I realize that some of this existed before, but is there any way to refactor 
> this so that we don't have so much boiler plate? Even using a utility macro 
> is probably better than this.
I was thinking about using a macro. I can do that after this patch.

The right way though, is to use virtual functions to do the dynamic dispatch. 
Ideally, we will have APFloatInterface as a pure virtual base, IEEEFloat and 
DoubleAPFloat as its two derives, and APFloat managing the union buffer to hold 
the objects. This approach is not easy to transit to, since then the object 
needs to keep a vtable pointer around, which costs a word. In order to 
compensate that overhead, we need somehow stash the "semantics" data member 
into the vtable.


https://reviews.llvm.org/D27872



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640314, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#640284, @probinson wrote:
>
> > In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote:
> >
> > > In https://reviews.llvm.org/D28404#640170, @probinson wrote:
> > >
> > > > In my experience, modifying source is by far simpler than hacking a 
> > > > build system to make a special case for compiler options for one module 
> > > > in an application.  (If you have a way to build Clang with everything 
> > > > done LTO except one module built with -O0, on Linux with ninja, I would 
> > > > be very curious to hear how you do that.)
> > >
> > >
> > > Static library, separated projects, etc.
> > >  We have tons of users...
> >
> >
> > Still waiting.
>
>
> Waiting for what?
>  We have use-cases, I gave you a few (vendor static libraries are one). 
> Again, if you think it is wrong to support O0 and LTO, then please elaborate.


Your original use-case described debugging a module in an application.  You 
claimed it was simpler to change the build options for a module than change the 
source, which I am still waiting to hear how/why that is simpler.

Your subsequent use cases are about entire sub-projects, which is entirely 
different and orthogonal to where you started.  Please elaborate on the 
original use case.


https://reviews.llvm.org/D28404



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

r291491 - Fixing test to work when the compiler defaults to a different C++ standard version.

[Douglas Yung via cfe-commits]

Author: dyung
Date: Mon Jan  9 16:20:10 2017
New Revision: 291491

URL: http://llvm.org/viewvc/llvm-project?rev=291491=rev
Log:
Fixing test to work when the compiler defaults to a different C++ standard 
version.

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


Modified:
cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp

Modified: cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp?rev=291491=291490=291491=diff
==
--- cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp 
(original)
+++ cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp Mon Jan 
 9 16:20:10 2017
@@ -1,8 +1,13 @@
 // RUN: %clang_cc1 -verify -fopenmp %s
+// RUN: %clang_cc1 -verify -fopenmp -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -std=c++11 %s
 
 void foo() {
 }
 
+#if __cplusplus >= 201103L
+// expected-note@+2 4 {{declared here}}
+#endif
 bool foobool(int argc) {
   return argc;
 }
@@ -43,6 +48,9 @@ T tmain(T argc, S **argv) { //expected-n
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST]; // expected-error 2 {{expected 2 
for loops after '#pragma omp target teams distribute', but found only 1}}
 
+#if __cplusplus >= 201103L
+// expected-note@+5 2 {{non-constexpr function 'foobool' cannot be used in a 
constant expression}}
+#endif
 // expected-error@+3 2 {{directive '#pragma omp target teams distribute' 
cannot contain more than one 'collapse' clause}}
 // expected-error@+2 2 {{argument to 'collapse' clause must be a strictly 
positive integer value}}
 // expected-error@+1 2 {{expression is not an integral constant expression}}
@@ -54,7 +62,11 @@ T tmain(T argc, S **argv) { //expected-n
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST];
 
-// expected-error@+1 2 {{expression is not an integral constant expression}}
+#if __cplusplus <= 199711L
+  // expected-error@+4 2 {{expression is not an integral constant expression}}
+#else
+  // expected-error@+2 2 {{integral constant expression must have integral or 
unscoped enumeration type, not 'char *'}}
+#endif
 #pragma omp target teams distribute collapse (argv[1]=2) // expected-error 
{{expected ')'}} expected-note {{to match this '('}}
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST];
@@ -93,10 +105,17 @@ int main(int argc, char **argv) {
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4]; // expected-error {{expected 4 for 
loops after '#pragma omp target teams distribute', but found only 1}}
 
-#pragma omp target teams distribute collapse (foobool(1) > 0 ? 1 : 2) // 
expected-error {{expression is not an integral constant expression}}
+// expected-error@+4 {{expression is not an integral constant expression}}
+#if __cplusplus >= 201103L
+// expected-note@+2 {{non-constexpr function 'foobool' cannot be used in a 
constant expression}}
+#endif
+#pragma omp target teams distribute collapse (foobool(1) > 0 ? 1 : 2)
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4];
 
+#if __cplusplus >= 201103L
+  // expected-note@+5{{non-constexpr function 'foobool' cannot be used in a 
constant expression}}
+#endif
 // expected-error@+3 {{expression is not an integral constant expression}}
 // expected-error@+2 2 {{directive '#pragma omp target teams distribute' 
cannot contain more than one 'collapse' clause}}
 // expected-error@+1 2 {{argument to 'collapse' clause must be a strictly 
positive integer value}}
@@ -108,7 +127,11 @@ int main(int argc, char **argv) {
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4];
 
-// expected-error@+1 {{expression is not an integral constant expression}}
+#if __cplusplus <= 199711L
+  // expected-error@+4 {{expression is not an integral constant expression}}
+#else
+  // expected-error@+2 {{integral constant expression must have integral or 
unscoped enumeration type, not 'char *'}}
+#endif
 #pragma omp target teams distribute collapse (argv[1]=2) // expected-error 
{{expected ')'}} expected-note {{to match this '('}}
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4];


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

[PATCH] D28418: Fixing test to work when the compiler defaults to a different C++ standard version

[Douglas Yung via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291491: Fixing test to work when the compiler defaults to a 
different C++ standard… (authored by dyung).

Changed prior to commit:
  https://reviews.llvm.org/D28418?vs=83447=83703#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28418

Files:
  cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp


Index: cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
===
--- cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
+++ cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
@@ -1,8 +1,13 @@
 // RUN: %clang_cc1 -verify -fopenmp %s
+// RUN: %clang_cc1 -verify -fopenmp -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -std=c++11 %s
 
 void foo() {
 }
 
+#if __cplusplus >= 201103L
+// expected-note@+2 4 {{declared here}}
+#endif
 bool foobool(int argc) {
   return argc;
 }
@@ -43,6 +48,9 @@
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST]; // expected-error 2 {{expected 2 
for loops after '#pragma omp target teams distribute', but found only 1}}
 
+#if __cplusplus >= 201103L
+// expected-note@+5 2 {{non-constexpr function 'foobool' cannot be used in a 
constant expression}}
+#endif
 // expected-error@+3 2 {{directive '#pragma omp target teams distribute' 
cannot contain more than one 'collapse' clause}}
 // expected-error@+2 2 {{argument to 'collapse' clause must be a strictly 
positive integer value}}
 // expected-error@+1 2 {{expression is not an integral constant expression}}
@@ -54,7 +62,11 @@
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST];
 
-// expected-error@+1 2 {{expression is not an integral constant expression}}
+#if __cplusplus <= 199711L
+  // expected-error@+4 2 {{expression is not an integral constant expression}}
+#else
+  // expected-error@+2 2 {{integral constant expression must have integral or 
unscoped enumeration type, not 'char *'}}
+#endif
 #pragma omp target teams distribute collapse (argv[1]=2) // expected-error 
{{expected ')'}} expected-note {{to match this '('}}
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST];
@@ -93,10 +105,17 @@
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4]; // expected-error {{expected 4 for 
loops after '#pragma omp target teams distribute', but found only 1}}
 
-#pragma omp target teams distribute collapse (foobool(1) > 0 ? 1 : 2) // 
expected-error {{expression is not an integral constant expression}}
+// expected-error@+4 {{expression is not an integral constant expression}}
+#if __cplusplus >= 201103L
+// expected-note@+2 {{non-constexpr function 'foobool' cannot be used in a 
constant expression}}
+#endif
+#pragma omp target teams distribute collapse (foobool(1) > 0 ? 1 : 2)
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4];
 
+#if __cplusplus >= 201103L
+  // expected-note@+5{{non-constexpr function 'foobool' cannot be used in a 
constant expression}}
+#endif
 // expected-error@+3 {{expression is not an integral constant expression}}
 // expected-error@+2 2 {{directive '#pragma omp target teams distribute' 
cannot contain more than one 'collapse' clause}}
 // expected-error@+1 2 {{argument to 'collapse' clause must be a strictly 
positive integer value}}
@@ -108,7 +127,11 @@
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4];
 
-// expected-error@+1 {{expression is not an integral constant expression}}
+#if __cplusplus <= 199711L
+  // expected-error@+4 {{expression is not an integral constant expression}}
+#else
+  // expected-error@+2 {{integral constant expression must have integral or 
unscoped enumeration type, not 'char *'}}
+#endif
 #pragma omp target teams distribute collapse (argv[1]=2) // expected-error 
{{expected ')'}} expected-note {{to match this '('}}
   for (int i = 4; i < 12; i++)
 argv[0][i] = argv[0][i] - argv[0][i-4];


Index: cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
===
--- cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
+++ cfe/trunk/test/OpenMP/target_teams_distribute_collapse_messages.cpp
@@ -1,8 +1,13 @@
 // RUN: %clang_cc1 -verify -fopenmp %s
+// RUN: %clang_cc1 -verify -fopenmp -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -std=c++11 %s
 
 void foo() {
 }
 
+#if __cplusplus >= 201103L
+// expected-note@+2 4 {{declared here}}
+#endif
 bool foobool(int argc) {
   return argc;
 }
@@ -43,6 +48,9 @@
   for (int i = ST; i < N; i++)
 argv[0][i] = argv[0][i] - argv[0][i-ST]; // expected-error 2 {{expected 2 for loops after '#pragma omp target teams distribute', but found only 1}}
 
+#if __cplusplus >= 201103L
+// expected-note@+5 2 {{non-constexpr function 'foobool' cannot be used in a constant expression}}
+#endif
 // 

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640314, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#640284, @probinson wrote:
>
> > Upfront, it seemed peculiar to handle only one optimization level.  After 
> > more thought, the whole idea of mixing -O0 and LTO seems wrong.  Sorry, 
> > should have signaled that I had changed my mind about it.
>
>
> You just haven't articulated 1) why it is wrong and 2) what should we do 
> about it.


"Optimize without optimizing" really?  Does not sound confused to you?  
Persuade me why it makes sense.

If it doesn't make sense, then yes making the `-O0 -flto` combination an error 
would be the right path.

Unless you are taking the position that `-flto` doesn't mean "use LTO" and 
instead means something else, like "emit bitcode" in which case you should be 
advocating to change the name of the option to say what it means.


https://reviews.llvm.org/D28404



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

r291489 - MSVC seems to use (void) in __FUNCSIG__ for a zero-parameter function even in C++. Follow suit.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jan  9 16:16:16 2017
New Revision: 291489

URL: http://llvm.org/viewvc/llvm-project?rev=291489=rev
Log:
MSVC seems to use (void) in __FUNCSIG__ for a zero-parameter function even in 
C++. Follow suit.

Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/test/CodeGenCXX/funcsig.cpp

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=291489=291488=291489=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Mon Jan  9 16:16:16 2017
@@ -582,12 +582,13 @@ std::string PredefinedExpr::ComputeName(
 if (i) POut << ", ";
 POut << Decl->getParamDecl(i)->getType().stream(Policy);
   }
-  if (!Context.getLangOpts().CPlusPlus && !Decl->getNumParams())
-POut << "void";
 
   if (FT->isVariadic()) {
 if (FD->getNumParams()) POut << ", ";
 POut << "...";
+  } else if ((IT == FuncSig || !Context.getLangOpts().CPlusPlus) &&
+ !Decl->getNumParams()) {
+POut << "void";
   }
 }
 POut << ")";

Modified: cfe/trunk/test/CodeGenCXX/funcsig.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/funcsig.cpp?rev=291489=291488=291489=diff
==
--- cfe/trunk/test/CodeGenCXX/funcsig.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/funcsig.cpp Mon Jan  9 16:16:16 2017
@@ -13,13 +13,12 @@ void funcNoProto() {
   printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
 }
 // CHECK-C:   @"\01??_C@_0BL@IHLLLCAO@void?5__cdecl?5funcNoProto?$CI?$CJ?$AA@" 
= linkonce_odr unnamed_addr constant [27 x i8] c"void __cdecl funcNoProto()\00"
-// CHECK-CXX: @"\01??_C@_0BL@IHLLLCAO@void?5__cdecl?5funcNoProto?$CI?$CJ?$AA@" 
= linkonce_odr unnamed_addr constant [27 x i8] c"void __cdecl funcNoProto()\00"
+// CHECK-CXX: 
@"\01??_C@_0BP@PJOECCJN@void?5__cdecl?5funcNoProto?$CIvoid?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [31 x i8] c"void __cdecl 
funcNoProto(void)\00"
 
 void funcNoParams(void) {
   printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
 }
-// CHECK-C:   
@"\01??_C@_0CA@GBIDFNBN@void?5__cdecl?5funcNoParams?$CIvoid?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [32 x i8] c"void __cdecl 
funcNoParams(void)\00"
-// CHECK-CXX: 
@"\01??_C@_0BM@GDFBOAEE@void?5__cdecl?5funcNoParams?$CI?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [28 x i8] c"void __cdecl funcNoParams()\00"
+// CHECK: 
@"\01??_C@_0CA@GBIDFNBN@void?5__cdecl?5funcNoParams?$CIvoid?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [32 x i8] c"void __cdecl 
funcNoParams(void)\00"
 
 void freeFunc(int *p, char c) {
   printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
@@ -27,6 +26,11 @@ void freeFunc(int *p, char c) {
 // CHECK: @"\01??_C@_0CD@KLGMNNL@void?5__cdecl?5freeFunc?$CIint?5?$CK?0?5cha@" 
= linkonce_odr unnamed_addr constant [{{.*}} x i8] c"void __cdecl freeFunc(int 
*, char)\00"
 
 #ifdef __cplusplus
+void funcVarargs(...) {
+  printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
+}
+// CHECK-CXX: 
@"\01??_C@_0BO@BOBPLEKP@void?5__cdecl?5funcVarargs?$CI?4?4?4?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [30 x i8] c"void __cdecl funcVarargs(...)\00"
+
 struct TopLevelClass {
   void topLevelMethod(int *, char);
 };


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

[PATCH] D27872: [APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, IEEEdouble)

[Tim Shen via Phabricator via cfe-commits]

timshen added a comment.

In https://reviews.llvm.org/D27872#639020, @hfinkel wrote:

> it is not at all obvious what is going on (i.e. why are we casting to 
> integers?). Maybe semPPCDoubleDoubleImpl needs a better name now? It seems 
> confusing to have semPPCDoubleDoubleImpl and semPPCDoubleDouble where one is 
> not really an "implementation" class of the other.


This is true. I renamed it to semPPCDoubleDoubleLegacy, and modified its 
documentation. I didn't put the documentation for each of the uses, because 
that'd be too verbose.


https://reviews.llvm.org/D27872



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

[PATCH] D27872: [APFloat] Switch from (PPCDoubleDoubleImpl, IEEEdouble) layout to (IEEEdouble, IEEEdouble)

[Tim Shen via Phabricator via cfe-commits]

timshen updated this revision to Diff 83700.
timshen added a comment.

Rename semPPCDoubleDoubleImpl to semPPCDoubleDoubleLegacy to reflect its use 
more accurately.


https://reviews.llvm.org/D27872

Files:
  clang/test/CodeGen/ppc64-complex-parms.c
  llvm/include/llvm/ADT/APFloat.h
  llvm/lib/Support/APFloat.cpp
  llvm/test/CodeGen/PowerPC/fp128-bitcast-after-operation.ll
  llvm/unittests/ADT/APFloatTest.cpp

Index: llvm/unittests/ADT/APFloatTest.cpp
===
--- llvm/unittests/ADT/APFloatTest.cpp
+++ llvm/unittests/ADT/APFloatTest.cpp
@@ -9,6 +9,7 @@
 
 #include "llvm/ADT/APFloat.h"
 #include "llvm/ADT/APSInt.h"
+#include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/raw_ostream.h"
@@ -3181,7 +3182,7 @@
   0x7948ull, 0ull, APFloat::fcInfinity,
   APFloat::rmNearestTiesToEven),
   // TODO: change the 4th 0x75ee to 0x75ef when
-  // PPCDoubleDoubleImpl is gone.
+  // semPPCDoubleDoubleLegacy is gone.
   // LDBL_MAX + (1.01... >> (1023 - 106) + (1.111...0 >> (1023 -
   // 160))) = fcNormal
   std::make_tuple(0x7fefull, 0x7c8eull,
@@ -3234,14 +3235,14 @@
   0x3ff0ull, 0x0001ull,
   APFloat::rmNearestTiesToEven),
   // TODO: change 0xf950 to 0xf940, when
-  // PPCDoubleDoubleImpl is gone.
+  // semPPCDoubleDoubleLegacy is gone.
   // (DBL_MAX - 1 << (1023 - 105)) + (1 << (1023 - 53) + 0) = DBL_MAX +
   // 1.1... << (1023 - 52)
   std::make_tuple(0x7fefull, 0xf950ull,
   0x7c90ull, 0, 0x7fefull,
   0x7c8eull, APFloat::rmNearestTiesToEven),
   // TODO: change 0xf950 to 0xf940, when
-  // PPCDoubleDoubleImpl is gone.
+  // semPPCDoubleDoubleLegacy is gone.
   // (1 << (1023 - 53) + 0) + (DBL_MAX - 1 << (1023 - 105)) = DBL_MAX +
   // 1.1... << (1023 - 52)
   std::make_tuple(0x7c90ull, 0, 0x7fefull,
@@ -3262,7 +3263,7 @@
 << formatv("({0:x} + {1:x}) + ({2:x} + {3:x})", Op1[0], Op1[1], Op2[0],
Op2[1])
.str();
-EXPECT_EQ(Expected[1], A1.getSecondFloat().bitcastToAPInt().getRawData()[0])
+EXPECT_EQ(Expected[1], A1.bitcastToAPInt().getRawData()[1])
 << formatv("({0:x} + {1:x}) + ({2:x} + {3:x})", Op1[0], Op1[1], Op2[0],
Op2[1])
.str();
@@ -3296,7 +3297,7 @@
 << formatv("({0:x} + {1:x}) - ({2:x} + {3:x})", Op1[0], Op1[1], Op2[0],
Op2[1])
.str();
-EXPECT_EQ(Expected[1], A1.getSecondFloat().bitcastToAPInt().getRawData()[0])
+EXPECT_EQ(Expected[1], A1.bitcastToAPInt().getRawData()[1])
 << formatv("({0:x} + {1:x}) - ({2:x} + {3:x})", Op1[0], Op1[1], Op2[0],
Op2[1])
.str();
@@ -3496,12 +3497,53 @@
 APFloat A1(APFloat::PPCDoubleDouble(), APInt(128, 2, Op1));
 APFloat A2(APFloat::PPCDoubleDouble(), APInt(128, 2, Op2));
 EXPECT_EQ(Expected, A1.compare(A2))
-<< formatv("({0:x} + {1:x}) - ({2:x} + {3:x})", Op1[0], Op1[1], Op2[0],
+<< formatv("compare(({0:x} + {1:x}), ({2:x} + {3:x}))", Op1[0], Op1[1],
+   Op2[0], Op2[1])
+   .str();
+  }
+}
+
+TEST(APFloatTest, PPCDoubleDoubleBitwiseIsEqual) {
+  using DataType = std::tuple;
+
+  DataType Data[] = {
+  // (1 + 0) = (1 + 0)
+  std::make_tuple(0x3ff0ull, 0, 0x3ff0ull, 0, true),
+  // (1 + 0) != (1.00...1 + 0)
+  std::make_tuple(0x3ff0ull, 0, 0x3ff1ull, 0,
+  false),
+  // NaN = NaN
+  std::make_tuple(0x7ff8ull, 0, 0x7ff8ull, 0, true),
+  // NaN != NaN with a different bit pattern
+  std::make_tuple(0x7ff8ull, 0, 0x7ff8ull,
+  0x3ff0ull, false),
+  // Inf = Inf
+  std::make_tuple(0x7ff0ull, 0, 0x7ff0ull, 0, true),
+  };
+
+  for (auto Tp : Data) {
+uint64_t Op1[2], Op2[2];
+bool Expected;
+std::tie(Op1[0], Op1[1], Op2[0], Op2[1], Expected) = Tp;
+
+APFloat A1(APFloat::PPCDoubleDouble(), APInt(128, 2, Op1));
+APFloat A2(APFloat::PPCDoubleDouble(), APInt(128, 2, Op2));
+EXPECT_EQ(Expected, A1.bitwiseIsEqual(A2))
+<< formatv("({0:x} + {1:x}) = ({2:x} + {3:x})", Op1[0], Op1[1], Op2[0],
Op2[1])
.str();
   }
 }
 
+TEST(APFloatTest, PPCDoubleDoubleHashValue) {
+  uint64_t Data1[] = {0x3ff1ull, 0x0001ull};
+  uint64_t Data2[] = {0x3ff1ull, 

[PATCH] D28350: [Sema] Avoid -Wshadow warning when a "redefinition of " error is presented

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm


Repository:
  rL LLVM

https://reviews.llvm.org/D28350



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640314, @mehdi_amini wrote:

> You just wrote above that " mixing -O0 and LTO " is wrong, *if* I were to 
> agree with you at some point, then I'd make it a hard error.


Yes, I was not clear that I meant that `-O0 -flto` on the same clang command 
line just seems nonsensical.  "Optimize my program without optimizing it" 
forsooth.


https://reviews.llvm.org/D28404



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640314, @mehdi_amini wrote:

> I don't follow: IMO if I generate a module with optnone and pipe it to `opt 
> -O3` I expect no function IR to be touched. If it is not the case it is a bug.


Your opinion and expectation are not supported by the IR spec.  Optnone skips 
"most" optimization passes.  It is not practical (or was not, at the time) to 
make the -O3 pipeline behave exactly the same as the -O0 pipeline, and also not 
actually necessary to support the purpose for which 'optnone' was invented.

If you have a goal of making 'optnone' functions use the actual -O0 pipeline, 
while non-optnone functions use the optimizing pipeline, more power to you and 
you will need to take up that particular design challenge with Chandler first.


https://reviews.llvm.org/D28404



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

Re: [libcxx] r291466 - [Chrono][Darwin] Make steady_clock use CLOCK_UPTIME_RAW

[Reid Kleckner via cfe-commits]

This appears to have broken the Chromium build:
https://build.chromium.org/p/chromium.fyi/builders/ClangToTMac/builds/12620/steps/gclient%20runhooks/logs/stdio
FAILED: projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o
/Applications/Xcode8.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
  -D_DEBUG -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Iprojects/libcxx/lib
-I/b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/lib -Iinclude
-I/b/c/b/ClangToTMac/src/third_party/llvm/include
-I/b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/include
-DLLVM_FORCE_HEAD_REVISION -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers  -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-Werror=date-time -std=c++11 -fcolor-diagnostics -O3  -isysroot
/Applications/Xcode8.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-mmacosx-version-min=10.11-UNDEBUG -std=c++11 -nostdinc++
-fvisibility-inlines-hidden -Wall -Wextra -W -Wwrite-strings
-Wno-unused-parameter -Wno-long-long -Werror=return-type
-Wno-user-defined-literals -Wno-covered-switch-default -Wno-error -fPIC
-MMD -MT projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o
-MF projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o.d -o
projects/libcxx/lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o -c
/b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/src/chrono.cpp
/b/c/b/ClangToTMac/src/third_party/llvm/projects/libcxx/src/chrono.cpp:102:5:
error: use of undeclared identifier 'gettimeofday'
gettimeofday(, 0);
^

The interesting flag in there is probably -mmacosx-version-min=10.11. Any
thoughts on what's going wrong?

On Mon, Jan 9, 2017 at 11:21 AM, Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bruno
> Date: Mon Jan  9 13:21:48 2017
> New Revision: 291466
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291466=rev
> Log:
> [Chrono][Darwin] Make steady_clock use CLOCK_UPTIME_RAW
>
> Use CLOCK_UPTIME_RAW in case clock_gettime is available on Darwin.
>
> On Apple platforms only CLOCK_UPTIME_RAW or mach_absolute_time are able
> to time functions in the nanosecond range. Thus, they are the only
> acceptable implementations of steady_clock.
>
> Differential Revision: https://reviews.llvm.org/D27429
>
> rdar://problem/29449467
>
> Modified:
> libcxx/trunk/src/chrono.cpp
>
> Modified: libcxx/trunk/src/chrono.cpp
> URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/
> chrono.cpp?rev=291466=291465=291466=diff
> 
> ==
> --- libcxx/trunk/src/chrono.cpp (original)
> +++ libcxx/trunk/src/chrono.cpp Mon Jan  9 13:21:48 2017
> @@ -12,6 +12,28 @@
>  #include "system_error"  // __throw_system_error
>  #include // clock_gettime, CLOCK_MONOTONIC and
> CLOCK_REALTIME
>
> +#if (__APPLE__)
> +#if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
> +#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101200
> +#define _LIBCXX_USE_CLOCK_GETTIME
> +#endif
> +#elif defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__)
> +#if __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ >= 10
> +#define _LIBCXX_USE_CLOCK_GETTIME
> +#endif
> +#elif defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__)
> +#if __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ >= 10
> +#define _LIBCXX_USE_CLOCK_GETTIME
> +#endif
> +#elif defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__)
> +#if __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ >= 3
> +#define _LIBCXX_USE_CLOCK_GETTIME
> +#endif
> +#endif // __ENVIRONMENT_.*_VERSION_MIN_REQUIRED__
> +#else
> +#define _LIBCXX_USE_CLOCK_GETTIME
> +#endif // __APPLE__
> +
>  #if defined(_LIBCPP_WIN32API)
>  #define WIN32_LEAN_AND_MEAN
>  #define VC_EXTRA_LEAN
> @@ -70,16 +92,16 @@ system_clock::now() _NOEXCEPT
> static_cast<__int64>(ft.dwLowDateTime)};
>return time_point(duration_cast(d - nt_to_unix_epoch));
>  #else
> -#ifdef CLOCK_REALTIME
> +#if defined(_LIBCXX_USE_CLOCK_GETTIME) && defined(CLOCK_REALTIME)
>  struct timespec tp;
>  if (0 != clock_gettime(CLOCK_REALTIME, ))
>  __throw_system_error(errno, "clock_gettime(CLOCK_REALTIME)
> failed");
>  return time_point(seconds(tp.tv_sec) + microseconds(tp.tv_nsec /
> 1000));
> -#else  // !CLOCK_REALTIME
> +#else
>  timeval tv;
>  gettimeofday(, 0);
>  return time_point(seconds(tv.tv_sec) + microseconds(tv.tv_usec));
> -#endif  // CLOCK_REALTIME
> +#endif // _LIBCXX_USE_CLOCK_GETTIME && CLOCK_REALTIME
>  #endif
>  }
>
> @@ -106,6 +128,18 @@ const bool steady_clock::is_steady;
>
>  #if defined(__APPLE__)
>
> +// Darwin libc versions >= 1133 provide ns precision via CLOCK_UPTIME_RAW
> +#if 

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and to the right

[Daniel Jasper via Phabricator via cfe-commits]

djasper accepted this revision.
djasper added a comment.

Just some nits. Thanks for working on this!




Comment at: lib/Format/WhitespaceManager.cpp:158
 
+static bool IsPointerOrReference(tok::TokenKind Kind) {
+  return Kind == tok::star || Kind == tok::amp || Kind == tok::ampamp;

This should be isPointerOrReference according to the coding guidelines.



Comment at: lib/Format/WhitespaceManager.cpp:197
+  for (int previous = i - 1;
+   previous >= 0 && IsPointerOrReference(Changes[previous].Kind);
+   previous--) {

This really makes me wonder if it wouldn't be much better to just attach the 
FormatTokens to the changes so we don't have to reimplement more and more of 
that. But that's probably for a follow up change.


https://reviews.llvm.org/D27651



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

[PATCH] D28399: PR31469: Don't add friend template class decls to redecl chain in dependent contexts.

[Richard Smith via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: lib/Sema/SemaTemplate.cpp:1214-1215
 CXXRecordDecl::Create(Context, Kind, SemanticContext, KWLoc, NameLoc, Name,
   PrevClassTemplate?
 PrevClassTemplate->getTemplatedDecl() : nullptr,
   /*DelayTypeCreation=*/true);

You should keep the class out of its redeclaration chain too.


Repository:
  rL LLVM

https://reviews.llvm.org/D28399



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#640297, @probinson wrote:

> Sorry, you lost me.  CFI is part of DWARF and we do DWARF perfectly well 
> without LTO (and at O0).


This CFI: http://clang.llvm.org/docs/ControlFlowIntegrity.html


https://reviews.llvm.org/D28404



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

[PATCH] D28441: [libc++] [CMake] Link with /nodefaultlibs on Windows

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: CMakeLists.txt:43
+if (WIN32 AND NOT MINGW)
+  set(LIBCXX_TARGETING_WINDOWS ON)
+else()

smeenai wrote:
> EricWF wrote:
> > EricWF wrote:
> > > smeenai wrote:
> > > > Not the biggest fan of this name, since it's not obvious why MinGW 
> > > > shouldn't count as targeting Windows. I thought of 
> > > > `LIBCXX_TARGETING_NATIVE_WINDOWS` or `LIBCXX_TARGETING_MSVCRT` instead, 
> > > > but MinGW is also native Windows and targets MSVCRT, so those names 
> > > > aren't any better from that perspective either. I can't think of 
> > > > anything else at the moment, but I'm sure there's a better name.
> > > Thanks for the feedback. I'm not exactly sure how this macro should be 
> > > defined either.
> > > 
> > > I thought that `MinGW` provided its own C library runtime wrappers that 
> > > forward to `MSVCRT`. 
> > > 
> > > The difference I was imagining between Native Windows builds and `MinGW` 
> > > is that it's possible to use
> > > `pthread` with `MinGW` but not with native Windows targets. 
> > Another distinction I would like this macro to embody is whether on not the 
> > compiler defines `_MSC_VER`.  `clang-cl`, `clang++`  on Windows, and MSVC 
> > `cl` all define this macro.
> If I recall correctly, MinGW uses `mscvrt.dll` but not `msvcrt.lib` (see my 
> other comment for the distinction). I'm fine with this name for now then; we 
> can always bikeshed later.
> 
> Btw it's also possible to use pthread with native Windows targets, via 
> [pthreads-win32](http://www.sourceware.org/pthreads-win32/) or other 
> libraries.
I'd call this LIBCXX_TARGETING_MSVCRT. "msvcrt.dll" usually refers to an 
ancient version (6?) of the Visual C runtime that is distributed as part of 
Windows. Typically it is found at C:/Windows/system32/msvcrt.dll. Mingw uses 
this, because it is available on all Windows systems they care to support. This 
DLL basically never receives updates, so I wouldn't want to build libc++ 
functionality on top of it. Over time, it seems that mingw has had to implement 
more and more C runtime functionality itself, and I wouldn't want libc++ to 
have to do that.

Until recently, MSVC users were required to redistribute the version of the CRT 
they chose to link against, and it was expected that all DLLs sharing CRT 
resources had to link against the same CRT version. Of course, this caused 
problems, so they went back to the single, OS-provided CRT in VS 2015 
(https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/).

My conclusion is that it's no longer worth thinking of that old DLL as the 
Visual C runtime. It's just an artifact of history at this point. If you say 
libc++ targets the MSVCRT, you're probably talking about the modern, universal 
CRT.

---

If you want this option to imply both the C++ ABI and the C runtime, then 
LIBCXX_TARGETING_MSVC would probably be a more appropriate name. Clang and LLVM 
have some support for using the Itanium C++ ABI with the MSVCRT, but it is more 
experimental, and not ABI compatible with any existing software. Saleem could 
say more about where he thinks this target will go in the future and whether 
it's worth adding to the libc++ support configuration matrix.



Comment at: lib/CMakeLists.txt:108-109
+if (LIBCXX_TARGETING_WINDOWS)
+  add_compile_flags(/Zl)
+  add_link_flags(/nodefaultlib)
+  add_library_flags(ucrt) # Universal C runtime

smeenai wrote:
> EricWF wrote:
> > smeenai wrote:
> > > halyavin wrote:
> > > > smeenai wrote:
> > > > > These should be guarded under a check for a cl or cl-like frontend 
> > > > > rather than `LIBCXX_TARGETING_WINDOWS` (since in theory we could be 
> > > > > using the regular clang frontend to compile for Windows as well).
> > > > Regular clang supports both gcc-like and cl-like options (there are 2 
> > > > compilers: clang.exe and clang-cl.exe). I think it is not worth it to 
> > > > support both considering they differ only in command line options 
> > > > handling.
> > > I'm aware of the separate drivers, but I still think it's worthwhile 
> > > specifying appropriate conditionals when it's easy enough to do. (In this 
> > > case, the inverse check of 
> > > https://reviews.llvm.org/diffusion/L/browse/libcxx/trunk/CMakeLists.txt;291339$394
> > >  should do the trick.)
> > Is it alright if libc++'s CMakeLists.txt only supports targeting `clang-cl` 
> > for the time being? I would love to also support `clang++` but that seems 
> > like a ways off.
> > 
> > For now my only concern is getting `clang-cl` working. Expanding to include 
> > supporting `clang++` seems like it's a ways away. @smeenai Would this be a 
> > regression for you?
> It would. It's easy enough to work around locally, so I don't care too much, 
> but it's also easy enough to not regress in the first place :p Would using 
> `add_flags_if_supported` and `add_link_flags_if_supported` instead of the 
> unconditional 

[PATCH] D26267: [Modules] Include builtins with #include instead of #import for ObjC

[Richard Smith via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: lib/Lex/HeaderSearch.cpp:1082
 
+  auto TryEnterImported = [&](void) -> bool {
+if (!ModulesEnabled)

Maybe add a FIXME here indicating that this is a workaround for the lack of 
proper modules-aware support for `#import` / `#pragma once`?


https://reviews.llvm.org/D26267



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#640284, @probinson wrote:

> In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote:
>
> > In https://reviews.llvm.org/D28404#640170, @probinson wrote:
> >
> > > In https://reviews.llvm.org/D28404#640090, @mehdi_amini wrote:
> > >
> > > > In https://reviews.llvm.org/D28404#640046, @probinson wrote:
> > > >
> > > > > "I don't care" doesn't seem like much of a principle.
> > > >
> > > >
> > > > Long version is: "There is no use-case, no users, so I don't have much 
> > > > motivation to push it forward for the only sake of completeness". Does 
> > > > it sound enough of a principle like that?
> > >
> > >
> > > No.  You still need to have adequate justification for your use case, 
> > > which I think you do not.
> >
> >
> > I don't follow your logic. 
> >  IIUC, you asked about "why not supporting `O1/O2/O3`" ; how is *not 
> > supporting* these because their not useful / don't have use-case related to 
> > "supporting `O0` is useful"?
>
>
> Upfront, it seemed peculiar to handle only one optimization level.  After 
> more thought, the whole idea of mixing -O0 and LTO seems wrong.  Sorry, 
> should have signaled that I had changed my mind about it.


You just haven't articulated 1) why it is wrong and 2) what should we do about 
it.

> 
> 
> Optnone does not equal -O0.  It is a debugging aid for the programmer, 
> because debugging optimized code sucks.  If you have an LTO-built 
> application and want to de-optimize parts of it to aid with debugging, 
> then you can use the pragma, as originally intended.
 
 Having to modifying the source isn't friendly. Not being able to honor -O0 
 during LTO is not user-friendly.
>>> 
>>> IMO, '-O0' and '-flto' are conflicting options and therefore not deserving 
>>> of special support.
>> 
>> You're advocating for *rejecting* O0 built module at link-time? We'd still 
>> need to detect this though. Status-quo isn't acceptable.
>>  Also, that's not practicable: what if I have an LTO static library for 
>> which I don't have the source, now if I build my own file with -O0 -flto I 
>> can't link anymore.
> 
> No, I'm saying they are conflicting options on the same Clang command line.
>  As long as your linker can handle foo.o and bar.bc on the same command line, 
> not a problem.  (If your linker can't handle that, fix the linker first.)

You just wrote above that " mixing -O0 and LTO " is wrong, *if* I were to agree 
with you at some point, then I'd make it a hard error.

>>> In my experience, modifying source is by far simpler than hacking a build 
>>> system to make a special case for compiler options for one module in an 
>>> application.  (If you have a way to build Clang with everything done LTO 
>>> except one module built with -O0, on Linux with ninja, I would be very 
>>> curious to hear how you do that.)
>> 
>> Static library, separated projects, etc.
>>  We have tons of users...
> 
> Still waiting.

Waiting for what?
We have use-cases, I gave you a few (vendor static libraries are one). Again, 
if you think it is wrong to support O0 and LTO, then please elaborate.

>   I don't think `-c -O0` should get this not-entirely-O0-like behavior.
 
 What is "not-entirely"? And why do you think that?
>>> 
>>> "Not entirely" means that running the -O0 pipeline, and running an 
>>> optimization pipeline but asking some subset of passes to turn themselves 
>>> off, does not get you the same result.  And I think that because I'm the 
>>> one who put 'optnone' upstream in the first place.  The case that 
>>> particularly sticks in my memory is the register allocator, but I believe 
>>> there are passes at every stage that do not turn themselves off for optnone.
>> 
>> That's orthogonal: you're saying we are not handling it correctly yet, I'm 
>> just moving toward *fixing* all these.
> 
> It's not orthogonal; that's exactly how 'optnone' behaves today.  If you have 
> proposed a redesign of how to mix optnone and non-optnone functions in the 
> same compilation unit, in some way other than what's done today, I am not 
> aware of it; can you point to your proposal?

I don't follow: IMO if I generate a module with optnone and pipe it to `opt 
-O3` I expect no function IR to be touched. If it is not the case it is a bug.


https://reviews.llvm.org/D28404



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

[PATCH] D28018: AMD family 17h (znver1) enablement

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

LGTM - @craig.topper any additional comments?


https://reviews.llvm.org/D28018



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640182, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote:
>
> > Also, that's not practicable: what if I have an LTO static library for 
> > which I don't have the source, now if I build my own file with -O0 -flto I 
> > can't link anymore.
>
>
> Also: LTO is required for some features likes CFI. There are users who wants 
> CFI+O0 during development (possibly for debugging a subcomponent of the app).


Sorry, you lost me.  CFI is part of DWARF and we do DWARF perfectly well 
without LTO (and at O0).


https://reviews.llvm.org/D28404



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#640170, @probinson wrote:
>
> > In https://reviews.llvm.org/D28404#640090, @mehdi_amini wrote:
> >
> > > In https://reviews.llvm.org/D28404#640046, @probinson wrote:
> > >
> > > > "I don't care" doesn't seem like much of a principle.
> > >
> > >
> > > Long version is: "There is no use-case, no users, so I don't have much 
> > > motivation to push it forward for the only sake of completeness". Does it 
> > > sound enough of a principle like that?
> >
> >
> > No.  You still need to have adequate justification for your use case, which 
> > I think you do not.
>
>
> I don't follow your logic. 
>  IIUC, you asked about "why not supporting `O1/O2/O3`" ; how is *not 
> supporting* these because their not useful / don't have use-case related to 
> "supporting `O0` is useful"?


Upfront, it seemed peculiar to handle only one optimization level.  After more 
thought, the whole idea of mixing -O0 and LTO seems wrong.  Sorry, should have 
signaled that I had changed my mind about it.

 Optnone does not equal -O0.  It is a debugging aid for the programmer, 
 because debugging optimized code sucks.  If you have an LTO-built 
 application and want to de-optimize parts of it to aid with debugging, 
 then you can use the pragma, as originally intended.
>>> 
>>> Having to modifying the source isn't friendly. Not being able to honor -O0 
>>> during LTO is not user-friendly.
>> 
>> IMO, '-O0' and '-flto' are conflicting options and therefore not deserving 
>> of special support.
> 
> You're advocating for *rejecting* O0 built module at link-time? We'd still 
> need to detect this though. Status-quo isn't acceptable.
>  Also, that's not practicable: what if I have an LTO static library for which 
> I don't have the source, now if I build my own file with -O0 -flto I can't 
> link anymore.

No, I'm saying they are conflicting options on the same Clang command line.
As long as your linker can handle foo.o and bar.bc on the same command line, 
not a problem.  (If your linker can't handle that, fix the linker first.)

>> In my experience, modifying source is by far simpler than hacking a build 
>> system to make a special case for compiler options for one module in an 
>> application.  (If you have a way to build Clang with everything done LTO 
>> except one module built with -O0, on Linux with ninja, I would be very 
>> curious to hear how you do that.)
> 
> Static library, separated projects, etc.
>  We have tons of users...

Still waiting.  Your up-front use case was about de-optimizing a module to 
assist debugging it within an LTO-built application, not building entire 
projects one way versus another.  If that is not actually your use case, you 
need to start over with the correct description.

   I don't think `-c -O0` should get this not-entirely-O0-like behavior.
>>> 
>>> What is "not-entirely"? And why do you think that?
>> 
>> "Not entirely" means that running the -O0 pipeline, and running an 
>> optimization pipeline but asking some subset of passes to turn themselves 
>> off, does not get you the same result.  And I think that because I'm the one 
>> who put 'optnone' upstream in the first place.  The case that particularly 
>> sticks in my memory is the register allocator, but I believe there are 
>> passes at every stage that do not turn themselves off for optnone.
> 
> That's orthogonal: you're saying we are not handling it correctly yet, I'm 
> just moving toward *fixing* all these.

It's not orthogonal; that's exactly how 'optnone' behaves today.  If you have 
proposed a redesign of how to mix optnone and non-optnone functions in the same 
compilation unit, in some way other than what's done today, I am not aware of 
it; can you point to your proposal?


https://reviews.llvm.org/D28404



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

r291484 - PR31587: Fix handling of __FUNCSIG__ in C.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon Jan  9 15:40:40 2017
New Revision: 291484

URL: http://llvm.org/viewvc/llvm-project?rev=291484=rev
Log:
PR31587: Fix handling of __FUNCSIG__ in C.

Fix crash if __FUNCSIG__ is used in a function without a prototype, and use
"(void)" as parameter list instead of "()" for a function with a no-parameters
prototype, matching MSVC's observed behavior.

Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/test/CodeGenCXX/funcsig.cpp

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=291484=291483=291484=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Mon Jan  9 15:40:40 2017
@@ -562,8 +562,7 @@ std::string PredefinedExpr::ComputeName(
   FT = dyn_cast(AFT);
 
 if (IT == FuncSig) {
-  assert(FT && "We must have a written prototype in this case.");
-  switch (FT->getCallConv()) {
+  switch (AFT->getCallConv()) {
   case CC_C: POut << "__cdecl "; break;
   case CC_X86StdCall: POut << "__stdcall "; break;
   case CC_X86FastCall: POut << "__fastcall "; break;
@@ -583,6 +582,8 @@ std::string PredefinedExpr::ComputeName(
 if (i) POut << ", ";
 POut << Decl->getParamDecl(i)->getType().stream(Policy);
   }
+  if (!Context.getLangOpts().CPlusPlus && !Decl->getNumParams())
+POut << "void";
 
   if (FT->isVariadic()) {
 if (FD->getNumParams()) POut << ", ";
@@ -592,7 +593,7 @@ std::string PredefinedExpr::ComputeName(
 POut << ")";
 
 if (const CXXMethodDecl *MD = dyn_cast(FD)) {
-  const FunctionType *FT = MD->getType()->castAs();
+  assert(FT && "We must have a written prototype in this case.");
   if (FT->isConst())
 POut << " const";
   if (FT->isVolatile())

Modified: cfe/trunk/test/CodeGenCXX/funcsig.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/funcsig.cpp?rev=291484=291483=291484=diff
==
--- cfe/trunk/test/CodeGenCXX/funcsig.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/funcsig.cpp Mon Jan  9 15:40:40 2017
@@ -1,22 +1,39 @@
-// RUN: %clang_cc1 -std=c++11 -triple i686-pc-win32 %s -fms-extensions 
-fno-rtti -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -triple i686-pc-win32 %s -fms-extensions 
-fno-rtti -emit-llvm -o - | FileCheck %s --check-prefix=CHECK 
--check-prefix=CHECK-CXX
+// RUN: %clang_cc1 -x c -triple i686-pc-win32 %s -fms-extensions -fno-rtti 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-C
 
 // Similar to predefined-expr.cpp, but not as exhaustive, since it's basically
 // equivalent to __PRETTY_FUNCTION__.
 
-extern "C" int printf(const char *, ...);
+#ifdef __cplusplus
+extern "C"
+#endif
+int printf(const char *, ...);
 
-void freeFunc(int *, char) {
+void funcNoProto() {
+  printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
+}
+// CHECK-C:   @"\01??_C@_0BL@IHLLLCAO@void?5__cdecl?5funcNoProto?$CI?$CJ?$AA@" 
= linkonce_odr unnamed_addr constant [27 x i8] c"void __cdecl funcNoProto()\00"
+// CHECK-CXX: @"\01??_C@_0BL@IHLLLCAO@void?5__cdecl?5funcNoProto?$CI?$CJ?$AA@" 
= linkonce_odr unnamed_addr constant [27 x i8] c"void __cdecl funcNoProto()\00"
+
+void funcNoParams(void) {
+  printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
+}
+// CHECK-C:   
@"\01??_C@_0CA@GBIDFNBN@void?5__cdecl?5funcNoParams?$CIvoid?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [32 x i8] c"void __cdecl 
funcNoParams(void)\00"
+// CHECK-CXX: 
@"\01??_C@_0BM@GDFBOAEE@void?5__cdecl?5funcNoParams?$CI?$CJ?$AA@" = 
linkonce_odr unnamed_addr constant [28 x i8] c"void __cdecl funcNoParams()\00"
+
+void freeFunc(int *p, char c) {
   printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
 }
 // CHECK: @"\01??_C@_0CD@KLGMNNL@void?5__cdecl?5freeFunc?$CIint?5?$CK?0?5cha@" 
= linkonce_odr unnamed_addr constant [{{.*}} x i8] c"void __cdecl freeFunc(int 
*, char)\00"
 
+#ifdef __cplusplus
 struct TopLevelClass {
   void topLevelMethod(int *, char);
 };
 void TopLevelClass::topLevelMethod(int *, char) {
   printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
 }
-// CHECK: @"\01??_C@_0DL@OBHNMDP@void?5__thiscall?5TopLevelClass?3?3t@" = 
linkonce_odr unnamed_addr constant [{{.*}} x i8] c"void __thiscall 
TopLevelClass::topLevelMethod(int *, char)\00"
+// CHECK-CXX: @"\01??_C@_0DL@OBHNMDP@void?5__thiscall?5TopLevelClass?3?3t@" = 
linkonce_odr unnamed_addr constant [{{.*}} x i8] c"void __thiscall 
TopLevelClass::topLevelMethod(int *, char)\00"
 
 namespace NS {
 struct NamespacedClass {
@@ -25,5 +42,6 @@ struct NamespacedClass {
 void NamespacedClass::namespacedMethod(int *, char) {
   printf("__FUNCSIG__ %s\n\n", __FUNCSIG__);
 }
-// CHECK: @"\01??_C@_0ED@PFDKIEBA@void?5__thiscall?5NS?3?3NamespacedCl@" = 
linkonce_odr unnamed_addr constant [{{.*}} x i8] c"void __thiscall 
NS::NamespacedClass::namespacedMethod(int *, char)\00"
+// CHECK-CXX: 

[PATCH] D28427: Allow constexpr construction of subobjects unconditionally, not just in C++14.

[David L. Jones via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291480: Allow constexpr construction of subobjects 
unconditionally, not just in C++14. (authored by dlj).

Changed prior to commit:
  https://reviews.llvm.org/D28427?vs=83650=83686#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28427

Files:
  cfe/trunk/lib/AST/ExprConstant.cpp
  cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
  cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp


Index: cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
===
--- cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
+++ cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
@@ -39,17 +39,17 @@
 T t[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.0, 8, 9.0, 10, 11.0, 12 };
 
 // CHECK: call {{.*}} @__cxa_atexit
-// CHECK: getelementptr inbounds ({{.*}} bitcast {{.*}}* @t to %struct.T*), 
i64 6
+// CHECK: getelementptr inbounds ({{.*}} getelementptr inbounds ([2 x [3 x 
{{.*}}]], [2 x [3 x {{.*}}]]* @t, i32 0, i32 0, i32 0), i64 6)
 // CHECK: call void @_ZN1TD1Ev
 // CHECK: icmp eq {{.*}} @t
 // CHECK: br i1 {{.*}}
 
 static T t2[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.0, 8, 9.0, 10, 11.0, 12 };
 
 // CHECK: call {{.*}} @__cxa_atexit
-// CHECK: getelementptr inbounds ({{.*}} bitcast {{.*}}* @_ZL2t2 to 
%struct.T*), i64 6
+// CHECK: getelementptr inbounds ({{.*}} getelementptr inbounds ([2 x [3 x 
{{.*}}]], [2 x [3 x {{.*}}]]* @_ZL2t2, i32 0, i32 0, i32 0), i64 6)
 // CHECK: call void @_ZN1TD1Ev
-// CHECK: icmp eq {{.*}} @_ZL2t
+// CHECK: icmp eq {{.*}} @_ZL2t2
 // CHECK: br i1 {{.*}}
 
 using U = T[2][3];
Index: cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
===
--- cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
+++ cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -verify %s -pedantic-errors -std=c++11
+// RUN: %clang_cc1 -verify %s -pedantic-errors -std=c++14
+// expected-no-diagnostics
+
+struct foo_t {
+  union {
+int i;
+volatile int j;
+  } u;
+};
+
+__attribute__((__require_constant_initialization__))
+static const foo_t x = {{0}};
+
+union foo_u {
+  int i;
+  volatile int j;
+};
+
+__attribute__((__require_constant_initialization__))
+static const foo_u y = {0};
Index: cfe/trunk/lib/AST/ExprConstant.cpp
===
--- cfe/trunk/lib/AST/ExprConstant.cpp
+++ cfe/trunk/lib/AST/ExprConstant.cpp
@@ -1627,8 +1627,17 @@
   // C++1y: A constant initializer for an object o [...] may also invoke
   // constexpr constructors for o and its subobjects even if those objects
   // are of non-literal class types.
-  if (Info.getLangOpts().CPlusPlus14 && This &&
-  Info.EvaluatingDecl == This->getLValueBase())
+  //
+  // C++11 missed this detail for aggregates, so classes like this:
+  //   struct foo_t { union { int i; volatile int j; } u; };
+  // are not (obviously) initializable like so:
+  //   __attribute__((__require_constant_initialization__))
+  //   static const foo_t x = {{0}};
+  // because "i" is a subobject with non-literal initialization (due to the
+  // volatile member of the union). See:
+  //   http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1677
+  // Therefore, we use the C++1y behavior.
+  if (This && Info.EvaluatingDecl == This->getLValueBase())
 return true;
 
   // Prvalue constant expressions must be of literal types.


Index: cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
===
--- cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
+++ cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
@@ -39,17 +39,17 @@
 T t[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.0, 8, 9.0, 10, 11.0, 12 };
 
 // CHECK: call {{.*}} @__cxa_atexit
-// CHECK: getelementptr inbounds ({{.*}} bitcast {{.*}}* @t to %struct.T*), i64 6
+// CHECK: getelementptr inbounds ({{.*}} getelementptr inbounds ([2 x [3 x {{.*}}]], [2 x [3 x {{.*}}]]* @t, i32 0, i32 0, i32 0), i64 6)
 // CHECK: call void @_ZN1TD1Ev
 // CHECK: icmp eq {{.*}} @t
 // CHECK: br i1 {{.*}}
 
 static T t2[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.0, 8, 9.0, 10, 11.0, 12 };
 
 // CHECK: call {{.*}} @__cxa_atexit
-// CHECK: getelementptr inbounds ({{.*}} bitcast {{.*}}* @_ZL2t2 to %struct.T*), i64 6
+// CHECK: getelementptr inbounds ({{.*}} getelementptr inbounds ([2 x [3 x {{.*}}]], [2 x [3 x {{.*}}]]* @_ZL2t2, i32 0, i32 0, i32 0), i64 6)
 // CHECK: call void @_ZN1TD1Ev
-// CHECK: icmp eq {{.*}} @_ZL2t
+// CHECK: icmp eq {{.*}} @_ZL2t2
 // CHECK: br i1 {{.*}}
 
 using U = T[2][3];
Index: cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
===
--- cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
+++ 

r291480 - Allow constexpr construction of subobjects unconditionally, not just in C++14.

[David L. Jones via cfe-commits]

Author: dlj
Date: Mon Jan  9 15:38:07 2017
New Revision: 291480

URL: http://llvm.org/viewvc/llvm-project?rev=291480=rev
Log:
Allow constexpr construction of subobjects unconditionally, not just in C++14.

Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:

  struct foo_t { union { int i; volatile int j; } u; };

  __attribute__((__require_constant_initialization__))
  static const foo_t x = {{0}};

Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:

  union foo_u { int i; volatile int j; };
  __attribute__((__require_constant_initialization__))
  static const foo_u x = {0};

does have a constant initializer.

(This was triggered by musl's pthread_mutex_t type when building under C++11.)

Reviewers: rsmith

Subscribers: EricWF, cfe-commits

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

Added:
cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=291480=291479=291480=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Jan  9 15:38:07 2017
@@ -1627,8 +1627,17 @@ static bool CheckLiteralType(EvalInfo 
   // C++1y: A constant initializer for an object o [...] may also invoke
   // constexpr constructors for o and its subobjects even if those objects
   // are of non-literal class types.
-  if (Info.getLangOpts().CPlusPlus14 && This &&
-  Info.EvaluatingDecl == This->getLValueBase())
+  //
+  // C++11 missed this detail for aggregates, so classes like this:
+  //   struct foo_t { union { int i; volatile int j; } u; };
+  // are not (obviously) initializable like so:
+  //   __attribute__((__require_constant_initialization__))
+  //   static const foo_t x = {{0}};
+  // because "i" is a subobject with non-literal initialization (due to the
+  // volatile member of the union). See:
+  //   http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1677
+  // Therefore, we use the C++1y behavior.
+  if (This && Info.EvaluatingDecl == This->getLValueBase())
 return true;
 
   // Prvalue constant expressions must be of literal types.

Added: cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp?rev=291480=auto
==
--- cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp (added)
+++ cfe/trunk/test/CXX/basic/basic.start/basic.start.init/p2.cpp Mon Jan  9 
15:38:07 2017
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -verify %s -pedantic-errors -std=c++11
+// RUN: %clang_cc1 -verify %s -pedantic-errors -std=c++14
+// expected-no-diagnostics
+
+struct foo_t {
+  union {
+int i;
+volatile int j;
+  } u;
+};
+
+__attribute__((__require_constant_initialization__))
+static const foo_t x = {{0}};
+
+union foo_u {
+  int i;
+  volatile int j;
+};
+
+__attribute__((__require_constant_initialization__))
+static const foo_u y = {0};

Modified: cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp?rev=291480=291479=291480=diff
==
--- cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/global-array-destruction.cpp Mon Jan  9 15:38:07 
2017
@@ -39,7 +39,7 @@ struct T {
 T t[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.0, 8, 9.0, 10, 11.0, 12 };
 
 // CHECK: call {{.*}} @__cxa_atexit
-// CHECK: getelementptr inbounds ({{.*}} bitcast {{.*}}* @t to %struct.T*), 
i64 6
+// CHECK: getelementptr inbounds ({{.*}} getelementptr inbounds ([2 x [3 x 
{{.*}}]], [2 x [3 x {{.*}}]]* @t, i32 0, i32 0, i32 0), i64 6)
 // CHECK: call void @_ZN1TD1Ev
 // CHECK: icmp eq {{.*}} @t
 // CHECK: br i1 {{.*}}
@@ -47,9 +47,9 @@ T t[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.
 static T t2[2][3] = { 1.0, 2, 3.0, 4, 5.0, 6, 7.0, 8, 9.0, 10, 11.0, 12 };
 
 // CHECK: call {{.*}} @__cxa_atexit
-// CHECK: getelementptr inbounds ({{.*}} bitcast {{.*}}* @_ZL2t2 to 
%struct.T*), i64 6
+// CHECK: getelementptr inbounds ({{.*}} getelementptr inbounds ([2 x [3 x 
{{.*}}]], [2 x [3 x {{.*}}]]* @_ZL2t2, i32 0, i32 0, i32 0), i64 6)
 // CHECK: call void @_ZN1TD1Ev
-// CHECK: icmp eq {{.*}} @_ZL2t
+// CHECK: icmp eq {{.*}} @_ZL2t2
 // CHECK: br i1 {{.*}}
 
 using U = T[2][3];


___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D26900: [cmake] Obtain LLVM_CMAKE_PATH from llvm-config if available

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm I figure we've waited a few days at this point.


https://reviews.llvm.org/D26900



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

[PATCH] D27680: [CodeGen] Move lifetime.start of a variable when goto jumps back past its declaration

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 83680.
ahatanak added a comment.
Herald added a subscriber: mgorny.

I added an AST analysis pass that is run before IRGen and decides which 
VarDecls need their lifetimes to be extended or disabled. It only looks at 
VarDecls which have their addresses taken and are declared after a label is 
seen. It extends the lifetimes of VarDecls declared in a compound statement if 
there are backward gotos that don't leave the scope of the compound statement. 
However, if there are gotos that jump from outside into the compound statement 
too, it drops all lifetime markers for those VarDecls since emitting 
lifetime.start at the beginning of the compound statement might break 
use-after-scope check. For example:

goto label2;

{

  // cannot move lifetime.start for "x" to the start of this block since the 
"goto label2" will
  // jump over lifetime.start.
  ...

label2:

  ...

label1:

  ...
  int x;
  foo1();
  goto label1; // backward goto.

}


https://reviews.llvm.org/D27680

Files:
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGStmt.cpp
  lib/CodeGen/CMakeLists.txt
  lib/CodeGen/CodeGenFunction.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/CodeGen/LifetimeExtend.cpp
  lib/CodeGen/LifetimeExtend.h
  test/CodeGen/lifetime2.c

Index: test/CodeGen/lifetime2.c
===
--- test/CodeGen/lifetime2.c
+++ test/CodeGen/lifetime2.c
@@ -1,5 +1,5 @@
-// RUN: %clang -S -emit-llvm -o - -O2 %s | FileCheck %s -check-prefixes=CHECK,O2
-// RUN: %clang -S -emit-llvm -o - -O0 %s | FileCheck %s -check-prefixes=CHECK,O0
+// RUN: %clang_cc1 -S -emit-llvm -o - -O2 -disable-llvm-passes %s | FileCheck %s -check-prefixes=CHECK,O2
+// RUN: %clang_cc1 -S -emit-llvm -o - -O0 %s | FileCheck %s -check-prefixes=CHECK,O0
 
 extern int bar(char *A, int n);
 
@@ -19,17 +19,16 @@
 
 // CHECK-LABEL: @no_goto_bypass
 void no_goto_bypass() {
+  // O2: @llvm.lifetime.start(i64 5
   // O2: @llvm.lifetime.start(i64 1
   char x;
 l1:
   bar(, 1);
-  // O2: @llvm.lifetime.start(i64 5
-  // O2: @llvm.lifetime.end(i64 5
   char y[5];
   bar(y, 5);
   goto l1;
   // Infinite loop
-  // O2-NOT: @llvm.lifetime.end(i64 1
+  // O2-NOT: @llvm.lifetime.end(
 }
 
 // CHECK-LABEL: @goto_bypass
@@ -89,3 +88,59 @@
 L:
   bar(, 1);
 }
+
+// O2-LABEL: define i32 @move_lifetime_start
+// O2: %i = alloca i32, align 4
+// O2: %[[BITCAST:[0-9]+]] = bitcast i32* %i to i8*
+// O2: call void @llvm.lifetime.start(i64 4, i8* %[[BITCAST]])
+// O2: br label %[[DESTLABEL:[a-z0-9]+]]
+// O2: [[DESTLABEL]]:
+// O2: br label %[[DESTLABEL]]
+// O2: %[[BITCAST2:[0-9]+]] = bitcast i32* %i to i8*
+// O2: call void @llvm.lifetime.end(i64 4, i8* %[[BITCAST2]])
+
+extern void foo2(int p);
+
+int move_lifetime_start(int a) {
+  int *p = 0;
+label1:
+  if (p) {
+foo2(*p);
+return 0;
+  }
+
+  int i = 999;
+  if (a != 2) {
+p = 
+goto label1;
+  }
+  return -1;
+}
+
+// O2-LABEL: define i32 @dont_move_lifetime_start
+// O2: %i = alloca i32, align 4
+// O2: br label %[[DESTLABEL:[a-z0-9]+]]
+// O2: [[DESTLABEL]]:
+// O2: %[[BITCAST:[0-9]+]] = bitcast i32* %i to i8*
+// O2: call void @llvm.lifetime.start(i64 4, i8* %[[BITCAST]])
+// O2: switch i32 %{{.*}}, label %{{.*}} [
+// O2-NEXT: i32 0, label %{{.*}}
+// O2-NEXT: i32 2, label %[[DESTLABEL]]
+
+int dont_move_lifetime_start(int a) {
+  int *p = 0;
+label1:
+  {
+if (p) {
+  foo2(*p);
+  return 0;
+}
+
+int i = 999;
+if (a != 2) {
+  p = 
+  goto label1;
+}
+  }
+  return -1;
+}
Index: lib/CodeGen/LifetimeExtend.h
===
--- /dev/null
+++ lib/CodeGen/LifetimeExtend.h
@@ -0,0 +1,43 @@
+#ifndef LLVM_CLANG_LIB_CODEGEN_LIFETIMEEXTEND_H
+#define LLVM_CLANG_LIB_CODEGEN_LIFETIMEEXTEND_H
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/SmallVector.h"
+
+namespace clang {
+
+class CompoundStmt;
+class Stmt;
+class VarDecl;
+
+namespace CodeGen {
+class VarBypassDetector;
+
+class LifetimeExtend {
+public:
+  typedef llvm::SmallVector VarDeclList;
+  void init(Stmt *Body, const VarBypassDetector );
+  const VarDeclList *extendedLifetimeVarDecls(const CompoundStmt *CS) const;
+  bool lifetimeExtendedOrDisabled(const VarDecl *VD) const;
+
+  void addExtendedOrDisabledLifetime(const VarDecl *VD) {
+ExtendedOrDisabledLifetimes.insert(VD);
+  }
+
+  void addExtendedLifetime(const CompoundStmt *CS, const VarDecl *VD) {
+ExtendedLifetimes[CS].push_back(VD);
+  }
+
+private:
+  // Lifetimes for these VarDecls are either extended or disabled.
+  llvm::SmallSet ExtendedOrDisabledLifetimes;
+
+  // These are the VarDecls whose lifetimes are emitted at the beginning of the
+  // compound statements with which they are associated.
+  llvm::DenseMap ExtendedLifetimes;
+};
+
+}
+}
+
+#endif
Index: lib/CodeGen/LifetimeExtend.cpp
===
--- /dev/null
+++ 

[PATCH] D26267: [Modules] Include builtins with #include instead of #import for ObjC

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added a comment.

@rsmith ping!


https://reviews.llvm.org/D26267



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

[PATCH] D28427: Allow constexpr construction of subobjects unconditionally, not just in C++14.

[Richard Smith via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D28427



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

[PATCH] D28478: Check for musl-libc's max_align_t in addition to other variants.

[David L. Jones via Phabricator via cfe-commits]

dlj created this revision.
dlj added a reviewer: mclow.lists.
dlj added a subscriber: cfe-commits.

Libcxx will define its own max_align_t when it is not available. However, the
availability checks today only check for Clang's definition and GCC's
definition. In particular, it does not check for musl's definition, which is the
same as GCC's but guarded with a different macro.


https://reviews.llvm.org/D28478

Files:
  include/cstddef
  include/stddef.h


Index: include/stddef.h
===
--- include/stddef.h
+++ include/stddef.h
@@ -53,7 +53,8 @@
 }
 
 // Re-use the compiler's  max_align_t where possible.
-#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T)
+#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T) && \
+!defined(__DEFINED_max_align_t)
 typedef long double max_align_t;
 #endif
 
Index: include/cstddef
===
--- include/cstddef
+++ include/cstddef
@@ -48,7 +48,8 @@
 using ::ptrdiff_t;
 using ::size_t;
 
-#if defined(__CLANG_MAX_ALIGN_T_DEFINED) || defined(_GCC_MAX_ALIGN_T)
+#if defined(__CLANG_MAX_ALIGN_T_DEFINED) || defined(_GCC_MAX_ALIGN_T) || \
+defined(__DEFINED_max_align_t)
 // Re-use the compiler's  max_align_t where possible.
 using ::max_align_t;
 #else


Index: include/stddef.h
===
--- include/stddef.h
+++ include/stddef.h
@@ -53,7 +53,8 @@
 }
 
 // Re-use the compiler's  max_align_t where possible.
-#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T)
+#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T) && \
+!defined(__DEFINED_max_align_t)
 typedef long double max_align_t;
 #endif
 
Index: include/cstddef
===
--- include/cstddef
+++ include/cstddef
@@ -48,7 +48,8 @@
 using ::ptrdiff_t;
 using ::size_t;
 
-#if defined(__CLANG_MAX_ALIGN_T_DEFINED) || defined(_GCC_MAX_ALIGN_T)
+#if defined(__CLANG_MAX_ALIGN_T_DEFINED) || defined(_GCC_MAX_ALIGN_T) || \
+defined(__DEFINED_max_align_t)
 // Re-use the compiler's  max_align_t where possible.
 using ::max_align_t;
 #else
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D21279: Fix some issues in clang-format's AlignConsecutive modes

[Beren Minor via Phabricator via cfe-commits]

berenm added a comment.

Pinging @djasper

There's https://reviews.llvm.org/D27651 that will conflict with this one.


https://reviews.llvm.org/D21279



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

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and to the right

[Beren Minor via Phabricator via cfe-commits]

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

Awesome!

Pinging @djasper


https://reviews.llvm.org/D27651



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

[PATCH] D28238: [Driver] Add openSuse AArch64 Triple

[Renato Golin via Phabricator via cfe-commits]

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

Sounds good. Thanks!


https://reviews.llvm.org/D28238



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

r291477 - [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

[Michal Gorny via cfe-commits]

Author: mgorny
Date: Mon Jan  9 14:54:20 2017
New Revision: 291477

URL: http://llvm.org/viewvc/llvm-project?rev=291477=rev
Log:
[Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume all those
types are aligned correctly by default since clang uses safe alignment
for _Atomic types even if the underlying types are aligned to a lower
boundary by default.

For example, the 'long long' and 'double' types on x86 are aligned to
32-bit boundary by default. However, '_Atomic long long' and '_Atomic
double' are aligned to 64-bit boundary, therefore satisfying
the requirements of lock-free atomic operations.

This fixes PR #19355 by correcting the value of
__GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing
the assumption made in libc++ tests. This also fixes PR #30581 by
applying a consistent logic between the functions used to implement
both interfaces.

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

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp
cfe/trunk/test/Sema/atomic-ops.c

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=291477=291476=291477=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Mon Jan  9 14:54:20 2017
@@ -286,12 +286,12 @@ static void DefineFastIntType(unsigned T
 
 /// Get the value the ATOMIC_*_LOCK_FREE macro should have for a type with
 /// the specified properties.
-static const char *getLockFreeValue(unsigned TypeWidth, unsigned TypeAlign,
-unsigned InlineWidth) {
+static const char *getLockFreeValue(unsigned TypeWidth, unsigned InlineWidth) {
   // Fully-aligned, power-of-2 sizes no larger than the inline
   // width will be inlined as lock-free operations.
-  if (TypeWidth == TypeAlign && (TypeWidth & (TypeWidth - 1)) == 0 &&
-  TypeWidth <= InlineWidth)
+  // Note: we do not need to check alignment since _Atomic(T) is always
+  // appropriately-aligned in clang.
+  if ((TypeWidth & (TypeWidth - 1)) == 0 && TypeWidth <= InlineWidth)
 return "2"; // "always lock free"
   // We cannot be certain what operations the lib calls might be
   // able to implement as lock-free on future processors.
@@ -881,7 +881,6 @@ static void InitializePredefinedMacros(c
 #define DEFINE_LOCK_FREE_MACRO(TYPE, Type) \
 Builder.defineMacro("__GCC_ATOMIC_" #TYPE "_LOCK_FREE", \
 getLockFreeValue(TI.get##Type##Width(), \
- TI.get##Type##Align(), \
  InlineWidthBits));
 DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
 DEFINE_LOCK_FREE_MACRO(CHAR, Char);
@@ -894,7 +893,6 @@ static void InitializePredefinedMacros(c
 DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
 Builder.defineMacro("__GCC_ATOMIC_POINTER_LOCK_FREE",
 getLockFreeValue(TI.getPointerWidth(0),
- TI.getPointerAlign(0),
  InlineWidthBits));
 #undef DEFINE_LOCK_FREE_MACRO
   }

Modified: cfe/trunk/test/Sema/atomic-ops.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/atomic-ops.c?rev=291477=291476=291477=diff
==
--- cfe/trunk/test/Sema/atomic-ops.c (original)
+++ cfe/trunk/test/Sema/atomic-ops.c Mon Jan  9 14:54:20 2017
@@ -14,11 +14,7 @@ _Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
-#ifdef __i386__
-_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
-#else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
-#endif
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");


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

[PATCH] D28213: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

[Michał Górny via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291477: [Frontend] Correct values of ATOMIC_*_LOCK_FREE to 
match builtin (authored by mgorny).

Changed prior to commit:
  https://reviews.llvm.org/D28213?vs=82791=83677#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28213

Files:
  cfe/trunk/lib/Frontend/InitPreprocessor.cpp
  cfe/trunk/test/Sema/atomic-ops.c


Index: cfe/trunk/test/Sema/atomic-ops.c
===
--- cfe/trunk/test/Sema/atomic-ops.c
+++ cfe/trunk/test/Sema/atomic-ops.c
@@ -14,11 +14,7 @@
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
-#ifdef __i386__
-_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
-#else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
-#endif
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");
Index: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
===
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp
@@ -286,12 +286,12 @@
 
 /// Get the value the ATOMIC_*_LOCK_FREE macro should have for a type with
 /// the specified properties.
-static const char *getLockFreeValue(unsigned TypeWidth, unsigned TypeAlign,
-unsigned InlineWidth) {
+static const char *getLockFreeValue(unsigned TypeWidth, unsigned InlineWidth) {
   // Fully-aligned, power-of-2 sizes no larger than the inline
   // width will be inlined as lock-free operations.
-  if (TypeWidth == TypeAlign && (TypeWidth & (TypeWidth - 1)) == 0 &&
-  TypeWidth <= InlineWidth)
+  // Note: we do not need to check alignment since _Atomic(T) is always
+  // appropriately-aligned in clang.
+  if ((TypeWidth & (TypeWidth - 1)) == 0 && TypeWidth <= InlineWidth)
 return "2"; // "always lock free"
   // We cannot be certain what operations the lib calls might be
   // able to implement as lock-free on future processors.
@@ -881,7 +881,6 @@
 #define DEFINE_LOCK_FREE_MACRO(TYPE, Type) \
 Builder.defineMacro("__GCC_ATOMIC_" #TYPE "_LOCK_FREE", \
 getLockFreeValue(TI.get##Type##Width(), \
- TI.get##Type##Align(), \
  InlineWidthBits));
 DEFINE_LOCK_FREE_MACRO(BOOL, Bool);
 DEFINE_LOCK_FREE_MACRO(CHAR, Char);
@@ -894,7 +893,6 @@
 DEFINE_LOCK_FREE_MACRO(LLONG, LongLong);
 Builder.defineMacro("__GCC_ATOMIC_POINTER_LOCK_FREE",
 getLockFreeValue(TI.getPointerWidth(0),
- TI.getPointerAlign(0),
  InlineWidthBits));
 #undef DEFINE_LOCK_FREE_MACRO
   }


Index: cfe/trunk/test/Sema/atomic-ops.c
===
--- cfe/trunk/test/Sema/atomic-ops.c
+++ cfe/trunk/test/Sema/atomic-ops.c
@@ -14,11 +14,7 @@
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
-#ifdef __i386__
-_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
-#else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
-#endif
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");
Index: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
===
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp
@@ -286,12 +286,12 @@
 
 /// Get the value the ATOMIC_*_LOCK_FREE macro should have for a type with
 /// the specified properties.
-static const char *getLockFreeValue(unsigned TypeWidth, unsigned TypeAlign,
-unsigned InlineWidth) {
+static const char *getLockFreeValue(unsigned TypeWidth, unsigned InlineWidth) {
   // Fully-aligned, power-of-2 sizes no larger than the inline
   // width will be inlined as lock-free operations.
-  if (TypeWidth == TypeAlign && (TypeWidth & (TypeWidth - 1)) == 0 &&
-  TypeWidth <= InlineWidth)
+  // Note: we do not need to check alignment since _Atomic(T) is always
+  // appropriately-aligned in clang.
+  if ((TypeWidth & (TypeWidth - 1)) == 0 && TypeWidth <= InlineWidth)
 return "2"; // "always lock free"
   // We cannot be certain what operations the lib calls might be
   // able to implement as lock-free on future processors.
@@ -881,7 +881,6 @@
 #define DEFINE_LOCK_FREE_MACRO(TYPE, Type) \
 Builder.defineMacro("__GCC_ATOMIC_" #TYPE "_LOCK_FREE", \
 getLockFreeValue(TI.get##Type##Width(), \
- TI.get##Type##Align(), \
  

Re: r291416 - [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing lambda expressions.

[Richard Smith via cfe-commits]

On 9 January 2017 at 03:44, Faisal Vali  wrote:

> On Mon, Jan 9, 2017 at 12:13 AM, Richard Smith 
> wrote:
> > On 8 January 2017 at 19:02, Faisal Vali via cfe-commits
> >  wrote:
> >>
> >> Author: faisalv
> >> Date: Sun Jan  8 21:02:53 2017
> >> New Revision: 291416
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=291416=rev
> >> Log:
> >> [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing
> >> lambda expressions.
> >>
> >> Add a visitor for lambda expressions to RecordExprEvaluator in
> >> ExprConstant.cpp that creates an empty APValue of Struct type to
> represent
> >> the closure object. Additionally, add a LambdaExpr visitor to the
> >> TemporaryExprEvaluator that forwards constant evaluation of
> >> immediately-called-lambda-expressions to the one in RecordExprEvaluator
> >> through VisitConstructExpr.
> >>
> >> This patch supports:
> >> constexpr auto ID = [] (auto a) { return a; };
> >> static_assert(ID(3.14) == 3.14);
> >> static_assert([](auto a) { return a + 1; }(10) == 11);
> >>
> >> Lambda captures are still not supported for constexpr lambdas.
> >>
> >>
> >> Modified:
> >> cfe/trunk/lib/AST/ExprConstant.cpp
> >> cfe/trunk/lib/Sema/SemaExpr.cpp
> >> cfe/trunk/test/SemaCXX/cxx1z-constexpr-lambdas.cpp
> >>
> >> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/
> ExprConstant.cpp?rev=291416=291415=291416=diff
> >>
> >> 
> ==
> >> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
> >> +++ cfe/trunk/lib/AST/ExprConstant.cpp Sun Jan  8 21:02:53 2017
> >> @@ -5868,6 +5868,7 @@ namespace {
> >>  bool VisitCXXConstructExpr(const CXXConstructExpr *E) {
> >>return VisitCXXConstructExpr(E, E->getType());
> >>  }
> >> +bool VisitLambdaExpr(const LambdaExpr *E);
> >>  bool VisitCXXInheritedCtorInitExpr(const CXXInheritedCtorInitExpr
> >> *E);
> >>  bool VisitCXXConstructExpr(const CXXConstructExpr *E, QualType T);
> >>  bool VisitCXXStdInitializerListExpr(const
> CXXStdInitializerListExpr
> >> *E);
> >> @@ -6202,6 +6203,21 @@ bool RecordExprEvaluator::VisitCXXStdIni
> >>return true;
> >>  }
> >>
> >> +bool RecordExprEvaluator::VisitLambdaExpr(const LambdaExpr *E) {
> >> +  const CXXRecordDecl *ClosureClass = E->getLambdaClass();
> >> +  if (ClosureClass->isInvalidDecl()) return false;
> >> +
> >> +  if (Info.checkingPotentialConstantExpression()) return true;
> >> +  if (E->capture_size()) {
> >> +Info.FFDiag(E, diag::note_unimplemented_
> constexpr_lambda_feature_ast)
> >> +<< "can not evaluate lambda expressions with captures";
> >> +return false;
> >> +  }
> >> +  // FIXME: Implement captures.
> >> +  Result = APValue(APValue::UninitStruct(), /*NumBases*/0,
> >> /*NumFields*/0);
> >> +  return true;
> >> +}
> >> +
> >>  static bool EvaluateRecord(const Expr *E, const LValue ,
> >> APValue , EvalInfo ) {
> >>assert(E->isRValue() && E->getType()->isRecordType() &&
> >> @@ -6251,6 +6267,9 @@ public:
> >>bool VisitCXXStdInitializerListExpr(const CXXStdInitializerListExpr
> *E)
> >> {
> >>  return VisitConstructExpr(E);
> >>}
> >> +  bool VisitLambdaExpr(const LambdaExpr *E) {
> >> +return VisitConstructExpr(E);
> >> +  }
> >>  };
> >>  } // end anonymous namespace
> >>
> >>
> >> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> >> URL:
> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaExpr.cpp?rev=291416=291415=291416=diff
> >>
> >> 
> ==
> >> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> >> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Sun Jan  8 21:02:53 2017
> >> @@ -13097,8 +13097,10 @@ void Sema::PopExpressionEvaluationContex
> >>  //   evaluate [...] a lambda-expression.
> >>  D = diag::err_lambda_in_constant_expression;
> >>}
> >> -  for (const auto *L : Rec.Lambdas)
> >> -Diag(L->getLocStart(), D);
> >> +  // C++1z allows lambda expressions as core constant expressions.
> >> +  if (Rec.Context != ConstantEvaluated ||
> !getLangOpts().CPlusPlus1z)
> >> +for (const auto *L : Rec.Lambdas)
> >> +  Diag(L->getLocStart(), D);
> >
> >
> > We'll need an implementation of DR1607 before we're done here, since it
> > looks like this has removed the last restriction on lambda-expressions in
> > function template signatures in some contexts (array bounds, template
> > arguments).
> >
>
> Yes - I'll add those restrictions back (I suppose we'll need to check
> whether the nearest enclosing non-lambda context is a valid one [while
> still allowing them in default function arguments]) - but then we'll
> need to relax some of them when we implement P0315 in post-C++-17
> right?
>
> For e.g. these would be ok w P0315 right?
>
> template 

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#640178, @mehdi_amini wrote:

> Also, that's not practicable: what if I have an LTO static library for which 
> I don't have the source, now if I build my own file with -O0 -flto I can't 
> link anymore.


Also: LTO is required for some features likes CFI. There are users who wants 
CFI+O0 during development (possibly for debugging a subcomponent of the app).


https://reviews.llvm.org/D28404



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#640170, @probinson wrote:

> In https://reviews.llvm.org/D28404#640090, @mehdi_amini wrote:
>
> > In https://reviews.llvm.org/D28404#640046, @probinson wrote:
> >
> > > "I don't care" doesn't seem like much of a principle.
> >
> >
> > Long version is: "There is no use-case, no users, so I don't have much 
> > motivation to push it forward for the only sake of completeness". Does it 
> > sound enough of a principle like that?
>
>
> No.  You still need to have adequate justification for your use case, which I 
> think you do not.


I don't follow your logic. 
IIUC, you asked about "why not supporting `O1/O2/O3`" ; how is *not supporting* 
these because their not useful / don't have use-case related to "supporting 
`O0` is useful"?

> 
> 
>>> Optnone does not equal -O0.  It is a debugging aid for the programmer, 
>>> because debugging optimized code sucks.  If you have an LTO-built 
>>> application and want to de-optimize parts of it to aid with debugging, then 
>>> you can use the pragma, as originally intended.
>> 
>> Having to modifying the source isn't friendly. Not being able to honor -O0 
>> during LTO is not user-friendly.
> 
> IMO, '-O0' and '-flto' are conflicting options and therefore not deserving of 
> special support.

You're advocating for *rejecting* O0 built module at link-time? We'd still need 
to detect this though. Status-quo isn't acceptable.

Also, that's not practicable: what if I have an LTO static library for which I 
don't have the source, now if I build my own file with -O0 -flto I can't link 
anymore.

> In my experience, modifying source is by far simpler than hacking a build 
> system to make a special case for compiler options for one module in an 
> application.  (If you have a way to build Clang with everything done LTO 
> except one module built with -O0, on Linux with ninja, I would be very 
> curious to hear how you do that.)

Static library, separated projects, etc.
We have tons of users...

>>>   I don't think `-c -O0` should get this not-entirely-O0-like behavior.
>> 
>> What is "not-entirely"? And why do you think that?
> 
> "Not entirely" means that running the -O0 pipeline, and running an 
> optimization pipeline but asking some subset of passes to turn themselves 
> off, does not get you the same result.  And I think that because I'm the one 
> who put 'optnone' upstream in the first place.  The case that particularly 
> sticks in my memory is the register allocator, but I believe there are passes 
> at every stage that do not turn themselves off for optnone.

That's orthogonal: you're saying we are not handling it correctly yet, I'm just 
moving toward *fixing* all these.


https://reviews.llvm.org/D28404



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

[PATCH] D27651: [clang-format] Even with AlignConsecutiveDeclarations, PointerAlignment: Right should keep *s and to the right

[Ken-Patrick Lehrmann via Phabricator via cfe-commits]

KP updated this revision to Diff 83676.
KP added a comment.

Thanks for the review!
Split declarations in test cases with PAS_Middle/PAS_Left.
Add tests with references and rvalue references.


https://reviews.llvm.org/D27651

Files:
  lib/Format/WhitespaceManager.cpp
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -8769,9 +8769,11 @@
   verifyFormat("int  oneTwoThree = {0}; // comment\n"
"unsigned oneTwo  = 0;   // comment",
Alignment);
+
+  // PAS_RIGHT
   EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
 "  int const i   = 1;\n"
-"  int * j   = 2;\n"
+"  int  *j   = 2;\n"
 "  int   big = 1;\n"
 "\n"
 "  unsigned oneTwoThree = 123;\n"
@@ -8792,6 +8794,141 @@
"int ll=1;\n"
"}",
Alignment));
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int **j   = 2, ***k;\n"
+"  int = i;\n"
+"  int &   = i + j;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int **j=2,***k;\n"
+   "int =i;\n"
+   "int &=i+j;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   Alignment));
+
+  // PAS_LEFT
+  FormatStyle AlignmentLeft = Alignment;
+  AlignmentLeft.PointerAlignment = FormatStyle::PAS_Left;
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int*  j   = 2;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int *j=2;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   AlignmentLeft));
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int** j   = 2;\n"
+"  int&  k   = i;\n"
+"  int&& l   = i + j;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int **j=2;\n"
+   "int =i;\n"
+   "int &=i+j;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   "float k= 2;\n"
+   "int ll=1;\n"
+   "}",
+   AlignmentLeft));
+  // PAS_MIDDLE
+  FormatStyle AlignmentMiddle = Alignment;
+  AlignmentMiddle.PointerAlignment = FormatStyle::PAS_Middle;
+  EXPECT_EQ("void SomeFunction(int parameter = 0) {\n"
+"  int const i   = 1;\n"
+"  int * j   = 2;\n"
+"  int   big = 1;\n"
+"\n"
+"  unsigned oneTwoThree = 123;\n"
+"  int  oneTwo  = 12;\n"
+"  method();\n"
+"  float k  = 2;\n"
+"  int   ll = 1;\n"
+"}",
+format("void SomeFunction(int parameter= 0) {\n"
+   " int const  i= 1;\n"
+   "  int *j=2;\n"
+   " int big  =  1;\n"
+   "\n"
+   "unsigned oneTwoThree  =123;\n"
+   "int oneTwo = 12;\n"
+   "  method();\n"
+   

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640170, @probinson wrote:

> In my experience, modifying source


Note that the source modification consists of adding `#pragma clang optimize 
off` to the top of the file.  It is not a complicated thing.


https://reviews.llvm.org/D28404



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

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

In https://reviews.llvm.org/D28404#640090, @mehdi_amini wrote:

> In https://reviews.llvm.org/D28404#640046, @probinson wrote:
>
> > "I don't care" doesn't seem like much of a principle.
>
>
> Long version is: "There is no use-case, no users, so I don't have much 
> motivation to push it forward for the only sake of completeness". Does it 
> sound enough of a principle like that?


No.  You still need to have adequate justification for your use case, which I 
think you do not.

>> Optnone does not equal -O0.  It is a debugging aid for the programmer, 
>> because debugging optimized code sucks.  If you have an LTO-built 
>> application and want to de-optimize parts of it to aid with debugging, then 
>> you can use the pragma, as originally intended.
> 
> Having to modifying the source isn't friendly. Not being able to honor -O0 
> during LTO is not user-friendly.

IMO, '-O0' and '-flto' are conflicting options and therefore not deserving of 
special support.

In my experience, modifying source is by far simpler than hacking a build 
system to make a special case for compiler options for one module in an 
application.  (If you have a way to build Clang with everything done LTO except 
one module built with -O0, on Linux with ninja, I would be very curious to hear 
how you do that.)  But if your build system makes that easy, you can just as 
easily remove `-flto` as add `-O0` and thus get the result you want without 
trying to pass conflicting options to the compiler.  Or spending time 
implementing this patch.

>>   I don't think `-c -O0` should get this not-entirely-O0-like behavior.
> 
> What is "not-entirely"? And why do you think that?

"Not entirely" means that running the -O0 pipeline, and running an optimization 
pipeline but asking some subset of passes to turn themselves off, does not get 
you the same result.  And I think that because I'm the one who put 'optnone' 
upstream in the first place.  The case that particularly sticks in my memory is 
the register allocator, but I believe there are passes at every stage that do 
not turn themselves off for optnone.


https://reviews.llvm.org/D28404



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

[PATCH] D27800: Add overload of TransformToPotentiallyEvaluated for TypeSourceInfo

[Eli Friedman via Phabricator via cfe-commits]

efriedma requested changes to this revision.
efriedma added a comment.
This revision now requires changes to proceed.

Missing regression test in test/SemaCXX/.


https://reviews.llvm.org/D27800



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

[PATCH] D28477: Add LF_ prefix to LibFunc enums in TargetLibraryInfo.

[David L. Jones via Phabricator via cfe-commits]

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

The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).

Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via ). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.

The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LF_". (Unfortunately, a scoped enum is not sufficient to override macros.)

These changes are for clang. See https://reviews.llvm.org/D28476 for LLVM.


https://reviews.llvm.org/D28477

Files:
  lib/CodeGen/BackendUtil.cpp


Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -262,7 +262,7 @@
 TLII->disableAllFunctions();
   else {
 // Disable individual libc/libm calls in TargetLibraryInfo.
-LibFunc::Func F;
+LibFunc F;
 for (auto  : CodeGenOpts.getNoBuiltinFuncs())
   if (TLII->getLibFunc(FuncName, F))
 TLII->setUnavailable(F);


Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -262,7 +262,7 @@
 TLII->disableAllFunctions();
   else {
 // Disable individual libc/libm calls in TargetLibraryInfo.
-LibFunc::Func F;
+LibFunc F;
 for (auto  : CodeGenOpts.getNoBuiltinFuncs())
   if (TLII->getLibFunc(FuncName, F))
 TLII->setUnavailable(F);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28472: Move _PairT declaration out of __hash_combine to avoid warning under C++98

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL291476: Move _PairT declaration out of __hash_combine to 
avoid warning under C++98 (authored by dim).

Changed prior to commit:
  https://reviews.llvm.org/D28472?vs=83654=83672#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28472

Files:
  libcxx/trunk/include/memory


Index: libcxx/trunk/include/memory
===
--- libcxx/trunk/include/memory
+++ libcxx/trunk/include/memory
@@ -3344,12 +3344,13 @@
 }
 };
 
+struct _PairT {
+  size_t first;
+  size_t second;
+};
+
 _LIBCPP_INLINE_VISIBILITY
 inline size_t __hash_combine(size_t __lhs, size_t __rhs) _NOEXCEPT {
-struct _PairT {
-  size_t first;
-  size_t second;
-};
 typedef __scalar_hash<_PairT> _HashT;
 const _PairT __p = {__lhs, __rhs};
 return _HashT()(__p);


Index: libcxx/trunk/include/memory
===
--- libcxx/trunk/include/memory
+++ libcxx/trunk/include/memory
@@ -3344,12 +3344,13 @@
 }
 };
 
+struct _PairT {
+  size_t first;
+  size_t second;
+};
+
 _LIBCPP_INLINE_VISIBILITY
 inline size_t __hash_combine(size_t __lhs, size_t __rhs) _NOEXCEPT {
-struct _PairT {
-  size_t first;
-  size_t second;
-};
 typedef __scalar_hash<_PairT> _HashT;
 const _PairT __p = {__lhs, __rhs};
 return _HashT()(__p);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r291476 - Move _PairT declaration out of __hash_combine to avoid warning under C++98

[Dimitry Andric via cfe-commits]

Author: dim
Date: Mon Jan  9 14:29:35 2017
New Revision: 291476

URL: http://llvm.org/viewvc/llvm-project?rev=291476=rev
Log:
Move _PairT declaration out of __hash_combine to avoid warning under C++98

Summary:
Some parts of the FreeBSD tree are still compiled with C++98, and until
rL288554 this has always worked fine.  After that, a complaint about the
newly introduced local _PairT is produced:

/usr/include/c++/v1/memory:3354:27: error: template argument uses local 
type '_PairT' [-Werror,-Wlocal-type-template-args]
typedef __scalar_hash<_PairT> _HashT;
  ^~
/usr/include/c++/v1/memory:3284:29: error: template argument uses local 
type '_PairT' [-Werror,-Wlocal-type-template-args]
: public unary_function<_Tp, size_t>
^~~
/usr/include/c++/v1/memory:3356:12: note: in instantiation of template 
class 'std::__1::__scalar_hash<_PairT, 2>' requested here
return _HashT()(__p);
   ^

As far as I can see, there should be no problem moving the _PairT
struct to just before the __hash_combine() function, which fixes this
particular warning.

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits, emaste

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

Modified:
libcxx/trunk/include/memory

Modified: libcxx/trunk/include/memory
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/memory?rev=291476=291475=291476=diff
==
--- libcxx/trunk/include/memory (original)
+++ libcxx/trunk/include/memory Mon Jan  9 14:29:35 2017
@@ -3344,12 +3344,13 @@ struct __scalar_hash<_Tp, 4>
 }
 };
 
+struct _PairT {
+  size_t first;
+  size_t second;
+};
+
 _LIBCPP_INLINE_VISIBILITY
 inline size_t __hash_combine(size_t __lhs, size_t __rhs) _NOEXCEPT {
-struct _PairT {
-  size_t first;
-  size_t second;
-};
 typedef __scalar_hash<_PairT> _HashT;
 const _PairT __p = {__lhs, __rhs};
 return _HashT()(__p);


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

[libcxx] r291475 - Added XFAIL for the apple versions of clang as well

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon Jan  9 14:29:28 2017
New Revision: 291475

URL: http://llvm.org/viewvc/llvm-project?rev=291475=rev
Log:
Added XFAIL for the apple versions of clang as well

Modified:

libcxx/trunk/test/std/strings/string.view/string_view.literals/literal.pass.cpp

libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.fail.cpp

libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.pass.cpp

libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.fail.cpp

libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.pass.cpp

libcxx/trunk/test/std/strings/string.view/string_view.literals/literal3.pass.cpp

Modified: 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string_view.literals/literal.pass.cpp?rev=291475=291474=291475=diff
==
--- 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal.pass.cpp 
Mon Jan  9 14:29:28 2017
@@ -10,6 +10,7 @@
 
 // UNSUPPORTED: c++98, c++03, c++11
 // UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5, clang-3.6, clang-3.7, 
clang-3.8, clang-3.9
+// UNSUPPORTED: apple-clang-6, apple-clang-7, apple-clang-8
 // Note: libc++ supports string_view before C++17, but literals were 
introduced in C++14
 
 #include 

Modified: 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.fail.cpp?rev=291475=291474=291475=diff
==
--- 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.fail.cpp
 Mon Jan  9 14:29:28 2017
@@ -10,6 +10,7 @@
 
 // UNSUPPORTED: c++98, c++03, c++11
 // UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5, clang-3.6, clang-3.7, 
clang-3.8, clang-3.9
+// UNSUPPORTED: apple-clang-6, apple-clang-7, apple-clang-8
 
 #include 
 #include 

Modified: 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.pass.cpp?rev=291475=291474=291475=diff
==
--- 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal1.pass.cpp
 Mon Jan  9 14:29:28 2017
@@ -10,6 +10,7 @@
 
 // UNSUPPORTED: c++98, c++03, c++11
 // UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5, clang-3.6, clang-3.7, 
clang-3.8, clang-3.9
+// UNSUPPORTED: apple-clang-6, apple-clang-7, apple-clang-8
 // Note: libc++ supports string_view before C++17, but literals were 
introduced in C++14
 
 #include 

Modified: 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.fail.cpp?rev=291475=291474=291475=diff
==
--- 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.fail.cpp
 (original)
+++ 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.fail.cpp
 Mon Jan  9 14:29:28 2017
@@ -10,6 +10,7 @@
 
 // UNSUPPORTED: c++98, c++03, c++11
 // UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5, clang-3.6, clang-3.7, 
clang-3.8, clang-3.9
+// UNSUPPORTED: apple-clang-6, apple-clang-7, apple-clang-8
 
 #include 
 #include 

Modified: 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.pass.cpp?rev=291475=291474=291475=diff
==
--- 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal2.pass.cpp
 Mon Jan  9 14:29:28 2017
@@ -10,6 +10,7 @@
 
 // UNSUPPORTED: c++98, c++03, c++11
 // UNSUPPORTED: clang-3.3, clang-3.4, clang-3.5, clang-3.6, clang-3.7, 
clang-3.8, clang-3.9
+// UNSUPPORTED: apple-clang-6, apple-clang-7, apple-clang-8
 // Note: libc++ supports string_view before C++17, but literals were 
introduced in C++14
 
 #include 

Modified: 
libcxx/trunk/test/std/strings/string.view/string_view.literals/literal3.pass.cpp
URL: 

[PATCH] D28445: [Analyzer] Extend taint propagation and checking

[Anna Zaks via Phabricator via cfe-commits]

zaks.anna added a comment.

Thanks for working on this!




Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:443
+  if (auto LCV = Val.getAs())
+return C.getSymbolManager().getRegionValueSymbol(LCV->getRegion());
+

This might create a new symbol. Is this what we want?



Comment at: lib/StaticAnalyzer/Core/ProgramState.cpp:694
+  if (const TypedValueRegion *TVR = dyn_cast(Reg)) {
+SymbolRef Sym = getSymbolManager().getRegionValueSymbol(TVR);
+

This might create a new symbol as well. Is this what we want here?



https://reviews.llvm.org/D28445



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

[PATCH] D28018: AMD family 17h (znver1) enablement

[Ganesh Gopalasubramanian via Phabricator via cfe-commits]

GGanesh added a comment.

If Okay, can you please commit these on my behalf. I don't have write access.


https://reviews.llvm.org/D28018



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

[PATCH] D28018: AMD family 17h (znver1) enablement

[Ganesh Gopalasubramanian via Phabricator via cfe-commits]

GGanesh added a comment.

Yes. True I mentioned that for the grouping or the order of the features 
enabled. These initFeatureMap are done based on the intrinsics and the CodeGen 
part.


https://reviews.llvm.org/D28018



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

r291458 - [Lit Test] Make tests C++11 compatible - nothrow destructors

[Charles Li via cfe-commits]

Author: lcharles
Date: Mon Jan  9 12:24:16 2017
New Revision: 291458

URL: http://llvm.org/viewvc/llvm-project?rev=291458=rev
Log:
[Lit Test] Make tests C++11 compatible - nothrow destructors

In C++11, a destructor's implicit exception-spec is nothrow.
The IR for the destructor's invocation changed from invoke to call.

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

Modified:
cfe/trunk/test/CodeGenCXX/arm.cpp
cfe/trunk/test/CodeGenCXX/debug-info-class.cpp
cfe/trunk/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp
cfe/trunk/test/CodeGenCXX/exceptions.cpp
cfe/trunk/test/CodeGenCXX/goto.cpp
cfe/trunk/test/OpenMP/atomic_codegen.cpp
cfe/trunk/test/OpenMP/threadprivate_codegen.cpp

Modified: cfe/trunk/test/CodeGenCXX/arm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/arm.cpp?rev=291458=291457=291458=diff
==
--- cfe/trunk/test/CodeGenCXX/arm.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/arm.cpp Mon Jan  9 12:24:16 2017
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 %s -triple=thumbv7-apple-ios6.0 -fno-use-cxa-atexit 
-target-abi apcs-gnu -emit-llvm -o - -fexceptions | FileCheck %s
+// RUN: %clang_cc1 %s -triple=thumbv7-apple-ios6.0 -fno-use-cxa-atexit 
-target-abi apcs-gnu -emit-llvm -std=gnu++98 -o - -fexceptions | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK98 %s
+// RUN: %clang_cc1 %s -triple=thumbv7-apple-ios6.0 -fno-use-cxa-atexit 
-target-abi apcs-gnu -emit-llvm -std=gnu++11 -o - -fexceptions | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK11 %s
 
 // CHECK: @_ZZN5test74testEvE1x = internal global i32 0, align 4
 // CHECK: @_ZGVZN5test74testEvE1x = internal global i32 0
@@ -156,7 +157,8 @@ namespace test3 {
 // CHECK: getelementptr {{.*}}, i32 4
 // CHECK: bitcast {{.*}} to i32*
 // CHECK: load
-// CHECK: invoke {{.*}} @_ZN5test31AD1Ev
+// CHECK98: invoke {{.*}} @_ZN5test31AD1Ev
+// CHECK11: call {{.*}} @_ZN5test31AD1Ev
 // CHECK: call void @_ZdaPv
 delete [] x;
   }
@@ -168,7 +170,8 @@ namespace test3 {
 // CHECK: getelementptr {{.*}}, i32 4
 // CHECK: bitcast {{.*}} to i32*
 // CHECK: load
-// CHECK: invoke {{.*}} @_ZN5test31AD1Ev
+// CHECK98: invoke {{.*}} @_ZN5test31AD1Ev
+// CHECK11: call {{.*}} @_ZN5test31AD1Ev
 // CHECK: call void @_ZdaPv
 delete [] x;
   }

Modified: cfe/trunk/test/CodeGenCXX/debug-info-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-class.cpp?rev=291458=291457=291458=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-class.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-class.cpp Mon Jan  9 12:24:16 2017
@@ -83,12 +83,17 @@ int main(int argc, char **argv) {
   return 0;
 }
 
-// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions %s -o - | FileCheck %s
-// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions %s -o - | FileCheck %s
-// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++98 %s -o - | FileCheck 
-check-prefix=CHECK98 %s
+// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions -std=c++98 %s -o - | FileCheck -check-prefix=CHECK98 %s
+// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++98 %s -o - | FileCheck 
-check-prefix=CHECK98 %s
+// RUN: %clang_cc1 -triple x86_64-unknown_unknown -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++11 %s -o - | FileCheck 
-check-prefix=CHECK11 %s
+// RUN: %clang_cc1 -triple i686-cygwin -emit-llvm -debug-info-kind=limited 
-fexceptions -std=c++11 %s -o - | FileCheck -check-prefix=CHECK11 %s
+// RUN: %clang_cc1 -triple armv7l-unknown-linux-gnueabihf -emit-llvm 
-debug-info-kind=limited -fexceptions -std=c++11 %s -o - | FileCheck 
-check-prefix=CHECK11 %s
+
+// CHECK98: invoke {{.+}} @_ZN1BD1Ev(%class.B* %b)
+// CHECK98-NEXT: unwind label %{{.+}}, !dbg ![[EXCEPTLOC:.*]]
+// CHECK11: call {{.+}} @_ZN1BD1Ev(%class.B* %b){{.*}}, !dbg ![[EXCEPTLOC:.*]]
 
-// CHECK: invoke {{.+}} @_ZN1BD1Ev(%class.B* %b)
-// CHECK-NEXT: unwind label %{{.+}}, !dbg ![[EXCEPTLOC:.*]]
 // CHECK: store i32 0, i32* %{{.+}}, !dbg ![[RETLOC:.*]]
 
 // CHECK: [[F:![0-9]*]] = !DICompositeType(tag: DW_TAG_structure_type, name: 
"F"

Modified: cfe/trunk/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp?rev=291458=291457=291458=diff
==
--- cfe/trunk/test/CodeGenCXX/eh-aggregate-copy-destroy.cpp (original)
+++ 

Patch for Bug 22877

[Arthur Eubanks via cfe-commits]

Hi,This is my first commit, please feel free to critique any of the code/new test since I'm not quite sure if this is in the correct format.The patch is for the bug https://llvm.org/bugs/show_bug.cgi?id=22877 regarding cleaning up default arguments in constructors while initializing an array.It doesn't break any old tests.Thanks,Arthur Eubanks

patch.diff
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28404: IRGen: Add optnone attribute on function during O0

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D28404#640046, @probinson wrote:

> In https://reviews.llvm.org/D28404#639887, @mehdi_amini wrote:
>
> > In https://reviews.llvm.org/D28404#639874, @probinson wrote:
> >
> > > Over the weekend I had a thought:  Why is -O0 so special here?  That is, 
> > > after going to all this trouble to propagate -O0 to LTO, how does this 
> > > generalize to propagating -O1 or any other specific -O option?  (Maybe 
> > > this question would be better dealt with on the dev list...)
> >
> >
> > O0 is "special" like Os and Oz because we have an attribute for it and 
> > passes "know" how to handle this attribute.
> >  I guess no-one cares enough about 
> > https://reviews.llvm.org/owners/package/1//https://reviews.llvm.org/owners/package/2//O3
> >  to find a solution for these (in the context of LTO, I don't really care 
> > about 
> > https://reviews.llvm.org/owners/package/1//https://reviews.llvm.org/owners/package/2/).
> >  It is likely that Og would need a special treatment at some point, maybe 
> > with a new attribute as well, to inhibit optimization that can't preserve 
> > debug info properly.
>
>
> "I don't care" doesn't seem like much of a principle.


Long version is: "There is no use-case, no users, so I don't have much 
motivation to push it forward for the only sake of completeness". Does it sound 
enough of a principle like that?

> Optnone does not equal -O0.  It is a debugging aid for the programmer, 
> because debugging optimized code sucks.  If you have an LTO-built application 
> and want to de-optimize parts of it to aid with debugging, then you can use 
> the pragma, as originally intended.

Having to modifying the source isn't friendly. Not being able to honor -O0 
during LTO is not user-friendly.

>   I don't think `-c -O0` should get this not-entirely-O0-like behavior.

What is "not-entirely"? And why do you think that?


https://reviews.llvm.org/D28404



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