[clang] 35e7b4f - [NFC] Fix argument types in doxygen comment

2022-04-26 Thread Warren Ristow via cfe-commits

Author: Warren Ristow
Date: 2022-04-26T16:30:55-07:00
New Revision: 35e7b4f82cfabc28ebc23558917440aece3f489f

URL: 
https://github.com/llvm/llvm-project/commit/35e7b4f82cfabc28ebc23558917440aece3f489f
DIFF: 
https://github.com/llvm/llvm-project/commit/35e7b4f82cfabc28ebc23558917440aece3f489f.diff

LOG: [NFC] Fix argument types in doxygen comment

The argument types for _mm_extract_epi16 and _mm_insert_epi16 were
incorrectly identified as '__m256i' instead of '__m128i'.  Introduced
by df08b3493869540bad5d4b040dae814e078b411d, and fixed here.

Added: 


Modified: 
clang/lib/Headers/emmintrin.h

Removed: 




diff  --git a/clang/lib/Headers/emmintrin.h b/clang/lib/Headers/emmintrin.h
index c1e2915b6cb27..a3f56e832b32d 100644
--- a/clang/lib/Headers/emmintrin.h
+++ b/clang/lib/Headers/emmintrin.h
@@ -4127,7 +4127,7 @@ static __inline__ __m128i __DEFAULT_FN_ATTRS 
_mm_packus_epi16(__m128i __a,
 /// \headerfile 
 ///
 /// \code
-/// __m128i _mm_extract_epi16(__m256i a, const int imm);
+/// __m128i _mm_extract_epi16(__m128i a, const int imm);
 /// \endcode
 ///
 /// This intrinsic corresponds to the  VPEXTRW / PEXTRW  instruction.
@@ -4159,7 +4159,7 @@ static __inline__ __m128i __DEFAULT_FN_ATTRS 
_mm_packus_epi16(__m128i __a,
 /// \headerfile 
 ///
 /// \code
-/// __m128i _mm_insert_epi16(__m256i a, int b, const int imm);
+/// __m128i _mm_insert_epi16(__m128i a, int b, const int imm);
 /// \endcode
 ///
 /// This intrinsic corresponds to the  VPINSRW / PINSRW  instruction.



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


[clang] df08b34 - [NFC] Cleanup miscellaneous header items

2022-04-26 Thread Warren Ristow via cfe-commits

Author: Warren Ristow
Date: 2022-04-26T14:36:49-07:00
New Revision: df08b3493869540bad5d4b040dae814e078b411d

URL: 
https://github.com/llvm/llvm-project/commit/df08b3493869540bad5d4b040dae814e078b411d
DIFF: 
https://github.com/llvm/llvm-project/commit/df08b3493869540bad5d4b040dae814e078b411d.diff

LOG: [NFC] Cleanup miscellaneous header items

- Explain the use of the _MM_SHUFFLE and _MM_SHUFFLE2 macros
- Update some doxygen parameter descriptions to match the implementations
- Add "see also" doxygen tags to some intrinsics
- Minor clang-format changes

Reviewers: RKSimon

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

Added: 


Modified: 
clang/lib/Headers/__wmmintrin_pclmul.h
clang/lib/Headers/avxintrin.h
clang/lib/Headers/bmiintrin.h
clang/lib/Headers/emmintrin.h
clang/lib/Headers/smmintrin.h
clang/lib/Headers/xmmintrin.h

Removed: 




diff  --git a/clang/lib/Headers/__wmmintrin_pclmul.h 
b/clang/lib/Headers/__wmmintrin_pclmul.h
index fef4b93dbb433..c9a6d50bdc89d 100644
--- a/clang/lib/Headers/__wmmintrin_pclmul.h
+++ b/clang/lib/Headers/__wmmintrin_pclmul.h
@@ -22,23 +22,23 @@
 /// \headerfile 
 ///
 /// \code
-/// __m128i _mm_clmulepi64_si128(__m128i __X, __m128i __Y, const int __I);
+/// __m128i _mm_clmulepi64_si128(__m128i X, __m128i Y, const int I);
 /// \endcode
 ///
 /// This intrinsic corresponds to the  VPCLMULQDQ  instruction.
 ///
-/// \param __X
+/// \param X
 ///A 128-bit vector of [2 x i64] containing one of the source operands.
-/// \param __Y
+/// \param Y
 ///A 128-bit vector of [2 x i64] containing one of the source operands.
-/// \param __I
+/// \param I
 ///An immediate value specifying which 64-bit values to select from the
-///operands. Bit 0 is used to select a value from operand \a __X, and bit
-///4 is used to select a value from operand \a __Y: \n
-///Bit[0]=0 indicates that bits[63:0] of operand \a __X are used. \n
-///Bit[0]=1 indicates that bits[127:64] of operand \a __X are used. \n
-///Bit[4]=0 indicates that bits[63:0] of operand \a __Y are used. \n
-///Bit[4]=1 indicates that bits[127:64] of operand \a __Y are used.
+///operands. Bit 0 is used to select a value from operand \a X, and bit
+///4 is used to select a value from operand \a Y: \n
+///Bit[0]=0 indicates that bits[63:0] of operand \a X are used. \n
+///Bit[0]=1 indicates that bits[127:64] of operand \a X are used. \n
+///Bit[4]=0 indicates that bits[63:0] of operand \a Y are used. \n
+///Bit[4]=1 indicates that bits[127:64] of operand \a Y are used.
 /// \returns The 128-bit integer vector containing the result of the carry-less
 ///multiplication of the selected 64-bit values.
 #define _mm_clmulepi64_si128(X, Y, I) \

diff  --git a/clang/lib/Headers/avxintrin.h b/clang/lib/Headers/avxintrin.h
index df2d1a2690d8e..a8f953c260c2a 100644
--- a/clang/lib/Headers/avxintrin.h
+++ b/clang/lib/Headers/avxintrin.h
@@ -1504,7 +1504,10 @@ _mm256_blendv_ps(__m256 __a, __m256 __b, __m256 __c)
 ///00: Bits [31:0] and [159:128] are copied from the selected operand. \n
 ///01: Bits [63:32] and [191:160] are copied from the selected operand. \n
 ///10: Bits [95:64] and [223:192] are copied from the selected operand. \n
-///11: Bits [127:96] and [255:224] are copied from the selected operand.
+///11: Bits [127:96] and [255:224] are copied from the selected operand. \n
+///Note: To generate a mask, you can use the \c _MM_SHUFFLE macro.
+///_MM_SHUFFLE(b6, b4, b2, b0) can create an 8-bit mask of the form
+///[b6, b4, b2, b0].
 /// \returns A 256-bit vector of [8 x float] containing the shuffled values.
 #define _mm256_shuffle_ps(a, b, mask) \
   ((__m256)__builtin_ia32_shufps256((__v8sf)(__m256)(a), \
@@ -1953,12 +1956,16 @@ _mm256_blendv_ps(__m256 __a, __m256 __b, __m256 __c)
 ///
 /// \headerfile 
 ///
+/// \code
+/// int _mm256_extract_epi32(__m256i X, const int N);
+/// \endcode
+///
 /// This intrinsic corresponds to the  VEXTRACTF128+COMPOSITE 
 ///   instruction.
 ///
-/// \param __a
+/// \param X
 ///A 256-bit vector of [8 x i32].
-/// \param __imm
+/// \param N
 ///An immediate integer operand with bits [2:0] determining which vector
 ///element is extracted and returned.
 /// \returns A 32-bit integer containing the extracted 32 bits of extended
@@ -1971,12 +1978,16 @@ _mm256_blendv_ps(__m256 __a, __m256 __b, __m256 __c)
 ///
 /// \headerfile 
 ///
+/// \code
+/// int _mm256_extract_epi16(__m256i X, const int N);
+/// \endcode
+///
 /// This intrinsic corresponds to the  VEXTRACTF128+COMPOSITE 
 ///   instruction.
 ///
-/// \param __a
+/// \param X
 ///A 256-bit integer vector of [16 x i16].
-/// \param __imm
+/// \param N
 ///An immediate integer operand with bits [3:0] determining which vector
 ///element is extracted and returned.
 /// \returns A 32-bit integer containing the 

[clang] 7fcd9e3 - [X86] Mark various pointer arguments in builtins as const

2019-12-19 Thread Warren Ristow via cfe-commits

Author: Warren Ristow
Date: 2019-12-19T11:42:11-08:00
New Revision: 7fcd9e3f70830a9c4bf631a602c2764180b5c3a8

URL: 
https://github.com/llvm/llvm-project/commit/7fcd9e3f70830a9c4bf631a602c2764180b5c3a8
DIFF: 
https://github.com/llvm/llvm-project/commit/7fcd9e3f70830a9c4bf631a602c2764180b5c3a8.diff

LOG: [X86] Mark various pointer arguments in builtins as const

Enabling `-Wcast-qual` identified many casts in various system headers
that were dropping the `const` qualifier.  Fixing those missing
qualifiers pointed out that a few of the definitions of the builtins
did not properly identify their arguments as `const` pointers.  This
commit fixes those builtin definitions, and the system header files
so that they no longer drop the qualifier.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsX86.def
clang/lib/Headers/avx512bwintrin.h
clang/lib/Headers/avx512fintrin.h
clang/lib/Headers/avx512vlbwintrin.h
clang/lib/Headers/avx512vlintrin.h
clang/lib/Headers/avxintrin.h
clang/lib/Headers/emmintrin.h
clang/lib/Headers/immintrin.h
clang/lib/Headers/mwaitxintrin.h
clang/lib/Headers/pmmintrin.h
clang/lib/Headers/xmmintrin.h
clang/test/Headers/x86-intrinsics-headers-clean.cpp
clang/test/Headers/x86intrin-2.c

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsX86.def 
b/clang/include/clang/Basic/BuiltinsX86.def
index 5ab9dc1c3ac3..d6aa46de02f9 100644
--- a/clang/include/clang/Basic/BuiltinsX86.def
+++ b/clang/include/clang/Basic/BuiltinsX86.def
@@ -365,7 +365,7 @@ TARGET_BUILTIN(__builtin_ia32_pmaddwd128, "V4iV8sV8s", 
"ncV:128:", "sse2")
 TARGET_BUILTIN(__builtin_ia32_pslldqi128_byteshift, "V2OiV2OiIi", "ncV:128:", 
"sse2")
 TARGET_BUILTIN(__builtin_ia32_psrldqi128_byteshift, "V2OiV2OiIi", "ncV:128:", 
"sse2")
 
-TARGET_BUILTIN(__builtin_ia32_monitor, "vv*UiUi", "n", "sse3")
+TARGET_BUILTIN(__builtin_ia32_monitor, "vvC*UiUi", "n", "sse3")
 TARGET_BUILTIN(__builtin_ia32_mwait, "vUiUi", "n", "sse3")
 TARGET_BUILTIN(__builtin_ia32_lddqu, "V16ccC*", "nV:128:", "sse3")
 
@@ -1396,8 +1396,8 @@ TARGET_BUILTIN(__builtin_ia32_psrlw512, "V32sV32sV8s", 
"ncV:512:", "avx512bw")
 TARGET_BUILTIN(__builtin_ia32_psrlwi512, "V32sV32si", "ncV:512:", "avx512bw")
 TARGET_BUILTIN(__builtin_ia32_pslldqi512_byteshift, "V8OiV8OiIi", "ncV:512:", 
"avx512bw")
 TARGET_BUILTIN(__builtin_ia32_psrldqi512_byteshift, "V8OiV8OiIi", "ncV:512:", 
"avx512bw")
-TARGET_BUILTIN(__builtin_ia32_movdqa32load128_mask, "V4iV4i*V4iUc", "nV:128:", 
"avx512vl")
-TARGET_BUILTIN(__builtin_ia32_movdqa32load256_mask, "V8iV8i*V8iUc", "nV:256:", 
"avx512vl")
+TARGET_BUILTIN(__builtin_ia32_movdqa32load128_mask, "V4iV4iC*V4iUc", 
"nV:128:", "avx512vl")
+TARGET_BUILTIN(__builtin_ia32_movdqa32load256_mask, "V8iV8iC*V8iUc", 
"nV:256:", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_movdqa32load512_mask, "V16iV16iC*V16iUs", 
"nV:512:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_movdqa32store512_mask, "vV16i*V16iUs", 
"nV:512:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_movdqa64load512_mask, "V8OiV8OiC*V8OiUc", 
"nV:512:", "avx512f")
@@ -1418,8 +1418,8 @@ TARGET_BUILTIN(__builtin_ia32_vcomisd, "iV2dV2dIiIi", 
"ncV:128:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_vcomiss, "iV4fV4fIiIi", "ncV:128:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_kunpckdi, "UOiUOiUOi", "nc", "avx512bw")
 TARGET_BUILTIN(__builtin_ia32_kunpcksi, "UiUiUi", "nc", "avx512bw")
-TARGET_BUILTIN(__builtin_ia32_loaddquhi512_mask, "V32sV32s*V32sUi", "nV:512:", 
"avx512bw")
-TARGET_BUILTIN(__builtin_ia32_loaddquqi512_mask, "V64cV64c*V64cUOi", 
"nV:512:", "avx512bw")
+TARGET_BUILTIN(__builtin_ia32_loaddquhi512_mask, "V32sV32sC*V32sUi", 
"nV:512:", "avx512bw")
+TARGET_BUILTIN(__builtin_ia32_loaddquqi512_mask, "V64cV64cC*V64cUOi", 
"nV:512:", "avx512bw")
 TARGET_BUILTIN(__builtin_ia32_fixupimmpd512_mask, "V8dV8dV8dV8OiIiUcIi", 
"ncV:512:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_fixupimmpd512_maskz, "V8dV8dV8dV8OiIiUcIi", 
"ncV:512:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_fixupimmps512_mask, "V16fV16fV16fV16iIiUsIi", 
"ncV:512:", "avx512f")
@@ -1432,10 +1432,10 @@ TARGET_BUILTIN(__builtin_ia32_getexpsd128_round_mask, 
"V2dV2dV2dV2dUcIi", "ncV:1
 TARGET_BUILTIN(__builtin_ia32_getexpss128_round_mask, "V4fV4fV4fV4fUcIi", 
"ncV:128:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_getmantsd_round_mask, "V2dV2dV2dIiV2dUcIi", 
"ncV:128:", "avx512f")
 TARGET_BUILTIN(__builtin_ia32_getmantss_round_mask, "V4fV4fV4fIiV4fUcIi", 
"ncV:128:", "avx512f")
-TARGET_BUILTIN(__builtin_ia32_loaddquhi128_mask, "V8sV8s*V8sUc", "nV:128:", 
"avx512bw,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_loaddquhi256_mask, "V16sV16s*V16sUs", "nV:256:", 
"avx512bw,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_loaddquqi128_mask, "V16cV16c*V16cUs", "nV:128:", 
"avx512bw,avx512vl")
-TARGET_BUILTIN(__builtin_ia32_loaddquqi256_mask, "V32cV32c*V32cUi", 

[clang] bcae3a7 - [PS4] Predefine the __SCE__ macro for the x86_64-scei-ps4 triple

2019-12-12 Thread Warren Ristow via cfe-commits

Author: Warren Ristow
Date: 2019-12-12T11:00:09-08:00
New Revision: bcae3a77afd171604d117393d8cb92dfca2da8bb

URL: 
https://github.com/llvm/llvm-project/commit/bcae3a77afd171604d117393d8cb92dfca2da8bb
DIFF: 
https://github.com/llvm/llvm-project/commit/bcae3a77afd171604d117393d8cb92dfca2da8bb.diff

LOG: [PS4] Predefine the __SCE__ macro for the x86_64-scei-ps4 triple

Added: 


Modified: 
clang/lib/Basic/Targets/OSTargets.h
clang/test/Preprocessor/init.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 756cb7a8bbe3..70fac030bc5d 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -538,6 +538,7 @@ class LLVM_LIBRARY_VISIBILITY PS4OSTargetInfo : public 
OSTargetInfo {
 Builder.defineMacro("__KPRINTF_ATTRIBUTE__");
 DefineStd(Builder, "unix", Opts);
 Builder.defineMacro("__ELF__");
+Builder.defineMacro("__SCE__");
 Builder.defineMacro("__ORBIS__");
   }
 

diff  --git a/clang/test/Preprocessor/init.c b/clang/test/Preprocessor/init.c
index cf0f428d38bb..9b116dda0ace 100644
--- a/clang/test/Preprocessor/init.c
+++ b/clang/test/Preprocessor/init.c
@@ -9599,6 +9599,7 @@
 // PS4:#define __PTRDIFF_TYPE__ long int
 // PS4:#define __PTRDIFF_WIDTH__ 64
 // PS4:#define __REGISTER_PREFIX__
+// PS4:#define __SCE__ 1
 // PS4:#define __SCHAR_MAX__ 127
 // PS4:#define __SHRT_MAX__ 32767
 // PS4:#define __SIG_ATOMIC_MAX__ 2147483647



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


r293911 - Prevent ICE in dllexport class with _Atomic data member

2017-02-02 Thread Warren Ristow via cfe-commits
Author: wristow
Date: Thu Feb  2 11:53:34 2017
New Revision: 293911

URL: http://llvm.org/viewvc/llvm-project?rev=293911=rev
Log:
Prevent ICE in dllexport class with _Atomic data member

Guard against a null pointer dereference that caused Clang to crash
when processing a class containing an _Atomic qualified data member,
and that is tagged with 'dllexport'.

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

Added:
cfe/trunk/test/CodeGenCXX/atomic-dllexport.cpp
Modified:
cfe/trunk/lib/CodeGen/CGClass.cpp

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=293911=293910=293911=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Thu Feb  2 11:53:34 2017
@@ -1131,10 +1131,11 @@ namespace {
   RHS = EC->getSubExpr();
 if (!RHS)
   return nullptr;
-MemberExpr *ME2 = dyn_cast(RHS);
-if (dyn_cast(ME2->getMemberDecl()) != Field)
-  return nullptr;
-return Field;
+if (MemberExpr *ME2 = dyn_cast(RHS)) {
+  if (ME2->getMemberDecl() == Field)
+return Field;
+}
+return nullptr;
   } else if (CXXMemberCallExpr *MCE = dyn_cast(S)) {
 CXXMethodDecl *MD = dyn_cast(MCE->getCalleeDecl());
 if (!(MD && isMemcpyEquivalentSpecialMember(MD)))

Added: cfe/trunk/test/CodeGenCXX/atomic-dllexport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/atomic-dllexport.cpp?rev=293911=auto
==
--- cfe/trunk/test/CodeGenCXX/atomic-dllexport.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/atomic-dllexport.cpp Thu Feb  2 11:53:34 2017
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple i686-windows-msvc -emit-llvm -std=c++11 
-fms-extensions -O0 -o - %s | FileCheck --check-prefix=M32 %s
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -std=c++11 
-fms-extensions -O0 -o - %s | FileCheck --check-prefix=M64 %s
+
+struct __declspec(dllexport) SomeStruct {
+  // Copy assignment operator should be produced, and exported:
+  // M32: define weak_odr dllexport x86_thiscallcc dereferenceable({{[0-9]+}}) 
%struct.SomeStruct* @"\01??4SomeStruct@@QAEAAU0@ABU0@@Z"
+  // M64: define weak_odr dllexportdereferenceable({{[0-9]+}}) 
%struct.SomeStruct* @"\01??4SomeStruct@@QEAAAEAU0@AEBU0@@Z"
+  _Atomic(int) mData;
+};


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


Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

2016-07-25 Thread Warren Ristow via cfe-commits
wristow added a comment.

> @wristow, if this still patches cleanly against trunk (I see that this has 
> been around a while) and test still pass, think this can be committed 
> soon-ish?


It does still apply cleanly, and testing still looks good.

Given that the test was adjusted as suggested by Reid, and the implementation 
was simplified as Richard suggested, even though you've only recently 
registered, I'll commit this.  (Actually, I don't have commit access, but one 
of my colleagues will commit it soon.)

Thanks!


https://reviews.llvm.org/D19815



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


Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

2016-06-13 Thread Warren Ristow via cfe-commits
wristow added a comment.

ping


http://reviews.llvm.org/D19815



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


Re: [PATCH] D20243: [PCH] Disable inclusion of timestamps when generating pch files on windows.

2016-05-18 Thread Warren Ristow via cfe-commits
wristow added a comment.

In http://reviews.llvm.org/D20243#433615, @thakis wrote:

> Did you see http://reviews.llvm.org/D19815 ? Does that help? Warren might 
> have opinions on this.


Yes, these are definitely related.  Fixing that other problem does //not //also 
fix the issue here, however the fix here will only work if that other fix is 
also applied.

In my view, that other issue is a fairly overt bug (PR24387) where `#pragma 
once` is blatantly ignored in a header-file processed for creating a PCH.  That 
can result in incorrect behavior, and always results in a misleading/confusing 
warning.  That issue also is independent of the host environment.

Whereas the timestamp issue described here is much more subtle, and it only 
impacts Windows hosts (due to some problem with the timestamps on the Windows 
file system).

Essentially, the proposed fix here is blocked by that other issue.  I should 
have realized and commented here earlier.  Thanks for bringing it to my 
attention.


http://reviews.llvm.org/D20243



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


Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

2016-05-16 Thread Warren Ristow via cfe-commits
wristow updated this revision to Diff 57320.
wristow added a comment.

Simplified he implementation, by using the existing `TUKind` field.


http://reviews.llvm.org/D19815

Files:
  llvm/tools/clang/lib/Lex/Pragma.cpp
  llvm/tools/clang/test/PCH/Inputs/pragma-once.h
  llvm/tools/clang/test/PCH/pragma-once.c

Index: llvm/tools/clang/test/PCH/pragma-once.c
===
--- /dev/null
+++ llvm/tools/clang/test/PCH/pragma-once.c
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/Inputs/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/Inputs/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "Inputs/pragma-once.h"
+#include "Inputs/pragma-once.h"
+int foo(void) { return 0; }
Index: llvm/tools/clang/test/PCH/Inputs/pragma-once.h
===
--- /dev/null
+++ llvm/tools/clang/test/PCH/Inputs/pragma-once.h
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;
Index: llvm/tools/clang/lib/Lex/Pragma.cpp
===
--- llvm/tools/clang/lib/Lex/Pragma.cpp
+++ llvm/tools/clang/lib/Lex/Pragma.cpp
@@ -354,7 +354,9 @@
 /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
 ///
 void Preprocessor::HandlePragmaOnce(Token ) {
-  if (isInPrimaryFile()) {
+  // Don't honor the 'once' when handling the primary source file, unless
+  // this is a prefix to a TU, which indicates we're generating a PCH file.
+  if (isInPrimaryFile() && TUKind != TU_Prefix) {
 Diag(OnceTok, diag::pp_pragma_once_in_main_file);
 return;
   }


Index: llvm/tools/clang/test/PCH/pragma-once.c
===
--- /dev/null
+++ llvm/tools/clang/test/PCH/pragma-once.c
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/Inputs/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/Inputs/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "Inputs/pragma-once.h"
+#include "Inputs/pragma-once.h"
+int foo(void) { return 0; }
Index: llvm/tools/clang/test/PCH/Inputs/pragma-once.h
===
--- /dev/null
+++ llvm/tools/clang/test/PCH/Inputs/pragma-once.h
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;
Index: llvm/tools/clang/lib/Lex/Pragma.cpp
===
--- llvm/tools/clang/lib/Lex/Pragma.cpp
+++ llvm/tools/clang/lib/Lex/Pragma.cpp
@@ -354,7 +354,9 @@
 /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
 ///
 void Preprocessor::HandlePragmaOnce(Token ) {
-  if (isInPrimaryFile()) {
+  // Don't honor the 'once' when handling the primary source file, unless
+  // this is a prefix to a TU, which indicates we're generating a PCH file.
+  if (isInPrimaryFile() && TUKind != TU_Prefix) {
 Diag(OnceTok, diag::pp_pragma_once_in_main_file);
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

2016-05-12 Thread Warren Ristow via cfe-commits
wristow added a comment.

Ping


http://reviews.llvm.org/D19815



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


Re: [PATCH] D19815: Support '#pragma once' in headers when using PCH

2016-05-02 Thread Warren Ristow via cfe-commits
wristow added a comment.

To check for whether we're in "generate a PCH file mode", I added a new flag 
(`GeneratePCHMode`) to `PreprocessorOptions`.  If the `CompilerInstance` had 
been visible in lexical analysis, it would have been easy to do this without 
adding a new flag.  Is there a better way to determine whether Clang is 
generating a PCH file?  One alternative approach considered was to put a 
reference to `FrontendOptions` into the `Preprocessor` class (it already 
includes a reference to `LangOpts`, for example).


http://reviews.llvm.org/D19815



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


[PATCH] D19815: Support '#pragma once' in headers when using PCH

2016-05-02 Thread Warren Ristow via cfe-commits
wristow created this revision.
wristow added a reviewer: rsmith.
wristow added a subscriber: cfe-commits.

The '#pragma once' directive was erroneously ignored when encountered
in the header-file specified in generate-PCH-mode.  This resulted in
compile-time errors in some cases with legal code, and also a misleading
warning being produced.

This fixes PR24387.

http://reviews.llvm.org/D19815

Files:
  include/clang/Lex/PreprocessorOptions.h
  lib/Frontend/InitPreprocessor.cpp
  lib/Lex/Pragma.cpp
  test/PCH/pragma-once.c
  test/PCH/pragma-once.h

Index: test/PCH/pragma-once.h
===
--- /dev/null
+++ test/PCH/pragma-once.h
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;
Index: test/PCH/pragma-once.c
===
--- /dev/null
+++ test/PCH/pragma-once.c
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "pragma-once.h"
+#include "pragma-once.h"
+int foo(void) { return 0; }
Index: lib/Lex/Pragma.cpp
===
--- lib/Lex/Pragma.cpp
+++ lib/Lex/Pragma.cpp
@@ -19,6 +19,7 @@
 #include "clang/Lex/LexDiagnostic.h"
 #include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroInfo.h"
+#include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -354,7 +355,9 @@
 /// HandlePragmaOnce - Handle \#pragma once.  OnceTok is the 'once'.
 ///
 void Preprocessor::HandlePragmaOnce(Token ) {
-  if (isInPrimaryFile()) {
+  // Don't honor the 'once' when handling the primary source file, unless
+  // we're generating a PCH file.
+  if (isInPrimaryFile() && !getPreprocessorOpts().GeneratePCHMode) {
 Diag(OnceTok, diag::pp_pragma_once_in_main_file);
 return;
   }
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -1021,6 +1021,10 @@
   if (!InitOpts.ImplicitPTHInclude.empty())
 AddImplicitIncludePTH(Builder, PP, InitOpts.ImplicitPTHInclude);
 
+  // Instruct the preprocessor that we're generating a PCH file.
+  if (FEOpts.ProgramAction == frontend::GeneratePCH)
+PP.getPreprocessorOpts().GeneratePCHMode = true;
+
   // Process -include directives.
   for (unsigned i = 0, e = InitOpts.Includes.size(); i != e; ++i) {
 const std::string  = InitOpts.Includes[i];
Index: include/clang/Lex/PreprocessorOptions.h
===
--- include/clang/Lex/PreprocessorOptions.h
+++ include/clang/Lex/PreprocessorOptions.h
@@ -61,6 +61,9 @@
   /// \brief Headers that will be converted to chained PCHs in memory.
   std::vector ChainedIncludes;
 
+  /// \brief When true, we are generating a pre-compiled header.
+  bool GeneratePCHMode;
+
   /// \brief When true, disables most of the normal validation performed on
   /// precompiled headers.
   bool DisablePCHValidation;
@@ -141,6 +144,7 @@
 
 public:
   PreprocessorOptions() : UsePredefines(true), DetailedRecord(false),
+  GeneratePCHMode(false),
   DisablePCHValidation(false),
   AllowPCHWithCompilerErrors(false),
   DumpDeserializedPCHDecls(false),


Index: test/PCH/pragma-once.h
===
--- /dev/null
+++ test/PCH/pragma-once.h
@@ -0,0 +1,5 @@
+#pragma once
+
+/* For use with the pragma-once.c test */
+
+int x = 3;
Index: test/PCH/pragma-once.c
===
--- /dev/null
+++ test/PCH/pragma-once.c
@@ -0,0 +1,13 @@
+// Test this without pch.
+// RUN: %clang_cc1 -include %S/pragma-once.h -fsyntax-only -verify %s
+
+// Test with pch.
+// RUN: %clang_cc1 -emit-pch -o %t %S/pragma-once.h
+// RUN: %clang_cc1 -include-pch %t -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+// Including "pragma-once.h" twice, to verify the 'once' aspect is honored.
+#include "pragma-once.h"
+#include "pragma-once.h"
+int foo(void) { return 0; }
Index: lib/Lex/Pragma.cpp
===
--- lib/Lex/Pragma.cpp
+++ lib/Lex/Pragma.cpp
@@ -19,6 +19,7 @@
 #include "clang/Lex/LexDiagnostic.h"
 #include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroInfo.h"
+#include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringSwitch.h"
@@ -354,7 +355,9 @@
 /// 

Re: [PATCH] D18708: Set C99 as default C Standard for PS4 target

2016-04-05 Thread Warren Ristow via cfe-commits
wristow added a subscriber: wristow.
wristow added a comment.

In http://reviews.llvm.org/D18708#390183, @dyung wrote:

> In http://reviews.llvm.org/D18708#390166, @rsmith wrote:
>
> > In http://reviews.llvm.org/D18708#390150, @dyung wrote:
> >
> > > From my understanding, there are 2 issues that block us. The first is 
> > > that we currently do not ship all of the header files for C11. The second 
> > > is that we do not yet fully have C11 library support yet for our platform.
> >
> >
> > How do things go wrong if Clang is used in C11 mode against a C99 library? 
> > Do you have code that conditionally uses C11 library features if they're 
> > available? (And thanks for explaining, by the way; this is useful 
> > information for when we next consider changing the default language mode -- 
> > we'll likely be changing the default C++ language mode soon.)
> >
> > Anyway, it seems reasonable for the PS4 toolchain to control its defaults 
> > here, and the patch itself LGTM.
>
>
> My understanding is that we currently do not ship all of the headers required 
> for C11, so if users tried to use anything from those, they would be unable 
> to do so. I am also under the impression that C11 requires some library 
> support which we do not yet provide.


To confirm and more directly answer your questions, we haven't encountered any 
situations where things have gone wrong when compiling in C11 mode against a 
C99 library.  As far as we're aware, Clang doesn't have any problems in that 
area (e.g., we don't know of any situations where Clang in C11 mode is 
rejecting valid C99 code).  We're just being conservative, in that since we 
don't provide C11 libraries and headers (and therefore we officially tell our 
customers we don't support C11), we don't want to run into situations where 
customers might conditionally enable a C11 library feature.  We may revisit 
that approach sometime in the future depending on customer demand for C11 
features, but at this point, we're defaulting to C99 just to be conservative.


Repository:
  rL LLVM

http://reviews.llvm.org/D18708



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


Re: [PATCH] D17775: Add a few dllimport/dllexport tests. NFC

2016-03-01 Thread Warren Ristow via cfe-commits
wristow added a comment.

In http://reviews.llvm.org/D17775#365611, @silvas wrote:

> Random question:
>
> > We plan to enable dllimport/dllexport support for the PS4
>
>
> How are you planning on codegenning them? The same way as we do in our 
> private branch?


Yes, that's the intention.


http://reviews.llvm.org/D17775



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


[PATCH] D17775: Add a few dllimport/dllexport tests. NFC

2016-03-01 Thread Warren Ristow via cfe-commits
wristow created this revision.
wristow added reviewers: cfe-commits, rnk, majnemer.

This change just adds tests for some corner cases of dllimport/dllexport,
primarily for some static methods.

We plan to enable dllimport/dllexport support for the PS4, and these
additional tests are for points we previously were testing internally.

Can someone review, and if OK then commit this patch for me, please?

-Warren Ristow
SN Systems - Sony Computer Entertainment Group

http://reviews.llvm.org/D17775

Files:
  llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
  llvm/tools/clang/test/CodeGenCXX/dllimport.cpp

Index: llvm/tools/clang/test/CodeGenCXX/dllimport.cpp
===
--- llvm/tools/clang/test/CodeGenCXX/dllimport.cpp
+++ llvm/tools/clang/test/CodeGenCXX/dllimport.cpp
@@ -27,6 +27,7 @@
 #define USEVAR(var) USEVARTYPE(int, var)
 #define USE(func) void UNIQ(use)() { func(); }
 #define USEMEMFUNC(class, func) void (class::*UNIQ(use)())() { return 
::func; }
+#define USESTATICMEMFUNC(class, func) void (*UNIQ(use)())() { return 
::func; }
 #define USECLASS(class) void UNIQ(USE)() { class x; }
 #define USECOPYASSIGN(class) class& (class::*UNIQ(use)())(class&) { return 
::operator=; }
 #define USEMOVEASSIGN(class) class& (class::*UNIQ(use)())(class&&) { return 
::operator=; }
@@ -590,6 +591,10 @@
   void a() {}
   // MO1-DAG: define available_externally dllimport x86_thiscallcc void 
@"\01?a@T@@QAEXXZ"
 
+  static void StaticMethod();
+  // MSC-DAG: declare dllimport void @"\01?StaticMethod@T@@SAXXZ"()
+  // GNU-DAG: declare dllimport void @_ZN1T12StaticMethodEv()
+
   static int b;
   // MO1-DAG: @"\01?b@T@@2HA" = external dllimport global i32
 
@@ -602,6 +607,7 @@
   // M19-DAG: define available_externally dllimport x86_thiscallcc 
dereferenceable({{[0-9]+}}) %struct.T* @"\01??4T@@QAEAAU0@$$QAU0@@Z"
 };
 USEMEMFUNC(T, a)
+USESTATICMEMFUNC(T, StaticMethod)
 USEVAR(T::b)
 USECOPYASSIGN(T)
 USEMOVEASSIGN(T)
Index: llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
===
--- llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
+++ llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
@@ -570,6 +570,30 @@
 USEVAR(T::b)
 int T::c;
 
+// Export template class with static member variable
+// MSC-DAG: @"\01?StaticClassVarExpTmplClass@?$TmplClass@H@@2HA" = weak_odr 
dllexport global i32 0, comdat, align 4
+// GNU-DAG: @_ZN9TmplClassIiE26StaticClassVarExpTmplClassE = weak_odr 
dllexport global i32 0, comdat, align 4
+template
+struct __declspec(dllexport) TmplClass
+{
+  static T StaticClassVarExpTmplClass;
+};
+
+template
+T TmplClass::StaticClassVarExpTmplClass;
+
+// Export a definition of a template function.
+// MSC-DAG: define weak_odr dllexport i32 @"\01??$TypeFunTmpl@H@@YAHH@Z"
+// GNU-DAG: define weak_odr dllexport i32 @_Z11TypeFunTmplIiET_S0_
+template
+T __declspec(dllexport) TypeFunTmpl(T t) { return t + t; }
+
+// Instantiate the exported template class and the exported template function.
+int useExportedTmplStaticAndFun()
+{
+  return TmplClass::StaticClassVarExpTmplClass + TypeFunTmpl(10);
+}
+
 template  struct __declspec(dllexport) U { void foo() {} };
 struct __declspec(dllexport) V : public U { };
 // U's assignment operator is emitted.


Index: llvm/tools/clang/test/CodeGenCXX/dllimport.cpp
===
--- llvm/tools/clang/test/CodeGenCXX/dllimport.cpp
+++ llvm/tools/clang/test/CodeGenCXX/dllimport.cpp
@@ -27,6 +27,7 @@
 #define USEVAR(var) USEVARTYPE(int, var)
 #define USE(func) void UNIQ(use)() { func(); }
 #define USEMEMFUNC(class, func) void (class::*UNIQ(use)())() { return ::func; }
+#define USESTATICMEMFUNC(class, func) void (*UNIQ(use)())() { return ::func; }
 #define USECLASS(class) void UNIQ(USE)() { class x; }
 #define USECOPYASSIGN(class) class& (class::*UNIQ(use)())(class&) { return ::operator=; }
 #define USEMOVEASSIGN(class) class& (class::*UNIQ(use)())(class&&) { return ::operator=; }
@@ -590,6 +591,10 @@
   void a() {}
   // MO1-DAG: define available_externally dllimport x86_thiscallcc void @"\01?a@T@@QAEXXZ"
 
+  static void StaticMethod();
+  // MSC-DAG: declare dllimport void @"\01?StaticMethod@T@@SAXXZ"()
+  // GNU-DAG: declare dllimport void @_ZN1T12StaticMethodEv()
+
   static int b;
   // MO1-DAG: @"\01?b@T@@2HA" = external dllimport global i32
 
@@ -602,6 +607,7 @@
   // M19-DAG: define available_externally dllimport x86_thiscallcc dereferenceable({{[0-9]+}}) %struct.T* @"\01??4T@@QAEAAU0@$$QAU0@@Z"
 };
 USEMEMFUNC(T, a)
+USESTATICMEMFUNC(T, StaticMethod)
 USEVAR(T::b)
 USECOPYASSIGN(T)
 USEMOVEASSIGN(T)
Index: llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
===
--- llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
+++ llvm/tools/clang/test/CodeGenCXX/dllexport.cpp
@@ -570,6 +570,30 @@
 USEVAR(T::b)
 int T::c;
 
+// Export template class with static member variable
+// 

Re: [PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

2015-10-02 Thread Warren Ristow via cfe-commits
wristow added inline comments.


Comment at: lib/Driver/Tools.cpp:4663
@@ +4662,3 @@
+  else if (Args.hasArg(options::OPT_fno_declspec))
+CmdArgs.push_back("-fno-declspec"); // Explicitly disabling __declspec.
+

But in the '-fno-declspec -fdeclspec' case, the 'if' clause "wins", and we 
never even reach the test of the 'else if' clause.  As I said at the end of my 
previous comment, if -fno-declspec isn't the last one, we don't get to that 
line.  That said, given the interaction with "implicit enabling" of declspec 
(via Microsoft, Borland, CUDA), it's a bit different than vanilla 
switch-handling.  So I've updated the tests to explicitly have some checks for 
'-fno-declspec -fdeclspec' case (and the reverse, and for with and without 
-fms-extensions interacting).


http://reviews.llvm.org/D13322



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


Re: [PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

2015-10-02 Thread Warren Ristow via cfe-commits
wristow updated this revision to Diff 36373.
wristow added a comment.

Added 4 new tests, the verify the last -fdeclspec/-fno-declspec wins, both in 
the context of -fms-extensions and without -fms-extensions.


http://reviews.llvm.org/D13322

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Basic/TokenKinds.def
  include/clang/Driver/Options.td
  include/clang/Parse/Parser.h
  lib/Basic/IdentifierTable.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParseDecl.cpp
  test/Lexer/keywords_test.c
  test/Lexer/keywords_test.cpp

Index: test/Lexer/keywords_test.cpp
===
--- test/Lexer/keywords_test.cpp
+++ test/Lexer/keywords_test.cpp
@@ -1,6 +1,19 @@
 // RUN: %clang_cc1 -std=c++03 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++11 -DCXX11 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++14 -fconcepts-ts -DCXX11 -DCONCEPTS -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fno-declspec -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fdeclspec -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fno-declspec -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fdeclspec -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -fno-declspec -fsyntax-only %s
 
 #define IS_KEYWORD(NAME) _Static_assert(!__is_identifier(NAME), #NAME)
 #define NOT_KEYWORD(NAME) _Static_assert(__is_identifier(NAME), #NAME)
@@ -12,6 +25,12 @@
 #define CONCEPTS_KEYWORD(NAME)  NOT_KEYWORD(NAME)
 #endif
 
+#ifdef DECLSPEC
+#define DECLSPEC_KEYWORD(NAME)  IS_KEYWORD(NAME)
+#else
+#define DECLSPEC_KEYWORD(NAME)  NOT_KEYWORD(NAME)
+#endif
+
 #ifdef CXX11
 #define CXX11_KEYWORD(NAME)  IS_KEYWORD(NAME)
 #define CXX11_TYPE(NAME) IS_TYPE(NAME)
@@ -38,6 +57,9 @@
 CONCEPTS_KEYWORD(concept);
 CONCEPTS_KEYWORD(requires);
 
+// __declspec extension
+DECLSPEC_KEYWORD(__declspec);
+
 // Clang extension
 IS_KEYWORD(__char16_t);
 IS_TYPE(__char16_t);
Index: test/Lexer/keywords_test.c
===
--- test/Lexer/keywords_test.c
+++ test/Lexer/keywords_test.c
@@ -9,6 +9,10 @@
 
 // RUN: %clang_cc1 -std=c99 -fms-extensions -E %s -o - \
 // RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS %s
+// RUN: %clang_cc1 -std=c99 -fdeclspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-DECLSPEC-KEYWORD %s
+// RUN: %clang_cc1 -std=c99 -fms-extensions -fno-declspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC %s
 
 void f() {
 // CHECK-NONE: int asm
@@ -22,8 +26,19 @@
 
 // CHECK-NONE: no_ms_wchar
 // CHECK-MS-KEYWORDS: has_ms_wchar
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: has_ms_wchar
 #if __is_identifier(__wchar_t)
 void no_ms_wchar();
 #else
 void has_ms_wchar();
 #endif
+
+// CHECK-NONE: no_declspec
+// CHECK-MS-KEYWORDS: has_declspec
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: no_declspec
+// CHECK-DECLSPEC-KEYWORD: has_declspec
+#if __is_identifier(__declspec)
+void no_declspec();
+#else
+void has_declspec();
+#endif
Index: lib/Parse/ParseDecl.cpp
===
--- lib/Parse/ParseDecl.cpp
+++ lib/Parse/ParseDecl.cpp
@@ -532,9 +532,7 @@
 /// extended-decl-modifier extended-decl-modifier-seq
 void Parser::ParseMicrosoftDeclSpecs(ParsedAttributes ,
  SourceLocation *End) {
-  assert((getLangOpts().MicrosoftExt || getLangOpts().Borland ||
-  getLangOpts().CUDA) &&
- "Incorrect language options for parsing __declspec");
+  assert(getLangOpts().DeclSpecKeyword && "__declspec keyword is not enabled");
   assert(Tok.is(tok::kw___declspec) && "Not a declspec!");
 
   while (Tok.is(tok::kw___declspec)) {
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1630,6 +1630,17 @@
   Opts.HalfArgsAndReturns = Args.hasArg(OPT_fallow_half_arguments_and_returns);
   Opts.GNUAsm = !Args.hasArg(OPT_fno_gnu_inline_asm);
 
+  // __declspec is enabled by default for the PS4 by the driver, and also
+  // enabled for Microsoft Extensions or Borland Extensions, here.
+  //
+  // FIXME: __declspec is also 

Re: [PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

2015-10-01 Thread Warren Ristow via cfe-commits
wristow added inline comments.


Comment at: include/clang/Basic/LangOptions.def:93
@@ -92,2 +92,3 @@
 LANGOPT(WChar , 1, CPlusPlus, "wchar_t keyword")
+LANGOPT(DeclSpecKeyword   , 1, 0, "Microsoft __declspec keyword support")
 BENIGN_LANGOPT(DollarIdents   , 1, 1, "'$' in identifiers")

rsmith wrote:
> compnerd wrote:
> > Im not sure I care for Microsoft here.  This is an extension that is 
> > supported on more than one compiler suite.  How about "Enable support for 
> > __declspec extension"?
> These strings are used in a diagnostic of the form "support for %0 is not 
> enabled", so `"__declspec"` or `"__declspec keyword"` would be appropriate.
I see.  Then I'll change it to "__declspec keyword", to both remove the 
Microsoft reference and make it appropriate for the diagnostic formed from it.


Comment at: include/clang/Driver/Options.td:520
@@ -519,1 +519,3 @@
+def fdeclspec : Flag<["-"], "fdeclspec">, Group,
+  HelpText<"Allow __declspec as a keyword">, Flags<[CC1Option]>;
 def fdollars_in_identifiers : Flag<["-"], "fdollars-in-identifiers">, 
Group,

rsmith wrote:
> compnerd wrote:
> > Shouldn't these be DriverOptions, and CC1Options?
> This should be in `f_clang_Group`, not `f_Group`.
I'll upload an updated patch shortly that takes care of this.


Comment at: lib/Driver/Tools.cpp:4663
@@ +4662,3 @@
+  else if (Args.hasArg(options::OPT_fno_declspec))
+CmdArgs.push_back("-fno-declspec"); // Explicitly disabling __declspec.
+

rsmith wrote:
> compnerd wrote:
> > The Args.hasFlag will correctly give you the value (-fdeclspec 
> > -fno-declspec will be treated as -fno-declspec).  In fact, doesn't your 
> > implementation make -fno-declspec take precedence?
> > 
> > Plus, you marked these as cc1options above, not driver options.  These 
> > aren't technically available here.
> The options are in the driver's Options.td and marked as CC1Option, so 
> they're available in both the driver and cc1.
OK, then I'll leave them marked as CC1Option.


Comment at: lib/Driver/Tools.cpp:4663
@@ +4662,3 @@
+  else if (Args.hasArg(options::OPT_fno_declspec))
+CmdArgs.push_back("-fno-declspec"); // Explicitly disabling __declspec.
+

wristow wrote:
> rsmith wrote:
> > compnerd wrote:
> > > The Args.hasFlag will correctly give you the value (-fdeclspec 
> > > -fno-declspec will be treated as -fno-declspec).  In fact, doesn't your 
> > > implementation make -fno-declspec take precedence?
> > > 
> > > Plus, you marked these as cc1options above, not driver options.  These 
> > > aren't technically available here.
> > The options are in the driver's Options.td and marked as CC1Option, so 
> > they're available in both the driver and cc1.
> OK, then I'll leave them marked as CC1Option.
Regarding the -fno-declspec taking precedence question, I think I've got it 
right, but I could have misunderstood something.  There is a complication with 
this declspec-keyword recognition, in that in addition to it being enabled by 
default for PS4, it's implicitly enabled by default with any of 
-fms-compatibility, -fms-extensions and -fborland-extensions (and temporarily 
also for CUDA).  My goal of -fno-declspec is that it should over-ride any 
implicit enabling of declspec.  The implicit enabling was handled in cc1 itself 
(by inspecting values that depend on -fms-compatibility, -fms-extensions, 
-fborland-extensions, and CUDA).  I left that being handled in cc1, although I 
considered collecting that information here in the driver, and passing a more 
elaborate expression as the 'Default' arg to hasFlag(), in which case I 
wouldn't have needed to explicitly push_back("-fno-declspec").  Anyway, with 
implicit enabling of declspec happening in cc1, it was easy to over-ride it by 
explicitly passing -fno-declspec through, iff that was the last 
-fdeclspec/-fno-declspec arg passed by the user.  So that's what I'm doing on 
the line with the "// Explicitly disabling __declspec." comment (unless I've 
misunderstood, if -fno-declspec isn't the last one, we don't get to that line).


http://reviews.llvm.org/D13322



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


Re: [PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

2015-10-01 Thread Warren Ristow via cfe-commits
wristow updated this revision to Diff 36307.
wristow added a comment.

Updated patch to change the Group of the diagnostic from f_Group to 
f_clang_Group, and to change the string associated with the LANGOPT definition 
of the flag.  Also fixed a minor typo in a comment.


http://reviews.llvm.org/D13322

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Basic/TokenKinds.def
  include/clang/Driver/Options.td
  include/clang/Parse/Parser.h
  lib/Basic/IdentifierTable.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParseDecl.cpp
  test/Lexer/keywords_test.c
  test/Lexer/keywords_test.cpp

Index: test/Lexer/keywords_test.cpp
===
--- test/Lexer/keywords_test.cpp
+++ test/Lexer/keywords_test.cpp
@@ -1,6 +1,15 @@
 // RUN: %clang_cc1 -std=c++03 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++11 -DCXX11 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++14 -fconcepts-ts -DCXX11 -DCONCEPTS -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -fno-declspec -fsyntax-only %s
 
 #define IS_KEYWORD(NAME) _Static_assert(!__is_identifier(NAME), #NAME)
 #define NOT_KEYWORD(NAME) _Static_assert(__is_identifier(NAME), #NAME)
@@ -12,6 +21,12 @@
 #define CONCEPTS_KEYWORD(NAME)  NOT_KEYWORD(NAME)
 #endif
 
+#ifdef DECLSPEC
+#define DECLSPEC_KEYWORD(NAME)  IS_KEYWORD(NAME)
+#else
+#define DECLSPEC_KEYWORD(NAME)  NOT_KEYWORD(NAME)
+#endif
+
 #ifdef CXX11
 #define CXX11_KEYWORD(NAME)  IS_KEYWORD(NAME)
 #define CXX11_TYPE(NAME) IS_TYPE(NAME)
@@ -38,6 +53,9 @@
 CONCEPTS_KEYWORD(concept);
 CONCEPTS_KEYWORD(requires);
 
+// __declspec extension
+DECLSPEC_KEYWORD(__declspec);
+
 // Clang extension
 IS_KEYWORD(__char16_t);
 IS_TYPE(__char16_t);
Index: test/Lexer/keywords_test.c
===
--- test/Lexer/keywords_test.c
+++ test/Lexer/keywords_test.c
@@ -9,6 +9,10 @@
 
 // RUN: %clang_cc1 -std=c99 -fms-extensions -E %s -o - \
 // RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS %s
+// RUN: %clang_cc1 -std=c99 -fdeclspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-DECLSPEC-KEYWORD %s
+// RUN: %clang_cc1 -std=c99 -fms-extensions -fno-declspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC %s
 
 void f() {
 // CHECK-NONE: int asm
@@ -22,8 +26,19 @@
 
 // CHECK-NONE: no_ms_wchar
 // CHECK-MS-KEYWORDS: has_ms_wchar
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: has_ms_wchar
 #if __is_identifier(__wchar_t)
 void no_ms_wchar();
 #else
 void has_ms_wchar();
 #endif
+
+// CHECK-NONE: no_declspec
+// CHECK-MS-KEYWORDS: has_declspec
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: no_declspec
+// CHECK-DECLSPEC-KEYWORD: has_declspec
+#if __is_identifier(__declspec)
+void no_declspec();
+#else
+void has_declspec();
+#endif
Index: lib/Parse/ParseDecl.cpp
===
--- lib/Parse/ParseDecl.cpp
+++ lib/Parse/ParseDecl.cpp
@@ -532,9 +532,7 @@
 /// extended-decl-modifier extended-decl-modifier-seq
 void Parser::ParseMicrosoftDeclSpecs(ParsedAttributes ,
  SourceLocation *End) {
-  assert((getLangOpts().MicrosoftExt || getLangOpts().Borland ||
-  getLangOpts().CUDA) &&
- "Incorrect language options for parsing __declspec");
+  assert(getLangOpts().DeclSpecKeyword && "__declspec keyword is not enabled");
   assert(Tok.is(tok::kw___declspec) && "Not a declspec!");
 
   while (Tok.is(tok::kw___declspec)) {
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1630,6 +1630,17 @@
   Opts.HalfArgsAndReturns = Args.hasArg(OPT_fallow_half_arguments_and_returns);
   Opts.GNUAsm = !Args.hasArg(OPT_fno_gnu_inline_asm);
 
+  // __declspec is enabled by default for the PS4 by the driver, and also
+  // enabled for Microsoft Extensions or Borland Extensions, here.
+  //
+  // FIXME: __declspec is also currently enabled for CUDA, but isn't really a
+  // CUDA extension, however it is required for supporting cuda_builtin_vars.h,
+  // which uses __declspec(property). Once that has been rewritten in terms of
+  // something more generic, remove the Opts.CUDA term here.
+  

Re: [PATCH] D11207: Enable recognition of __declspec for PS4

2015-09-30 Thread Warren Ristow via cfe-commits
wristow abandoned this revision.
wristow added a comment.

This has been superseded by http://reviews.llvm.org/D13322.


http://reviews.llvm.org/D11207



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


[PATCH] D13322: Add -f[no-]declspec to control recognition of __declspec as a keyword

2015-09-30 Thread Warren Ristow via cfe-commits
wristow created this revision.
wristow added reviewers: aaron.ballman, ygao, alexr, silvas, compnerd, 
cfe-commits.

In versions of clang prior to r238238, __declspec was recognized as a
keyword in all modes.  It was then changed to only be enabled when
Microsoft or Borland extensions were enabled (and for CUDA, as a
temporary measure).  There is a desire to support __declspec in
Playstation code, and possibly other environments.  This commit adds a
command-line switch to allow explicit enabling/disabling of the
recognition of __declspec as a keyword.  Recognition is enabled by
default in Microsoft, Borland, CUDA and PS4 environments, and disabled
in all other environments.

This proposed change supersedes D11207.  In D11207, it was proposed that a new 
language-dialect be added to Clang, to support extensions used in the 
Playstation environment.  The primary motivation of that language-dialect was 
the recognition of __declspec as a keyword.  After consideration, it was 
suggested that adding a switch to independently control the recognition of 
__declspec was an alternative to consider.  See:

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150713/133310.html

As a result of that, this proposed change adds a switch to control the 
recognition of __declspec.

Can someone review, and if OK then commit this patch for me, please?

-Warren Ristow
SN Systems - Sony Computer Entertainment Group

http://reviews.llvm.org/D13322

Files:
  include/clang/Basic/LangOptions.def
  include/clang/Basic/TokenKinds.def
  include/clang/Driver/Options.td
  include/clang/Parse/Parser.h
  lib/Basic/IdentifierTable.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Parse/ParseDecl.cpp
  test/Lexer/keywords_test.c
  test/Lexer/keywords_test.cpp

Index: test/Lexer/keywords_test.cpp
===
--- test/Lexer/keywords_test.cpp
+++ test/Lexer/keywords_test.cpp
@@ -1,6 +1,15 @@
 // RUN: %clang_cc1 -std=c++03 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++11 -DCXX11 -fsyntax-only %s
 // RUN: %clang_cc1 -std=c++14 -fconcepts-ts -DCXX11 -DCONCEPTS -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fdeclspec -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -DDECLSPEC -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fms-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang_cc1 -std=c++03 -fborland-extensions -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -DDECLSPEC -fsyntax-only %s
+// RUN: %clang -std=c++03 -target i686-windows-msvc -fno-declspec -fsyntax-only %s
+// RUN: %clang -std=c++03 -target x86_64-scei-ps4 -fno-declspec -fsyntax-only %s
 
 #define IS_KEYWORD(NAME) _Static_assert(!__is_identifier(NAME), #NAME)
 #define NOT_KEYWORD(NAME) _Static_assert(__is_identifier(NAME), #NAME)
@@ -12,6 +21,12 @@
 #define CONCEPTS_KEYWORD(NAME)  NOT_KEYWORD(NAME)
 #endif
 
+#ifdef DECLSPEC
+#define DECLSPEC_KEYWORD(NAME)  IS_KEYWORD(NAME)
+#else
+#define DECLSPEC_KEYWORD(NAME)  NOT_KEYWORD(NAME)
+#endif
+
 #ifdef CXX11
 #define CXX11_KEYWORD(NAME)  IS_KEYWORD(NAME)
 #define CXX11_TYPE(NAME) IS_TYPE(NAME)
@@ -38,6 +53,9 @@
 CONCEPTS_KEYWORD(concept);
 CONCEPTS_KEYWORD(requires);
 
+// __declspec extension
+DECLSPEC_KEYWORD(__declspec);
+
 // Clang extension
 IS_KEYWORD(__char16_t);
 IS_TYPE(__char16_t);
Index: test/Lexer/keywords_test.c
===
--- test/Lexer/keywords_test.c
+++ test/Lexer/keywords_test.c
@@ -9,6 +9,10 @@
 
 // RUN: %clang_cc1 -std=c99 -fms-extensions -E %s -o - \
 // RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS %s
+// RUN: %clang_cc1 -std=c99 -fdeclspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-DECLSPEC-KEYWORD %s
+// RUN: %clang_cc1 -std=c99 -fms-extensions -fno-declspec -E %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC %s
 
 void f() {
 // CHECK-NONE: int asm
@@ -22,8 +26,19 @@
 
 // CHECK-NONE: no_ms_wchar
 // CHECK-MS-KEYWORDS: has_ms_wchar
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: has_ms_wchar
 #if __is_identifier(__wchar_t)
 void no_ms_wchar();
 #else
 void has_ms_wchar();
 #endif
+
+// CHECK-NONE: no_declspec
+// CHECK-MS-KEYWORDS: has_declspec
+// CHECK-MS-KEYWORDS-WITHOUT-DECLSPEC: no_declspec
+// CHECK-DECLSPEC-KEYWORD: has_declspec
+#if __is_identifier(__declspec)
+void no_declspec();
+#else
+void has_declspec();
+#endif
Index: lib/Parse/ParseDecl.cpp
===
--- lib/Parse/ParseDecl.cpp
+++ lib/Parse/ParseDecl.cpp
@@ -532,9 +532,7 @@
 /// extended-decl-modifier extended-decl-modifier-seq
 void Parser::ParseMicrosoftDeclSpecs(ParsedAttributes ,
  SourceLocation *End) {
-