Re: r212427 - libclang: refactor handling of unsaved_files
Author: Alp Toker Date: Mon Jul 7 22:42:03 2014 + libclang: pass return code out argument by reference r212427 formalized the message-passing pattern by making these argument structures const. This commit changes output arguments to get passed by reference so we can eliminate mutable fields. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212497 91177308-0d34-0410-b5e6-96231b3b80d8 On 08/07/2014 07:26, David Blaikie wrote: On Mon, Jul 7, 2014 at 9:14 PM, Alp Toker wrote: On 08/07/2014 06:27, David Blaikie wrote: Hi Alp, It looks like you responded to some of this code review in r212497. Usually we follow up with a reply to the original review feedback and mention the commit message where feedback was addressed (and explain why unaddressed feedback was left as it was). I've explained the fixes already in detail within the commit log. Without mention of the context, but that's OK (sometimes people prefer to mention that the commit was motivated by code review, mentioning the original revision See the commit log in question, above, which cites the referenced revision in its *first line*: "r212427 formalized" ... , etc - helps provide breadcrumbs later), not something I was commenting on. That commit was a couple of hours ago and I obviously intend to follow-up once remaining points are addressed.. Sorry about that - but it wasn't obvious to me. I seemed to recall seeing this (code review feedback responded to, but lacking the trail back to the original commit, etc) previously (perhaps from you, perhaps others as well/instead - I don't know) & figured I'd comment on it to help things along. Anyway, I see you made the mutable member a reference instead. That seems OK, but still a bit 'interesting' - do you know if there's any reason the return value of clang_parseTranslationUnit_Impl wasn't used for the result, or at least a separate reference parameter? (I'm not David, It's OK to ask questions, but but it's clear from what you've said above that you're not particularly familiar with the libclang process isolation model. Not even in the slightest - wouldn't mind understanding. But if as it pertains to the code review it might be sufficient to say "the system here needs all the parameters wrapped in a single struct" (possibly with a sentence about why), that doesn't seem terribly laborious, See the commit log above where I've gone out of my way to explain the existing code, and usage of these structures as part of a cross-thread message-passing system: "the message-passing pattern by making these argument structures const." and the code change you made seems great (the struct member types then match what the argument types would be, if it weren't for this process isolation mechanism/limitations). sure why all the parameters, especially the result, were bundled into a struct - I guess it might have to do with that RunSafely function? Maybe it could be made variadic/perfect forwarding, if it isn't already) The message structure is passed by pointer to an isolated thread to enable strong crash recovery. I'm sorry but we're *not* rewriting this any time soon, and especially not as part of a commit to consolidate unsaved_files. No need to apologize - I was talking casually about what might be possible, knowing very little about the limitations or how deep-seeded or well justified they are. It's totally OK to say "yeah, it's this way for a good reason and it's either not worth changing or worth changing but requires a lot of work that's not a priority right now". That's exactly how I *would* have responded after reading your mail, had you the patience to hold on for a few hours after sending your questions before pushing for a reply in this manner. You've sent me 10 emails today, often on topics that are tangential to the actual commits. You need to be aware that these aren't going to get same-day responses. Sure - I just usually at least handle one email in its entirety - no reason that's everyone else's process. As I said above, just thought I'd recalled some other cases of code review responses without final feedback/breadcrumbs. I may've misremembered. Huh. The commits I make in the LLVM project are *systematic* about citing related revisions, historic commits, PRs, even referencing cross-module dependency changes to help people using modular LLVM repositories who might forget to svn up. I'm very much willing to stand by that claim if you dispute it because I believe these logs have as much, or more, importance than the code they describe and I put real time and effort into them. Meanwhile, if you want to templatize, introduce variadic/perfect forwarding/smart pointers you can of course submit patches to the commits list like everyone else. Sure - as I said, don't really know how costly something is until I ask - I figured you knew, so all I was asking was to understand that, then you/I/anyone else can appro
r212512 - Headers: conditionalise more declarations
Author: compnerd
Date: Tue Jul 8 00:46:04 2014
New Revision: 212512
URL: http://llvm.org/viewvc/llvm-project?rev=212512&view=rev
Log:
Headers: conditionalise more declarations
Protect MMX specific declarations under a __MMX__ guard. This header can be
included on non-x86 architectures (e.g. ARM) which do not support the MMX ISA.
Use the preprocessor to prevent these declarations from being processed.
Added:
cfe/trunk/test/Headers/arm-intrin.c
Modified:
cfe/trunk/lib/Headers/Intrin.h
Modified: cfe/trunk/lib/Headers/Intrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=212512&r1=212511&r2=212512&view=diff
==
--- cfe/trunk/lib/Headers/Intrin.h (original)
+++ cfe/trunk/lib/Headers/Intrin.h Tue Jul 8 00:46:04 2014
@@ -41,12 +41,14 @@
extern "C" {
#endif
+#if defined(__MMX__)
/* And the random ones that aren't in those files. */
__m64 _m_from_float(float);
__m64 _m_from_int(int _l);
void _m_prefetch(void *);
float _m_to_float(__m64);
int _m_to_int(__m64 _M);
+#endif
/* Other assorted instruction intrinsics. */
void __addfsbyte(unsigned long, unsigned char);
Added: cfe/trunk/test/Headers/arm-intrin.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/arm-intrin.c?rev=212512&view=auto
==
--- cfe/trunk/test/Headers/arm-intrin.c (added)
+++ cfe/trunk/test/Headers/arm-intrin.c Tue Jul 8 00:46:04 2014
@@ -0,0 +1,6 @@
+// RUN: %clang -target armv7-windows -I %S/Inputs/include -Xclang -verify -E %s
+// expected-no-diagnostics
+
+typedef __SIZE_TYPE__ size_t;
+#include
+
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212511 - Headers: mark arm_acle.h with extern "C"
Author: compnerd
Date: Tue Jul 8 00:46:00 2014
New Revision: 212511
URL: http://llvm.org/viewvc/llvm-project?rev=212511&view=rev
Log:
Headers: mark arm_acle.h with extern "C"
Although the functions are marked as always_inline, the compiler with which they
are used may not honour the extended attributes and emit them as functions. In
such a case, indicate that they should have extern "C" linkage and should not be
mangled in C++ style if used within C++.
Modified:
cfe/trunk/lib/Headers/arm_acle.h
Modified: cfe/trunk/lib/Headers/arm_acle.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/arm_acle.h?rev=212511&r1=212510&r2=212511&view=diff
==
--- cfe/trunk/lib/Headers/arm_acle.h (original)
+++ cfe/trunk/lib/Headers/arm_acle.h Tue Jul 8 00:46:00 2014
@@ -30,6 +30,10 @@
#include
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
/* Miscellaneous data-processing intrinsics */
static __inline__ uint32_t __attribute__((always_inline, nodebug))
@@ -140,4 +144,8 @@ static __inline__ uint32_t __attribute__
}
#endif
+#if defined(__cplusplus)
+}
+#endif
+
#endif /* __ARM_ACLE_H */
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [libcxxabi] Add lit configs for libcxxabi tests.
Comment at: CMakeLists.txt:110
@@ +109,3 @@
+ else()
+set(LIBCXXABI_LIBCXX_INCLUDES "${LLVM_INCLUDE_DIR}/c++/v1")
+ endif()
Saleem Abdulrasool wrote:
> Dan Albert wrote:
> > Saleem Abdulrasool wrote:
> > > I think that you should use a separate variable (LIBCXX_INCLUDE_DIR
> > > perhaps?) that is set to ${CMAKE_CURRENT_BINARY_DIR}/include rather than
> > > relying on LLVM's variable.
> > >
> > > I realize that this is a standalone build, and therefore LLVM_INCLUDE_DIR
> > > *should* point to the same location, but it makes it something that you
> > > need to reason out (at least, I had to think about it for a moment).
> > I don't understand. ${CMAKE_CURRENT_BINARY_DIR}/include won't contain the
> > libcxx headers...
> AIUI, thats what it will be set to. It does actually get the headers copied
> there (at least, it did in my local tree).
Hmm. They aren't for mine. Not for a standalone build, anyway. I'm running
exactly the command from the docs.
http://reviews.llvm.org/D4414
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[PATCH] Do not define the gcc style target specific pre-defined preprocessor macros in clang-cl
Hi rnk, hansw,
http://reviews.llvm.org/D4415
Files:
lib/Basic/Targets.cpp
lib/Headers/Intrin.h
lib/Headers/ammintrin.h
lib/Headers/arm_acle.h
lib/Headers/emmintrin.h
lib/Headers/fmaintrin.h
lib/Headers/immintrin.h
lib/Headers/mmintrin.h
lib/Headers/nmmintrin.h
lib/Headers/pmmintrin.h
lib/Headers/smmintrin.h
lib/Headers/tmmintrin.h
lib/Headers/wmmintrin.h
lib/Headers/x86intrin.h
lib/Headers/xmmintrin.h
test/CodeGenCXX/mangle-ms-vector-types.cpp
test/Preprocessor/predefined-macros.c
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2588,6 +2588,31 @@
/// definitions for this particular subtarget.
void X86TargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
+ // None of these macros make sense in MSVC compat mode.
+ if (Opts.MicrosoftExt) {
+if (getTriple().getArch() == llvm::Triple::x86) {
+ switch (SSELevel) {
+ case AVX512F:
+ case AVX2:
+ case AVX:
+ case SSE42:
+ case SSE41:
+ case SSSE3:
+ case SSE3:
+ case SSE2:
+Builder.defineMacro("_M_IX86_FP", Twine(2));
+break;
+ case SSE1:
+Builder.defineMacro("_M_IX86_FP", Twine(1));
+break;
+ default:
+Builder.defineMacro("_M_IX86_FP", Twine(0));
+ }
+}
+
+return;
+ }
+
// Target identification.
if (getTriple().getArch() == llvm::Triple::x86_64) {
Builder.defineMacro("__amd64__");
@@ -2831,26 +2856,6 @@
break;
}
- if (Opts.MicrosoftExt && getTriple().getArch() == llvm::Triple::x86) {
-switch (SSELevel) {
-case AVX512F:
-case AVX2:
-case AVX:
-case SSE42:
-case SSE41:
-case SSSE3:
-case SSE3:
-case SSE2:
- Builder.defineMacro("_M_IX86_FP", Twine(2));
- break;
-case SSE1:
- Builder.defineMacro("_M_IX86_FP", Twine(1));
- break;
-default:
- Builder.defineMacro("_M_IX86_FP", Twine(0));
-}
- }
-
// Each case falls through to the previous one here.
switch (MMX3DNowLevel) {
case AMD3DNowAthlon:
@@ -4182,7 +4187,8 @@
: ARMTargetInfo(Triple, false) { }
virtual void getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
-Builder.defineMacro("__ARMEL__");
+if (!Opts.MSVCCompat)
+ Builder.defineMacro("__ARMEL__");
ARMTargetInfo::getTargetDefines(Opts, Builder);
}
};
@@ -4193,8 +4199,10 @@
: ARMTargetInfo(Triple, true) { }
virtual void getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
-Builder.defineMacro("__ARMEB__");
-Builder.defineMacro("__ARM_BIG_ENDIAN");
+if (!Opts.MSVCCompat) {
+ Builder.defineMacro("__ARMEB__");
+ Builder.defineMacro("__ARM_BIG_ENDIAN");
+}
ARMTargetInfo::getTargetDefines(Opts, Builder);
}
};
Index: lib/Headers/Intrin.h
===
--- lib/Headers/Intrin.h
+++ lib/Headers/Intrin.h
@@ -30,7 +30,7 @@
#define __INTRIN_H
/* First include the standard intrinsics. */
-#if defined(__i386__) || defined(__x86_64__)
+#if defined(__i386__) || defined(__x86_64__) || defined(_M_IX86) || defined(_M_X64)
#include
#endif
Index: lib/Headers/ammintrin.h
===
--- lib/Headers/ammintrin.h
+++ lib/Headers/ammintrin.h
@@ -24,7 +24,7 @@
#ifndef __AMMINTRIN_H
#define __AMMINTRIN_H
-#ifndef __SSE4A__
+#if !defined(__SSE4A__) && !defined(_MSC_VER)
#error "SSE4A instruction set not enabled"
#else
Index: lib/Headers/arm_acle.h
===
--- lib/Headers/arm_acle.h
+++ lib/Headers/arm_acle.h
@@ -24,7 +24,7 @@
#ifndef __ARM_ACLE_H
#define __ARM_ACLE_H
-#ifndef __ARM_ACLE
+#if !defined(__ARM_ACLE) && !defined(_MSC_VER)
#error "ACLE intrinsics support not enabled."
#endif
Index: lib/Headers/emmintrin.h
===
--- lib/Headers/emmintrin.h
+++ lib/Headers/emmintrin.h
@@ -24,7 +24,7 @@
#ifndef __EMMINTRIN_H
#define __EMMINTRIN_H
-#ifndef __SSE2__
+#if !defined(__SSE2__) && !defined(_MSC_VER)
#error "SSE2 instruction set not enabled"
#else
Index: lib/Headers/fmaintrin.h
===
--- lib/Headers/fmaintrin.h
+++ lib/Headers/fmaintrin.h
@@ -28,7 +28,7 @@
#ifndef __FMAINTRIN_H
#define __FMAINTRIN_H
-#ifndef __FMA__
+#if !defined(__FMA__) && !defined(_MSC_VER)
# error "FMA instruction set is not enabled"
#else
Index: lib/Headers/immintrin.h
===
--- lib/Headers/immintrin.h
+++ lib/Headers/immintrin.h
@@ -24,39 +24,39 @@
#ifndef __IMMINTRIN_H
#define __IMMINTRIN_H
-#ifdef __MMX__
+#if defined(__MMX_
Re: r212427 - libclang: refactor handling of unsaved_files
On Mon, Jul 7, 2014 at 9:14 PM, Alp Toker wrote:
>
> On 08/07/2014 06:27, David Blaikie wrote:
>>
>> Hi Alp,
>>
>> It looks like you responded to some of this code review in r212497.
>> Usually we follow up with a reply to the original review feedback and
>> mention the commit message where feedback was addressed (and explain
>> why unaddressed feedback was left as it was).
>
>
> I've explained the fixes already in detail within the commit log.
Without mention of the context, but that's OK (sometimes people prefer
to mention that the commit was motivated by code review, mentioning
the original revision, etc - helps provide breadcrumbs later), not
something I was commenting on.
> That
> commit was a couple of hours ago and I obviously intend to follow-up once
> remaining points are addressed..
Sorry about that - but it wasn't obvious to me. I seemed to recall
seeing this (code review feedback responded to, but lacking the trail
back to the original commit, etc) previously (perhaps from you,
perhaps others as well/instead - I don't know) & figured I'd comment
on it to help things along.
>> Anyway, I see you made the mutable member a reference instead. That
>> seems OK, but still a bit 'interesting' - do you know if there's any
>> reason the return value of clang_parseTranslationUnit_Impl wasn't used
>> for the result, or at least a separate reference parameter? (I'm not
>
>
> David, It's OK to ask questions, but but it's clear from what you've said
> above that you're not particularly familiar with the libclang process
> isolation model.
Not even in the slightest - wouldn't mind understanding. But if as it
pertains to the code review it might be sufficient to say "the system
here needs all the parameters wrapped in a single struct" (possibly
with a sentence about why), that doesn't seem terribly laborious, and
the code change you made seems great (the struct member types then
match what the argument types would be, if it weren't for this process
isolation mechanism/limitations).
>> sure why all the parameters, especially the result, were bundled into
>> a struct - I guess it might have to do with that RunSafely function?
>> Maybe it could be made variadic/perfect forwarding, if it isn't
>> already)
>
>
> The message structure is passed by pointer to an isolated thread to enable
> strong crash recovery. I'm sorry but we're *not* rewriting this any time
> soon, and especially not as part of a commit to consolidate unsaved_files.
No need to apologize - I was talking casually about what might be
possible, knowing very little about the limitations or how deep-seeded
or well justified they are. It's totally OK to say "yeah, it's this
way for a good reason and it's either not worth changing or worth
changing but requires a lot of work that's not a priority right now".
> You've sent me 10 emails today, often on topics that are tangential to the
> actual commits. You need to be aware that these aren't going to get same-day
> responses.
Sure - I just usually at least handle one email in its entirety - no
reason that's everyone else's process. As I said above, just thought
I'd recalled some other cases of code review responses without final
feedback/breadcrumbs. I may've misremembered.
> Meanwhile, if you want to templatize, introduce variadic/perfect
> forwarding/smart pointers you can of course submit patches to the commits
> list like everyone else.
Sure - as I said, don't really know how costly something is until I
ask - I figured you knew, so all I was asking was to understand that,
then you/I/anyone else can appropriately prioritize it.
Thanks,
- David
>
> Alp.
>
>
>
>>
>> On Mon, Jul 7, 2014 at 2:11 PM, David Blaikie wrote:
>>>
>>> On Sun, Jul 6, 2014 at 6:23 PM, Alp Toker wrote:
Author: alp
Date: Sun Jul 6 20:23:14 2014
New Revision: 212427
URL: http://llvm.org/viewvc/llvm-project?rev=212427&view=rev
Log:
libclang: refactor handling of unsaved_files
Consolidate CXUnsavedFile argument handling in API functions to support
a wider
cleanup of various file remapping schemes in the frontend.
Modified:
cfe/trunk/tools/libclang/CIndex.cpp
cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp
cfe/trunk/tools/libclang/CXString.h
cfe/trunk/tools/libclang/Indexing.cpp
Modified: cfe/trunk/tools/libclang/CIndex.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=212427&r1=212426&r2=212427&view=diff
==
--- cfe/trunk/tools/libclang/CIndex.cpp (original)
+++ cfe/trunk/tools/libclang/CIndex.cpp Sun Jul 6 20:23:14 2014
@@ -2727,21 +2727,18 @@ struct ParseTranslationUnitInfo {
const char *source_filename;
const char *const *command_line_args;
int num_command_line_args;
- struct CXUnsavedFile *unsaved_files;
- unsigned n
Re: r212427 - libclang: refactor handling of unsaved_files
On 08/07/2014 06:27, David Blaikie wrote:
Hi Alp,
It looks like you responded to some of this code review in r212497.
Usually we follow up with a reply to the original review feedback and
mention the commit message where feedback was addressed (and explain
why unaddressed feedback was left as it was).
I've explained the fixes already in detail within the commit log. That
commit was a couple of hours ago and I obviously intend to follow-up
once remaining points are addressed..
Anyway, I see you made the mutable member a reference instead. That
seems OK, but still a bit 'interesting' - do you know if there's any
reason the return value of clang_parseTranslationUnit_Impl wasn't used
for the result, or at least a separate reference parameter? (I'm not
David, It's OK to ask questions, but but it's clear from what you've
said above that you're not particularly familiar with the libclang
process isolation model.
sure why all the parameters, especially the result, were bundled into
a struct - I guess it might have to do with that RunSafely function?
Maybe it could be made variadic/perfect forwarding, if it isn't
already)
The message structure is passed by pointer to an isolated thread to
enable strong crash recovery. I'm sorry but we're *not* rewriting this
any time soon, and especially not as part of a commit to consolidate
unsaved_files.
You've sent me 10 emails today, often on topics that are tangential to
the actual commits. You need to be aware that these aren't going to get
same-day responses.
Meanwhile, if you want to templatize, introduce variadic/perfect
forwarding/smart pointers you can of course submit patches to the
commits list like everyone else.
Alp.
On Mon, Jul 7, 2014 at 2:11 PM, David Blaikie wrote:
On Sun, Jul 6, 2014 at 6:23 PM, Alp Toker wrote:
Author: alp
Date: Sun Jul 6 20:23:14 2014
New Revision: 212427
URL: http://llvm.org/viewvc/llvm-project?rev=212427&view=rev
Log:
libclang: refactor handling of unsaved_files
Consolidate CXUnsavedFile argument handling in API functions to support a wider
cleanup of various file remapping schemes in the frontend.
Modified:
cfe/trunk/tools/libclang/CIndex.cpp
cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp
cfe/trunk/tools/libclang/CXString.h
cfe/trunk/tools/libclang/Indexing.cpp
Modified: cfe/trunk/tools/libclang/CIndex.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=212427&r1=212426&r2=212427&view=diff
==
--- cfe/trunk/tools/libclang/CIndex.cpp (original)
+++ cfe/trunk/tools/libclang/CIndex.cpp Sun Jul 6 20:23:14 2014
@@ -2727,21 +2727,18 @@ struct ParseTranslationUnitInfo {
const char *source_filename;
const char *const *command_line_args;
int num_command_line_args;
- struct CXUnsavedFile *unsaved_files;
- unsigned num_unsaved_files;
+ ArrayRef unsaved_files;
unsigned options;
CXTranslationUnit *out_TU;
- CXErrorCode result;
+ mutable CXErrorCode result;
I haven't looked at the code in detail - but is there a one-sentence
summary of why the right pivot/design here is to have this field
mutable? (& similarly for another field or two that are becoming
mutable in this change)
};
static void clang_parseTranslationUnit_Impl(void *UserData) {
- ParseTranslationUnitInfo *PTUI =
-static_cast(UserData);
+ const ParseTranslationUnitInfo *PTUI =
+ static_cast(UserData);
If you like, you could add "const" to the cast and just use "auto *"
(or even plain "auto") on the LHS. (& similarly with some other
changes in this commit)
CXIndex CIdx = PTUI->CIdx;
const char *source_filename = PTUI->source_filename;
const char * const *command_line_args = PTUI->command_line_args;
int num_command_line_args = PTUI->num_command_line_args;
- struct CXUnsavedFile *unsaved_files = PTUI->unsaved_files;
- unsigned num_unsaved_files = PTUI->num_unsaved_files;
unsigned options = PTUI->options;
CXTranslationUnit *out_TU = PTUI->out_TU;
@@ -2751,8 +2748,7 @@ static void clang_parseTranslationUnit_I
PTUI->result = CXError_Failure;
// Check arguments.
- if (!CIdx || !out_TU ||
- (unsaved_files == nullptr && num_unsaved_files != 0)) {
+ if (!CIdx || !out_TU) {
PTUI->result = CXError_InvalidArguments;
return;
}
@@ -2789,12 +2785,10 @@ static void clang_parseTranslationUnit_I
llvm::CrashRecoveryContextCleanupRegistrar<
std::vector > RemappedCleanup(RemappedFiles.get());
- for (unsigned I = 0; I != num_unsaved_files; ++I) {
-StringRef Data(unsaved_files[I].Contents, unsaved_files[I].Length);
-llvm::MemoryBuffer *Buffer =
-llvm::MemoryBuffer::getMemBufferCopy(Data, unsaved_files[I].Filename);
-RemappedFiles->push_back(std::make_pair(unsaved_files[I].Filename,
-Buffer));
+ for (auto &UF : PTUI->unsaved_files) {
+llvm::MemoryBuffer *MB =
Re: [PATCH] [libcxxabi] Add lit configs for libcxxabi tests.
Comment at: CMakeLists.txt:104
@@ -103,2 +103,3 @@
option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
-option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." OFF)
+option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
+
Dan Albert wrote:
> Saleem Abdulrasool wrote:
> > Did you intend to make this shared by default?
> Yes. See the long part of the summary. I'm willing to change this back to the
> way it was if people think that's better.
I think moving the comment here would be better.
Comment at: CMakeLists.txt:110
@@ +109,3 @@
+ else()
+set(LIBCXXABI_LIBCXX_INCLUDES "${LLVM_INCLUDE_DIR}/c++/v1")
+ endif()
Dan Albert wrote:
> Saleem Abdulrasool wrote:
> > I think that you should use a separate variable (LIBCXX_INCLUDE_DIR
> > perhaps?) that is set to ${CMAKE_CURRENT_BINARY_DIR}/include rather than
> > relying on LLVM's variable.
> >
> > I realize that this is a standalone build, and therefore LLVM_INCLUDE_DIR
> > *should* point to the same location, but it makes it something that you
> > need to reason out (at least, I had to think about it for a moment).
> I don't understand. ${CMAKE_CURRENT_BINARY_DIR}/include won't contain the
> libcxx headers...
AIUI, thats what it will be set to. It does actually get the headers copied
there (at least, it did in my local tree).
Comment at: test/lit.cfg:1
@@ +1,2 @@
+# -*- Python -*- vim: set syntax=python tabstop=4 expandtab cc=80:
+
Dan Albert wrote:
> Saleem Abdulrasool wrote:
> > Is this the format that the rest of the python code in LLVM uses? I don't
> > really care at the end of the day, just curious.
> I assumed it was. I copied it from libcxx/test/lit.cfg. I'll look in to it.
>
> As a somewhat related note, there's a lot of redundancy between here and the
> lit.cfg in libcxx. It'd be nice to factor that out at some point...
WFM. As I said, it was more that I was just surprised. Sharing that would be
*great*.
http://reviews.llvm.org/D4414
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212427 - libclang: refactor handling of unsaved_files
Hi Alp,
It looks like you responded to some of this code review in r212497.
Usually we follow up with a reply to the original review feedback and
mention the commit message where feedback was addressed (and explain
why unaddressed feedback was left as it was).
Anyway, I see you made the mutable member a reference instead. That
seems OK, but still a bit 'interesting' - do you know if there's any
reason the return value of clang_parseTranslationUnit_Impl wasn't used
for the result, or at least a separate reference parameter? (I'm not
sure why all the parameters, especially the result, were bundled into
a struct - I guess it might have to do with that RunSafely function?
Maybe it could be made variadic/perfect forwarding, if it isn't
already)
On Mon, Jul 7, 2014 at 2:11 PM, David Blaikie wrote:
> On Sun, Jul 6, 2014 at 6:23 PM, Alp Toker wrote:
>> Author: alp
>> Date: Sun Jul 6 20:23:14 2014
>> New Revision: 212427
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212427&view=rev
>> Log:
>> libclang: refactor handling of unsaved_files
>>
>> Consolidate CXUnsavedFile argument handling in API functions to support a
>> wider
>> cleanup of various file remapping schemes in the frontend.
>>
>> Modified:
>> cfe/trunk/tools/libclang/CIndex.cpp
>> cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp
>> cfe/trunk/tools/libclang/CXString.h
>> cfe/trunk/tools/libclang/Indexing.cpp
>>
>> Modified: cfe/trunk/tools/libclang/CIndex.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=212427&r1=212426&r2=212427&view=diff
>> ==
>> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
>> +++ cfe/trunk/tools/libclang/CIndex.cpp Sun Jul 6 20:23:14 2014
>> @@ -2727,21 +2727,18 @@ struct ParseTranslationUnitInfo {
>>const char *source_filename;
>>const char *const *command_line_args;
>>int num_command_line_args;
>> - struct CXUnsavedFile *unsaved_files;
>> - unsigned num_unsaved_files;
>> + ArrayRef unsaved_files;
>>unsigned options;
>>CXTranslationUnit *out_TU;
>> - CXErrorCode result;
>> + mutable CXErrorCode result;
>
> I haven't looked at the code in detail - but is there a one-sentence
> summary of why the right pivot/design here is to have this field
> mutable? (& similarly for another field or two that are becoming
> mutable in this change)
>
>> };
>> static void clang_parseTranslationUnit_Impl(void *UserData) {
>> - ParseTranslationUnitInfo *PTUI =
>> -static_cast(UserData);
>> + const ParseTranslationUnitInfo *PTUI =
>> + static_cast(UserData);
>
> If you like, you could add "const" to the cast and just use "auto *"
> (or even plain "auto") on the LHS. (& similarly with some other
> changes in this commit)
>
>>CXIndex CIdx = PTUI->CIdx;
>>const char *source_filename = PTUI->source_filename;
>>const char * const *command_line_args = PTUI->command_line_args;
>>int num_command_line_args = PTUI->num_command_line_args;
>> - struct CXUnsavedFile *unsaved_files = PTUI->unsaved_files;
>> - unsigned num_unsaved_files = PTUI->num_unsaved_files;
>>unsigned options = PTUI->options;
>>CXTranslationUnit *out_TU = PTUI->out_TU;
>>
>> @@ -2751,8 +2748,7 @@ static void clang_parseTranslationUnit_I
>>PTUI->result = CXError_Failure;
>>
>>// Check arguments.
>> - if (!CIdx || !out_TU ||
>> - (unsaved_files == nullptr && num_unsaved_files != 0)) {
>> + if (!CIdx || !out_TU) {
>> PTUI->result = CXError_InvalidArguments;
>> return;
>>}
>> @@ -2789,12 +2785,10 @@ static void clang_parseTranslationUnit_I
>>llvm::CrashRecoveryContextCleanupRegistrar<
>> std::vector >
>> RemappedCleanup(RemappedFiles.get());
>>
>> - for (unsigned I = 0; I != num_unsaved_files; ++I) {
>> -StringRef Data(unsaved_files[I].Contents, unsaved_files[I].Length);
>> -llvm::MemoryBuffer *Buffer =
>> -llvm::MemoryBuffer::getMemBufferCopy(Data,
>> unsaved_files[I].Filename);
>> -RemappedFiles->push_back(std::make_pair(unsaved_files[I].Filename,
>> -Buffer));
>> + for (auto &UF : PTUI->unsaved_files) {
>> +llvm::MemoryBuffer *MB =
>> +llvm::MemoryBuffer::getMemBufferCopy(getContents(UF), UF.Filename);
>> +RemappedFiles->push_back(std::make_pair(UF.Filename, MB));
>>}
>>
>>std::unique_ptr> Args(
>> @@ -2895,10 +2889,18 @@ enum CXErrorCode clang_parseTranslationU
>>*Log << command_line_args[i] << " ";
>>}
>>
>> - ParseTranslationUnitInfo PTUI = { CIdx, source_filename,
>> command_line_args,
>> -num_command_line_args, unsaved_files,
>> -num_unsaved_files, options, out_TU,
>> -CXError_Failure };
>> + if (num_unsaved_files && !unsaved_files)
>> +return CXError_InvalidArguments;
>> +
>> + ParseTranslationUnitInfo PTUI = {
>> + CIdx
r212508 - MS ABI: "Fix" passing non-POD structs by value to variadic functions
Author: rnk
Date: Mon Jul 7 21:24:27 2014
New Revision: 212508
URL: http://llvm.org/viewvc/llvm-project?rev=212508&view=rev
Log:
MS ABI: "Fix" passing non-POD structs by value to variadic functions
Of course, such code is horribly broken and will explode on impact.
That said, ATL does it, and we have to support them, at least a little
bit.
Fixes PR20191.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-byval-vararg.cpp
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=212508&r1=212507&r2=212508&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Jul 7 21:24:27 2014
@@ -2859,28 +2859,33 @@ RValue CodeGenFunction::EmitCall(const C
if (ArgMemory) {
llvm::Value *Arg = ArgMemory;
-llvm::Type *LastParamTy =
-IRFuncTy->getParamType(IRFuncTy->getNumParams() - 1);
-if (Arg->getType() != LastParamTy) {
+if (CallInfo.isVariadic()) {
+ // When passing non-POD arguments by value to variadic functions, we will
+ // end up with a variadic prototype and an inalloca call site. In such
+ // cases, we can't do any parameter mismatch checks. Give up and bitcast
+ // the callee.
+ unsigned CalleeAS =
+ cast(Callee->getType())->getAddressSpace();
+ Callee = Builder.CreateBitCast(
+ Callee,
getTypes().GetFunctionType(CallInfo)->getPointerTo(CalleeAS));
+} else {
+ llvm::Type *LastParamTy =
+ IRFuncTy->getParamType(IRFuncTy->getNumParams() - 1);
+ if (Arg->getType() != LastParamTy) {
#ifndef NDEBUG
- // Assert that these structs have equivalent element types.
- llvm::StructType *FullTy = CallInfo.getArgStruct();
- llvm::StructType *Prefix = cast(
- cast(LastParamTy)->getElementType());
-
- // For variadic functions, the caller might supply a larger struct than
- // the callee expects, and that's OK.
- assert(Prefix->getNumElements() == FullTy->getNumElements() ||
- (CallInfo.isVariadic() &&
- Prefix->getNumElements() <= FullTy->getNumElements()));
-
- for (llvm::StructType::element_iterator PI = Prefix->element_begin(),
- PE = Prefix->element_end(),
- FI = FullTy->element_begin();
- PI != PE; ++PI, ++FI)
-assert(*PI == *FI);
+// Assert that these structs have equivalent element types.
+llvm::StructType *FullTy = CallInfo.getArgStruct();
+llvm::StructType *DeclaredTy = cast(
+cast(LastParamTy)->getElementType());
+assert(DeclaredTy->getNumElements() == FullTy->getNumElements());
+for (llvm::StructType::element_iterator DI =
DeclaredTy->element_begin(),
+DE = DeclaredTy->element_end(),
+FI = FullTy->element_begin();
+ DI != DE; ++DI, ++FI)
+ assert(*DI == *FI);
#endif
- Arg = Builder.CreateBitCast(Arg, LastParamTy);
+Arg = Builder.CreateBitCast(Arg, LastParamTy);
+ }
}
Args.push_back(Arg);
}
Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-byval-vararg.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-byval-vararg.cpp?rev=212508&r1=212507&r2=212508&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-byval-vararg.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-byval-vararg.cpp Mon Jul 7
21:24:27 2014
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -emit-llvm %s -o - -triple=i686-pc-win32
-mconstructor-aliases -fno-rtti | FileCheck %s
+// RUN: %clang_cc1 -Wno-non-pod-varargs -emit-llvm %s -o -
-triple=i686-pc-win32 -mconstructor-aliases -fno-rtti | FileCheck %s
#include
@@ -19,9 +19,34 @@ int foo(A a, ...) {
return sum;
}
+// CHECK-LABEL: define i32 @"\01?foo@@YAHUA@@ZZ"(<{ %struct.A }>* inalloca,
...)
+
int main() {
return foo(A(3), 1, 2, 3);
}
// CHECK-LABEL: define i32 @main()
-// CHECK: %[[argmem_cast:[^ ]*]] = bitcast <{ %struct.A, i32, i32, i32 }>*
%argmem to <{ %struct.A }>*
-// CHECK: call i32 (<{ %struct.A }>*, ...)* @"\01?foo@@YAHUA@@ZZ"(<{ %struct.A
}>* inalloca %[[argmem_cast]])
+// CHECK: %[[argmem:[^ ]*]] = alloca inalloca <{ %struct.A, i32, i32, i32 }>
+// CHECK: call i32 {{.*bitcast.*}}@"\01?foo@@YAHUA@@ZZ"{{.*}}(<{ %struct.A,
i32, i32, i32 }>* inalloca %[[argmem]])
+
+void varargs_zero(...);
+void varargs_one(int, ...);
+void varargs_two(int, int, ...);
+void varargs_three(int, int, int, ...);
+void call_var_args() {
+ A x(3);
+ varargs_zero(x);
+ varargs_one(1, x);
+ varargs_two(1, 2, x);
+ varargs_three(1, 2, 3, x);
+}
+
+// CHECK-LABEL: define void @"
Re: [PATCH] [libcxxabi] Add lit configs for libcxxabi tests.
Comment at: CMakeLists.txt:104
@@ -103,2 +103,3 @@
option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
-option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." OFF)
+option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
+
Saleem Abdulrasool wrote:
> Did you intend to make this shared by default?
Yes. See the long part of the summary. I'm willing to change this back to the
way it was if people think that's better.
Comment at: CMakeLists.txt:110
@@ +109,3 @@
+ else()
+set(LIBCXXABI_LIBCXX_INCLUDES "${LLVM_INCLUDE_DIR}/c++/v1")
+ endif()
Saleem Abdulrasool wrote:
> I think that you should use a separate variable (LIBCXX_INCLUDE_DIR perhaps?)
> that is set to ${CMAKE_CURRENT_BINARY_DIR}/include rather than relying on
> LLVM's variable.
>
> I realize that this is a standalone build, and therefore LLVM_INCLUDE_DIR
> *should* point to the same location, but it makes it something that you need
> to reason out (at least, I had to think about it for a moment).
I don't understand. ${CMAKE_CURRENT_BINARY_DIR}/include won't contain the
libcxx headers...
Comment at: test/lit.cfg:1
@@ +1,2 @@
+# -*- Python -*- vim: set syntax=python tabstop=4 expandtab cc=80:
+
Saleem Abdulrasool wrote:
> Is this the format that the rest of the python code in LLVM uses? I don't
> really care at the end of the day, just curious.
I assumed it was. I copied it from libcxx/test/lit.cfg. I'll look in to it.
As a somewhat related note, there's a lot of redundancy between here and the
lit.cfg in libcxx. It'd be nice to factor that out at some point...
http://reviews.llvm.org/D4414
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r211216 - CodeGen: improve ms instrincics support
On Fri, Jun 20, 2014 at 1:38 PM, Reid Kleckner wrote:
> Remember how I said it'd be OK if we provided
> _InterlockedCompareExchangePointer on x86? Well, doing that broke the
> sanitizers. Do 'check-asan' on 32-bit Windows to reproduce.
>
> This is the problematic code:
> inline static void *_InterlockedCompareExchangePointer(
> void *volatile *Destination,
> void *Exchange, void *Comparand) {
> return reinterpret_cast(
> _InterlockedCompareExchange(
> reinterpret_cast(Destination), // NOLINT
> reinterpret_cast(Exchange), // NOLINT
> reinterpret_cast(Comparand)));// NOLINT
> }
>
Ugh, seems that my message never got sent, it remained in the drafts :-(.
Thanks for submitting a fix for it Timur. I had the following conflict
which is why it never got addressed:
I seem to be having issues building check-asan, as in missing the target
:-(. However, since you were kind enough to provide the reduction of the
issue, it really helps.
Im conflicted on the best approach to solve this. We could either
a) filter this in FunctionDecl::getBuiltinID
b) not provide this in ASAN.
AIUI, ASAN does require instrumentation of code, so it would not be
possible to actually build ASAN enabled code reasonably with Visual Studio
at the moment. If I am mistaken on this point, Id love to know about that,
and in that case, we could wrap this in a #if !defined(__clang__) check.
Are there other similar builtins that we may have to isolate to specific
platforms? If so, it might be worth the effort to build up infrastructure
to handle this generically.
>
> On Wed, Jun 18, 2014 at 1:51 PM, Saleem Abdulrasool > wrote:
>
>> Author: compnerd
>> Date: Wed Jun 18 15:51:10 2014
>> New Revision: 211216
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=211216&view=rev
>> Log:
>> CodeGen: improve ms instrincics support
>>
>> Add support for _InterlockedCompareExchangePointer,
>> _InterlockExchangePointer,
>> _InterlockExchange. These are available as a compiler intrinsic on ARM
>> and x86.
>> These are used directly by the Windows SDK headers without use of the
>> intrin
>> header.
>>
>> Added:
>> cfe/trunk/test/CodeGen/ms-intrinsics.c
>> Modified:
>> cfe/trunk/include/clang/Basic/Builtins.def
>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> cfe/trunk/lib/Headers/Intrin.h
>>
>> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=211216&r1=211215&r2=211216&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>> +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Jun 18 15:51:10 2014
>> @@ -683,9 +683,12 @@ LANGBUILTIN(__noop, "v.", "n", AL
>> LANGBUILTIN(__debugbreak, "v", "n", ALL_MS_LANGUAGES)
>> LANGBUILTIN(__va_start, "vc**.", "nt", ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedCompareExchange, "LiLiD*LiLi", "n",
>> ALL_MS_LANGUAGES)
>> +LANGBUILTIN(_InterlockedCompareExchangePointer, "v*v*D*v*v*", "n",
>> ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedIncrement, "LiLiD*", "n", ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedDecrement, "LiLiD*", "n", ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedExchangeAdd, "LiLiD*Li", "n", ALL_MS_LANGUAGES)
>> +LANGBUILTIN(_InterlockedExchangePointer, "v*v*D*v*", "n",
>> ALL_MS_LANGUAGES)
>> +LANGBUILTIN(_InterlockedExchange, "LiLiD*Li", "n", ALL_MS_LANGUAGES)
>>
>> // C99 library functions
>> // C99 stdlib.h
>>
>> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=211216&r1=211215&r2=211216&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Jun 18 15:51:10 2014
>> @@ -1516,6 +1516,35 @@ RValue CodeGenFunction::EmitBuiltinExpr(
>> E->getArg(0), true);
>>case Builtin::BI__noop:
>> return RValue::get(nullptr);
>> + case Builtin::BI_InterlockedExchange:
>> + case Builtin::BI_InterlockedExchangePointer:
>> +return EmitBinaryAtomic(*this, llvm::AtomicRMWInst::Xchg, E);
>> + case Builtin::BI_InterlockedCompareExchangePointer: {
>> +llvm::Type *RTy;
>> +llvm::IntegerType *IntType =
>> + IntegerType::get(getLLVMContext(),
>> + getContext().getTypeSize(E->getType()));
>> +llvm::Type *IntPtrType = IntType->getPointerTo();
>> +
>> +llvm::Value *Destination =
>> + Builder.CreateBitCast(EmitScalarExpr(E->getArg(0)), IntPtrType);
>> +
>> +llvm::Value *Exchange = EmitScalarExpr(E->getArg(1));
>> +RTy = Exchange->getType();
>> +Exchange = Builder.CreatePtrToInt(Exchange, IntType);
>> +
>> +llvm::Value *Comparand =
>> + Builder.CreatePtrToInt(EmitScalarExpr(E->getArg(2)), IntType);
Re: [PATCH] [libcxxabi] Add lit configs for libcxxabi tests.
Comment at: CMakeLists.txt:104
@@ -103,2 +103,3 @@
option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
-option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." OFF)
+option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
+
Did you intend to make this shared by default?
Comment at: CMakeLists.txt:110
@@ +109,3 @@
+ else()
+set(LIBCXXABI_LIBCXX_INCLUDES "${LLVM_INCLUDE_DIR}/c++/v1")
+ endif()
I think that you should use a separate variable (LIBCXX_INCLUDE_DIR perhaps?)
that is set to ${CMAKE_CURRENT_BINARY_DIR}/include rather than relying on
LLVM's variable.
I realize that this is a standalone build, and therefore LLVM_INCLUDE_DIR
*should* point to the same location, but it makes it something that you need to
reason out (at least, I had to think about it for a moment).
Comment at: test/lit.cfg:1
@@ +1,2 @@
+# -*- Python -*- vim: set syntax=python tabstop=4 expandtab cc=80:
+
Is this the format that the rest of the python code in LLVM uses? I don't
really care at the end of the day, just curious.
http://reviews.llvm.org/D4414
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [AArch64] Implement Clang CLI interface proposal about "-march".
Ping again... 2014-07-03 16:26 GMT+08:00 Kevin Qin : > ping... Is any comment on this patch? > > > 2014-07-01 18:29 GMT+08:00 Renato Golin : > > On 1 July 2014 10:55, Kevin Qin wrote: >> > It's deprecated. Any use of "-mfpu" on AArch64 target will provide an >> > warning "argument unused during compilation" and won't block compiling >> > process. So most build systems can still work well except receiving a >> lot of >> > warnings. >> >> It might not block the compilation process, but it might break the >> linking process (build attributes, libraries), or change code >> generation, with regards to vectorization and optimizations. I agree >> this is not critical, but it's the kind of bug that is hard to find >> (as opposed to a compilation error), and the kind of warnings that >> people tend not to look at. >> >> I have no more arguments against the removal, and I don't feel too bad >> about it, but was just raising the issue. If people think it's for the >> best, I'll go with it. >> >> >> > Gcc can accept "-mcpu" with modifiers. >> >> Hum... ok, I had no idea, and from their docs, it's not clear also. In >> that case, fine by me. >> >> Thanks for threading this awkward minefield! I think Tim and others >> more involved in the AArch64 port should have a final look, but from >> what you discussed, I have no more objections. >> >> cheers, >> --renato >> > > > > -- > Best Regards, > > Kevin Qin > -- Best Regards, Kevin Qin ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212505 - [ASan] Completely remove sanitizer blacklist file from instrumentation pass.
Author: samsonov
Date: Mon Jul 7 19:50:49 2014
New Revision: 212505
URL: http://llvm.org/viewvc/llvm-project?rev=212505&view=rev
Log:
[ASan] Completely remove sanitizer blacklist file from instrumentation pass.
All blacklisting logic is now moved to the frontend (Clang).
If a function (or source file it is in) is blacklisted, it doesn't
get sanitize_address attribute and is therefore not instrumented.
If a global variable (or source file it is in) is blacklisted, it is
reported to be blacklisted by the entry in llvm.asan.globals metadata,
and is not modified by the instrumentation.
The latter may lead to certain false positives - not all the globals
created by Clang are described in llvm.asan.globals metadata (e.g,
RTTI descriptors are not), so we may start reporting errors on them
even if "module" they appear in is blacklisted. We assume it's fine
to take such risk:
1) errors on these globals are rare and usually indicate wild memory access
2) we can lazily add descriptors for these globals into llvm.asan.globals
lazily.
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=212505&r1=212504&r2=212505&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jul 7 19:50:49 2014
@@ -180,11 +180,8 @@ static void addBoundsCheckingPass(const
static void addAddressSanitizerPasses(const PassManagerBuilder &Builder,
PassManagerBase &PM) {
- const PassManagerBuilderWrapper &BuilderWrapper =
- static_cast(Builder);
- const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
PM.add(createAddressSanitizerFunctionPass());
- PM.add(createAddressSanitizerModulePass(CGOpts.SanitizerBlacklistFile));
+ PM.add(createAddressSanitizerModulePass());
}
static void addMemorySanitizerPass(const PassManagerBuilder &Builder,
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212138 - Driver: Handle /GR- in a compatible way with MSVC
ASAN replaces one internal global with another. Because the new symbol isn't in a Comdat, it's alias isn't either. This makes the alias a strong definition. On Mon, Jul 7, 2014 at 9:43 AM, Timur Iskhodzhanov wrote: > I think either this or r212125 broke "check-asan" and Chromium build but it > was hidden by another build failure (r211216). > > Can you please take a look at "TestCases/Windows/dll_cerr.cc" (or Chromium > failures) ? > > > 2014-07-02 2:24 GMT+04:00 David Majnemer : > >> Author: majnemer >> Date: Tue Jul 1 17:24:56 2014 >> New Revision: 212138 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=212138&view=rev >> Log: >> Driver: Handle /GR- in a compatible way with MSVC >> >> There are slight differences between /GR- and -fno-rtti which made >> mapping one to the other inappropriate. >> >> -fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related >> information for the v-table. >> >> /GR- does not generate complete object locators and thus will not >> reference them in vftables. However, constructs like dynamic_cast and >> typeid are permitted. >> >> This should bring our implementation of RTTI up to semantic parity with >> MSVC modulo bugs. >> >> Added: >> cfe/trunk/test/CodeGenCXX/microsoft-no-rtti-data.cpp >> Modified: >> cfe/trunk/include/clang/Basic/LangOptions.def >> cfe/trunk/include/clang/Driver/CC1Options.td >> cfe/trunk/include/clang/Driver/CLCompatOptions.td >> cfe/trunk/lib/AST/VTableBuilder.cpp >> cfe/trunk/lib/Basic/Targets.cpp >> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp >> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp >> cfe/trunk/lib/Driver/Tools.cpp >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp >> cfe/trunk/test/Driver/cl-fallback.c >> cfe/trunk/test/Driver/cl-options.c >> >> Modified: cfe/trunk/include/clang/Basic/LangOptions.def >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=212138&r1=212137&r2=212138&view=diff >> >> == >> --- cfe/trunk/include/clang/Basic/LangOptions.def (original) >> +++ cfe/trunk/include/clang/Basic/LangOptions.def Tue Jul 1 17:24:56 2014 >> @@ -84,6 +84,7 @@ LANGOPT(CXXExceptions , 1, 0, "C++ e >> LANGOPT(SjLjExceptions, 1, 0, "setjmp-longjump exception handling") >> LANGOPT(TraditionalCPP, 1, 0, "traditional CPP emulation") >> LANGOPT(RTTI , 1, 1, "run-time type information") >> +LANGOPT(RTTIData , 1, 1, "emit run-time type information data") >> LANGOPT(MSBitfields , 1, 0, "Microsoft-compatible structure >> layout") >> LANGOPT(Freestanding, 1, 0, "freestanding implementation") >> LANGOPT(NoBuiltin , 1, 0, "disable builtin functions") >> >> Modified: cfe/trunk/include/clang/Driver/CC1Options.td >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=212138&r1=212137&r2=212138&view=diff >> >> == >> --- cfe/trunk/include/clang/Driver/CC1Options.td (original) >> +++ cfe/trunk/include/clang/Driver/CC1Options.td Tue Jul 1 17:24:56 2014 >> @@ -484,6 +484,8 @@ def fobjc_subscripting_legacy_runtime : >>HelpText<"Allow Objective-C array and dictionary subscripting in legacy >> runtime">; >> def vtordisp_mode_EQ : Joined<["-"], "vtordisp-mode=">, >>HelpText<"Control vtordisp placement on win32 targets">; >> +def fno_rtti_data : Flag<["-"], "fno-rtti-data">, >> + HelpText<"Control emission of RTTI data">; >> >> >> //===--===// >> // Header Search Options >> >> Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=212138&r1=212137&r2=212138&view=diff >> >> == >> --- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original) >> +++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Jul 1 17:24:56 >> 2014 >> @@ -58,8 +58,8 @@ def _SLASH_c : CLFlag<"c">, HelpText<"Co >> def _SLASH_D : CLJoinedOrSeparate<"D">, HelpText<"Define macro">, >>MetaVarName<"">, Alias; >> def _SLASH_E : CLFlag<"E">, HelpText<"Preprocess to stdout">, Alias; >> -def _SLASH_GR : CLFlag<"GR">, HelpText<"Enable RTTI">, Alias; >> -def _SLASH_GR_ : CLFlag<"GR-">, HelpText<"Disable RTTI">, >> Alias; >> +def _SLASH_GR : CLFlag<"GR">, HelpText<"Enable emission of RTTI data">; >> +def _SLASH_GR_ : CLFlag<"GR-">, HelpText<"Disable emission of RTTI >> data">; >> def _SLASH_GF_ : CLFlag<"GF-">, HelpText<"Disable string pooling">, >>Alias; >> def _SLASH_Gy : CLFlag<"Gy">, HelpText<"Put each function in its own >> section">, >> >> Modified: cfe/trunk/lib/AST/VTableBuilder.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=212138&r1=212137&r2
[PATCH] [libcxxabi] Add lit configs for libcxxabi tests.
This makes running libcxxabi tests on Linux _much_ easier.
Adds a check-libcxxabi target to cmake.
Also defaults to building a dynamic libc++abi. This is so that the
default options still test the libc++abi that is being built. There are
two problems with testing a static libc++abi. In the case of a
standalone build, the tests will link the system's libc++, which might
not have been built against our libc++abi. In the case of an in tree
build, libc++ will prefer a dynamic libc++abi from the system over a
static libc++abi from the output directory.
http://reviews.llvm.org/D4414
Files:
CMakeLists.txt
src/CMakeLists.txt
test/CMakeLists.txt
test/lit.cfg
test/lit.site.cfg.in
www/index.html
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -101,7 +101,18 @@
option(LIBCXXABI_ENABLE_ASSERTIONS "Enable assertions independent of build mode." ON)
option(LIBCXXABI_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
-option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." OFF)
+option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
+
+if (NOT LIBCXXABI_LIBCXX_INCLUDES)
+ if (NOT LIBCXXABI_BUILT_STANDALONE)
+set(LIBCXXABI_LIBCXX_INCLUDES "${LLVM_MAIN_SRC_DIR}/projects/libcxx/include")
+ else()
+set(LIBCXXABI_LIBCXX_INCLUDES "${LLVM_INCLUDE_DIR}/c++/v1")
+ endif()
+endif()
+
+set(LIBCXXABI_LIBCXX_INCLUDES "${LIBCXXABI_LIBCXX_INCLUDES}" CACHE STRING
+"Specify path to libc++ includes." FORCE)
#===
# Configure System
@@ -210,3 +221,16 @@
# Add source code. This also contains all of the logic for deciding linker flags
# soname, etc...
add_subdirectory(src)
+
+if(NOT LIBCXXABI_ENABLE_SHARED)
+ # TODO: Fix the libc++ cmake files so that libc++abi can be statically linked.
+ # As it is now, libc++ will prefer linking against a dynamic libc++abi in the
+ # system library paths over a static libc++abi in the out directory. This
+ # would test the system library rather than the one we just built, which isn't
+ # very helpful.
+ message(WARNING "The libc++abi tests are currently only valid when "
+ "LIBCXXABI_ENABLE_SHARED is on, no check target will be "
+ "available!")
+else()
+ add_subdirectory(test)
+endif()
Index: src/CMakeLists.txt
===
--- src/CMakeLists.txt
+++ src/CMakeLists.txt
@@ -48,13 +48,7 @@
)
endif()
-if (LIBCXXABI_LIBCXX_INCLUDES)
- include_directories("${LIBCXXABI_LIBCXX_INCLUDES}")
-elseif (NOT LIBCXXABI_BUILT_STANDALONE)
- include_directories("${LLVM_MAIN_SRC_DIR}/projects/libcxx/include")
-else()
- include_directories("${LLVM_INCLUDE_DIR}/c++/v1")
-endif()
+include_directories("${LIBCXXABI_LIBCXX_INCLUDES}")
# Generate library list.
set(libraries ${LIBCXXABI_CXX_ABI_LIBRARIES})
Index: test/CMakeLists.txt
===
--- /dev/null
+++ test/CMakeLists.txt
@@ -0,0 +1,53 @@
+macro(pythonize_bool var)
+ if (${var})
+set(${var} True)
+ else()
+set(${var} False)
+ endif()
+endmacro()
+
+include(FindPythonInterp)
+if(PYTHONINTERP_FOUND)
+ if(LIBCXXABI_BUILT_STANDALONE)
+set(LIT_EXECUTABLE "" CACHE FILEPATH "Path to LLVM's lit.py.")
+ else()
+set(LIT_EXECUTABLE "${CMAKE_SOURCE_DIR}/utils/lit/lit.py")
+ endif()
+
+ set(LIT_ARGS "${LLVM_LIT_ARGS}")
+ separate_arguments(LIT_ARGS)
+
+ set(LIBCXXABI_COMPILER ${CMAKE_CXX_COMPILER})
+ set(LIBCXXABI_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/..)
+ set(LIBCXXABI_BINARY_DIR ${CMAKE_BINARY_DIR})
+ set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
+ pythonize_bool(LIBCXXABI_ENABLE_SHARED)
+
+ set(AUTO_GEN_COMMENT "## Autogenerated by libcxxabi configuration.\n# Do not edit!")
+
+ configure_file(
+${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
+${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+@ONLY)
+
+ if (LIBCXXABI_BUILT_STANDALONE)
+add_custom_target(check-libcxxabi
+ COMMAND ${PYTHON_EXECUTABLE}
+ ${LIT_EXECUTABLE}
+ ${LIT_ARGS}
+ ${CMAKE_CURRENT_BINARY_DIR}
+ DEPENDS cxxabi
+ COMMENT "Running libcxxabi tests")
+ else()
+add_custom_target(check-libcxxabi
+ COMMAND ${PYTHON_EXECUTABLE}
+ ${LIT_EXECUTABLE}
+ ${LIT_ARGS}
+ ${CMAKE_CURRENT_BINARY_DIR}
+ DEPENDS cxxabi
+ DEPENDS cxx
+ COMMENT "Running libcxxabi tests")
+ endif()
+else()
+ message(WARNING "Could not find Python, no check target will be available!")
+endif()
Index: test/lit.cfg
===
--- /dev/null
+++ test/lit.cfg
@@ -0,0 +1,236 @@
+# -*- Python -*- vim: set syntax=python tabstop=4 expandtab cc=80:
+
+# Configuration file for the 'lit' t
Re: [PATCH] [libcxxabi] Add lit configs for libcxxabi tests.
Comment at: test/CMakeLists.txt:41 @@ +40,3 @@ + COMMENT "Running libcxxabi tests") + else() +add_custom_target(check-libcxxabi The only thing this conditional is doing is adding an additional dependency on libc++ if we're building in tree... is there a way to add a dependency to a custom target after add_custom_target has been called? http://reviews.llvm.org/D4414 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Add support for unroll pragma
- Original Message -
> From: "Mark Heffernan"
> To: "Aaron Ballman"
> Cc: reviews+d4297+public+26d6caf125d42...@reviews.llvm.org, "Eli Bendersky"
> , "Tyler Nowicki"
> , "Peter Collingbourne" , "Hal Finkel"
> , "llvm cfe"
> , "Richard Smith" , "Chandler
> Carruth"
> Sent: Monday, July 7, 2014 5:52:33 PM
> Subject: Re: [PATCH] Add support for unroll pragma
>
>
>
>
> On Wed, Jul 2, 2014 at 7:54 AM, Aaron Ballman <
> aaron.ball...@gmail.com > wrote:
>
>
>
> I may have led you slightly astray on this point. I believe the
> consensus wound up being that having two different syntaxes for the
> same thing was okay, and so #pragma loop unroll[_count] should
> remain.
> Richard, Chandler, do I have that correct?
>
>
>
> I think Richard and Chandler (correct me if I'm wrong) were referring
> to supporting the following "#pragma unroll" syntaxes for
> compatibility purposes:
>
>
> #pragma unroll // CUDA, intel, and IBM
> #pragma unroll N // CUDA
> #pragma unroll(N) // intel and IBM
>
>
> However, not much has been said about, in addition, continuing to
> support the newly added form in the clang pragma namespace:
>
>
> #pragma clang loop unroll(...) unroll_count(...)
>
>
> Since you initially voiced objection to having two forms with
> identical semantics, I've come around and agree. That is, I think we
> should drop support for the "#pragma clang loop unroll" syntax and
> only support the "#pragma unroll" one.
I strongly disagree. clang now has a single self-consistent syntax for loop
optimization hints. This includes vectorization, interleaving and unrolling
(and could include other things in the future). This is not a bad thing. For
compatibility with other compilers we might also support other syntaxes, but
having to tell users that #pragma clang loop bla is the way to provide loop
optimization hints, except for unrolling which has its own special syntax, will
only cause confusion.
-Hal
>
>
> Mark
>
>
>
>
> Some comments:
>
> > Index: docs/LanguageExtensions.rst
> > ===
> > --- docs/LanguageExtensions.rst
> > +++ docs/LanguageExtensions.rst
> > @@ -1767,15 +1767,10 @@
> >
> > Extensions for loop hint optimizations
> > ==
> > -
> > The ``#pragma clang loop`` directive is used to specify hints for
> > optimizing the
> > subsequent for, while, do-while, or c++11 range-based for loop. The
> > directive
> > -provides options for vectorization, interleaving, and unrolling.
> > Loop hints can
> > -be specified before any loop and will be ignored if the
> > optimization is not safe
> > -to apply.
> > -
> > -Vectorization and Interleaving
> > ---
> > +provides options for vectorization and interleaving. Loop hints
> > can be specified
> > +before any loop and will be ignored if the optimization is not
> > safe to apply.
> >
> > A vectorized loop performs multiple iterations of the original loop
> > in parallel using vector instructions. The instruction set of the
> > target
> > @@ -1818,43 +1813,6 @@
> > Specifying a width/count of 1 disables the optimization, and is
> > equivalent to
> > ``vectorize(disable)`` or ``interleave(disable)``.
> >
> > -Loop Unrolling
> > ---
> > -
> > -Unrolling a loop reduces the loop control overhead and exposes
> > more
> > -opportunities for ILP. Loops can be fully or partially unrolled.
> > Full unrolling
> > -eliminates the loop and replaces it with an enumerated sequence of
> > loop
> > -iterations. Full unrolling is only possible if the loop trip count
> > is known at
> > -compile time. Partial unrolling replicates the loop body within
> > the loop and
> > -reduces the trip count.
> > -
> > -If ``unroll(enable)`` is specified the unroller will attempt to
> > fully unroll the
> > -loop if the trip count is known at compile time. If the loop count
> > is not known
> > -or the fully unrolled code size is greater than the limit
> > specified by the
> > -`-pragma-unroll-threshold` command line option the loop will be
> > partially
> > -unrolled subject to the same limit.
> > -
> > -.. code-block:: c++
> > -
> > - #pragma clang loop unroll(enable)
> > - for(...) {
> > - ...
> > - }
> > -
> > -The unroll count can be specified explicitly with
> > ``unroll_count(_value_)`` where
> > -_value_ is a positive integer. If this value is greater than the
> > trip count the
> > -loop will be fully unrolled. Otherwise the loop is partially
> > unrolled subject
> > -to the `-pragma-unroll-threshold` limit.
> > -
> > -.. code-block:: c++
> > -
> > - #pragma clang loop unroll_count(8)
> > - for(...) {
> > - ...
> > - }
> > -
> > -Unrolling of a loop can be prevented by specifying
> > ``unroll(disable)``.
> > -
> > Additional Information
> > --
> >
> > Index: docs/ReleaseNotes.rst
> > ===
> > --- docs/ReleaseNotes.rst
> > +++ docs/Rel
Re: [PATCH] Add support for CUDA unroll pragma
- Original Message -
> From: "Mark Heffernan"
> To: "Richard Smith"
> Cc: reviews+d4297+public+26d6caf125d42...@reviews.llvm.org, "Aaron Ballman"
> , "llvm cfe"
>
> Sent: Monday, July 7, 2014 6:12:00 PM
> Subject: Re: [PATCH] Add support for CUDA unroll pragma
>
>
>
>
>
> On Tue, Jul 1, 2014 at 5:36 PM, Richard Smith < rich...@metafoo.co.uk
> > wrote:
>
>
>
>
>
>
>
> One question: you list the unroll count as 'n'. Must that be a
> constant integer? The clang pragma intends to allow an arbitrary
> integer constant expression there. That might be a good reason for
> us to introduce our own syntax for it, if we're providing a slightly
> more general form.
>
>
>
> nvcc (CUDA) only supports a literal integer constant. icc seems to
> support only literal constants as well. xlc supports integer
> constant expressions. Given xlc and icc share the same syntax
> ("#pragma unroll (_value_)") there is no way to be perfectly
> compatible with both icc and xlc so I'm inclined to support
> expressions in "#pragma unroll" as planned with the other loop
> pragmas and just be more permissive than nvcc and icc.
At least in CUDA mode, we may want to issue a warning for non-literal-constants.
-Hal
>
>
> Mark
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212502 - Rename static function to better describe its purpose
Author: alp
Date: Mon Jul 7 19:02:05 2014
New Revision: 212502
URL: http://llvm.org/viewvc/llvm-project?rev=212502&view=rev
Log:
Rename static function to better describe its purpose
Modified:
cfe/trunk/lib/Sema/SemaType.cpp
Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=212502&r1=212501&r2=212502&view=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Mon Jul 7 19:02:05 2014
@@ -2040,9 +2040,9 @@ static void diagnoseIgnoredQualifiers(
}
// Diagnose pointless type qualifiers on the return type of a function.
-static void diagnoseIgnoredFunctionQualifiers(Sema &S, QualType RetTy,
- Declarator &D,
- unsigned FunctionChunkIndex) {
+static void diagnoseRedundantReturnTypeQualifiers(Sema &S, QualType RetTy,
+ Declarator &D,
+ unsigned FunctionChunkIndex)
{
if (D.getTypeObject(FunctionChunkIndex).Fun.hasTrailingReturnType()) {
// FIXME: TypeSourceInfo doesn't preserve location information for
// qualifiers.
@@ -2788,7 +2788,7 @@ static TypeSourceInfo *GetFullTypeForDec
if ((T.getCVRQualifiers() || T->isAtomicType()) &&
!(S.getLangOpts().CPlusPlus &&
(T->isDependentType() || T->isRecordType(
-diagnoseIgnoredFunctionQualifiers(S, T, D, chunkIndex);
+diagnoseRedundantReturnTypeQualifiers(S, T, D, chunkIndex);
// Objective-C ARC ownership qualifiers are ignored on the function
// return type (by type canonicalization). Complain if this attribute
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212501 - [Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code.
Author: samsonov
Date: Mon Jul 7 18:59:57 2014
New Revision: 212501
URL: http://llvm.org/viewvc/llvm-project?rev=212501&view=rev
Log:
[Sanitizer] Remove brittle cache variable and slightly simplify blacklisting
code.
Now CodeGenFunction is responsible for looking at sanitizer blacklist
(in CodeGenFunction::StartFunction) and turning off instrumentation,
if necessary.
No functionality change.
Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/CodeGenModule.h
Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=212501&r1=212500&r2=212501&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Jul 7 18:59:57 2014
@@ -407,7 +407,7 @@ CodeGenFunction::EmitReferenceBindingToE
assert(LV.isSimple());
llvm::Value *Value = LV.getAddress();
- if (SanitizePerformTypeCheck && !E->getType()->isFunctionType()) {
+ if (sanitizePerformTypeCheck() && !E->getType()->isFunctionType()) {
// C++11 [dcl.ref]p5 (as amended by core issue 453):
// If a glvalue to which a reference is directly bound designates neither
// an existing object or function of an appropriate type nor a region of
@@ -441,10 +441,15 @@ static llvm::Value *emitHash16Bytes(CGBu
return Builder.CreateMul(B1, KMul);
}
+bool CodeGenFunction::sanitizePerformTypeCheck() const {
+ return SanOpts->Null | SanOpts->Alignment | SanOpts->ObjectSize |
+ SanOpts->Vptr;
+}
+
void CodeGenFunction::EmitTypeCheck(TypeCheckKind TCK, SourceLocation Loc,
llvm::Value *Address,
QualType Ty, CharUnits Alignment) {
- if (!SanitizePerformTypeCheck)
+ if (!sanitizePerformTypeCheck())
return;
// Don't check pointers outside the default address space. The null check
@@ -2877,7 +2882,7 @@ LValue CodeGenFunction::EmitCastLValue(c
// C++11 [expr.static.cast]p2: Behavior is undefined if a downcast is
// performed and the object is not of the derived type.
-if (SanitizePerformTypeCheck)
+if (sanitizePerformTypeCheck())
EmitTypeCheck(TCK_DowncastReference, E->getExprLoc(),
Derived, E->getType());
Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprScalar.cpp?rev=212501&r1=212500&r2=212501&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Mon Jul 7 18:59:57 2014
@@ -1328,7 +1328,7 @@ Value *ScalarExprEmitter::VisitCastExpr(
// C++11 [expr.static.cast]p11: Behavior is undefined if a downcast is
// performed and the object is not of the derived type.
-if (CGF.SanitizePerformTypeCheck)
+if (CGF.sanitizePerformTypeCheck())
CGF.EmitTypeCheck(CodeGenFunction::TCK_DowncastPointer, CE->getExprLoc(),
Derived, DestTy->getPointeeType());
Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=212501&r1=212500&r2=212501&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Mon Jul 7 18:59:57 2014
@@ -37,11 +37,7 @@ CodeGenFunction::CodeGenFunction(CodeGen
: CodeGenTypeCache(cgm), CGM(cgm), Target(cgm.getTarget()),
Builder(cgm.getModule().getContext(), llvm::ConstantFolder(),
CGBuilderInserterTy(this)), CapturedStmtInfo(nullptr),
- SanitizePerformTypeCheck(CGM.getSanOpts().Null |
- CGM.getSanOpts().Alignment |
- CGM.getSanOpts().ObjectSize |
- CGM.getSanOpts().Vptr),
- SanOpts(&CGM.getSanOpts()), AutoreleaseResult(false), BlockInfo(nullptr),
+ SanOpts(&CGM.getLangOpts().Sanitize), AutoreleaseResult(false),
BlockInfo(nullptr),
BlockPointer(nullptr), LambdaThisCaptureField(nullptr),
NormalCleanupDest(nullptr), NextCleanupDestIndex(1),
FirstBlockInfo(nullptr), EHResumeBlock(nullptr), ExceptionSlot(nullptr),
@@ -539,10 +535,8 @@ void CodeGenFunction::StartFunction(Glob
CurFnInfo = &FnInfo;
assert(CurFn->isDeclaration() && "Function already has body?");
- if (CGM.getSanitizerBlacklist().isIn(*Fn)) {
+ if (CGM.getSanitizerBlacklist().isIn(*Fn))
SanOpts = &SanitizerOptions::Disabled;
-SanitizePerformTypeCheck = false;
- }
// Pass inline keyword to optimizer if it appears explicitly on any
// declaration. Also, in the case of -fno-inline a
Re: [PATCH] gcc compatibility: silent -finline-limit=1234 & -finline-limit
On 08/07/2014 00:30, Reid Kleckner wrote: One alternative is to recognize the flag, but warn on it. An easy way to do this with a poor diagnostic experience is to simply add it to our option table, don't put it into clang_ignored_f_Group, and don't check it in the driver. Clang will emit 'warning: argument unused during compilation '-finline-limit=1234''. For extra credit, we could have a diagnostic like "ignoring GCC optimization tuning flag" and use that for all GCC optimization flags that don't have analogues in Clang/LLVM. Reid, this is an *excellent* idea. Such a tablegen flag could be applied to this -finline-limit= flag and most of the other currently silently ignored ones. It was never cool that we silently ignored these and it's about time to change that. Arthur, adding a Group plus warning sounds like a much better use of time than trying to implement the feature in LLVM as I suggested, and will educate users with improved QOI. Incidentally, do you have any means of collecting compiler warnings emitted during a full rebuild of Debian? That would be pretty interesting, and let you remove -Werror to get things building in more cases without losing valuable diagnostics. Alp. Comment at: include/clang/Driver/Options.td:1561 @@ -1560,2 +1560,3 @@ defm implicit_templates : BooleanFFlag<"implicit-templates">, Group; +def inline_limit_EQ : Joined<["-"], "finline-limit=">, Group; defm inline_limit : BooleanFFlag<"inline-limit">, Group; This should be finline_limit_EQ. http://reviews.llvm.org/D4376 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits -- http://www.nuanti.com the browser experts ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] CodeGen: Let arrays be inputs to inline asm
- Remove changes from CodeGen.
http://reviews.llvm.org/D4382
Files:
lib/Sema/SemaStmtAsm.cpp
test/CodeGen/asm.c
test/CodeGen/x86-64-inline-asm.c
Index: lib/Sema/SemaStmtAsm.cpp
===
--- lib/Sema/SemaStmtAsm.cpp
+++ lib/Sema/SemaStmtAsm.cpp
@@ -152,6 +152,12 @@
diag::err_asm_invalid_lvalue_in_input)
<< Info.getConstraintStr()
<< InputExpr->getSourceRange());
+} else {
+ ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
+ if (Result.isInvalid())
+return StmtError();
+
+ Exprs[i] = Result.get();
}
if (Info.allowsRegister()) {
@@ -163,11 +169,6 @@
}
}
-ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
-if (Result.isInvalid())
- return StmtError();
-
-Exprs[i] = Result.get();
InputConstraintInfos.push_back(Info);
const Type *Ty = Exprs[i]->getType().getTypePtr();
Index: test/CodeGen/asm.c
===
--- test/CodeGen/asm.c
+++ test/CodeGen/asm.c
@@ -239,3 +239,12 @@
// CHECK: call void asm sideeffect "/* $0 */",
"i|r,~{dirflag},~{fpsr},~{flags}"(i32 1)
}
+static unsigned t29_var[1];
+
+void t29(void) {
+ asm volatile("movl %%eax, %0"
+ :
+ : "m"(t29_var));
+ // CHECK: @t29
+ // CHECK: call void asm sideeffect "movl %eax, $0",
"*m,~{dirflag},~{fpsr},~{flags}"([1 x i32]* @t29_var)
+}
Index: test/CodeGen/x86-64-inline-asm.c
===
--- test/CodeGen/x86-64-inline-asm.c
+++ test/CodeGen/x86-64-inline-asm.c
@@ -10,3 +10,8 @@
// expected-error@-5 {{scale factor without index register is ignored}}
#endif
}
+
+static unsigned var[1] = {};
+void g(void) { asm volatile("movd %%xmm0, %0"
+:
+: "m"(var)); }
Index: lib/Sema/SemaStmtAsm.cpp
===
--- lib/Sema/SemaStmtAsm.cpp
+++ lib/Sema/SemaStmtAsm.cpp
@@ -152,6 +152,12 @@
diag::err_asm_invalid_lvalue_in_input)
<< Info.getConstraintStr()
<< InputExpr->getSourceRange());
+} else {
+ ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
+ if (Result.isInvalid())
+return StmtError();
+
+ Exprs[i] = Result.get();
}
if (Info.allowsRegister()) {
@@ -163,11 +169,6 @@
}
}
-ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
-if (Result.isInvalid())
- return StmtError();
-
-Exprs[i] = Result.get();
InputConstraintInfos.push_back(Info);
const Type *Ty = Exprs[i]->getType().getTypePtr();
Index: test/CodeGen/asm.c
===
--- test/CodeGen/asm.c
+++ test/CodeGen/asm.c
@@ -239,3 +239,12 @@
// CHECK: call void asm sideeffect "/* $0 */", "i|r,~{dirflag},~{fpsr},~{flags}"(i32 1)
}
+static unsigned t29_var[1];
+
+void t29(void) {
+ asm volatile("movl %%eax, %0"
+ :
+ : "m"(t29_var));
+ // CHECK: @t29
+ // CHECK: call void asm sideeffect "movl %eax, $0", "*m,~{dirflag},~{fpsr},~{flags}"([1 x i32]* @t29_var)
+}
Index: test/CodeGen/x86-64-inline-asm.c
===
--- test/CodeGen/x86-64-inline-asm.c
+++ test/CodeGen/x86-64-inline-asm.c
@@ -10,3 +10,8 @@
// expected-error@-5 {{scale factor without index register is ignored}}
#endif
}
+
+static unsigned var[1] = {};
+void g(void) { asm volatile("movd %%xmm0, %0"
+:
+: "m"(var)); }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] CodeGen: Don't emit a thread-wrapper if we can't touch the backing variable
- Address review comments.
http://reviews.llvm.org/D4109
Files:
lib/CodeGen/ItaniumCXXABI.cpp
test/CodeGenCXX/tls-init-funcs.cpp
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -1818,6 +1818,15 @@
CGF.registerGlobalDtorWithAtExit(D, dtor, addr);
}
+static bool isThreadWrapperReplaceable(const VarDecl *VD,
+ CodeGen::CodeGenModule &CGM) {
+ assert(!VD->isStaticLocal() && "static local VarDecls don't need wrappers!");
+ // OS X prefers to have references to thread local variables to go through
+ // the thread wrapper instead of directly referencing the backing variable.
+ return VD->getTLSKind() == VarDecl::TLS_Dynamic &&
+ CGM.getTarget().getTriple().isMacOSX();
+}
+
/// Get the appropriate linkage for the wrapper function. This is essentially
/// the weak form of the variable's linkage; every translation unit which needs
/// the wrapper emits a copy, and we want the linker to merge them.
@@ -1830,12 +1839,14 @@
if (llvm::GlobalValue::isLocalLinkage(VarLinkage))
return VarLinkage;
- // All accesses to the thread_local variable go through the thread wrapper.
- // However, this means that we cannot allow the thread wrapper to get inlined
- // into any functions.
- if (VD->getTLSKind() == VarDecl::TLS_Dynamic &&
- CGM.getTarget().getTriple().isMacOSX())
-return llvm::GlobalValue::WeakAnyLinkage;
+ // The thread wrapper can't be inlined if the backing variable cannot always
+ // be referenced. However, the thread wrapper can be replaced by a different
+ // definition in another translation unit.
+ if (isThreadWrapperReplaceable(VD, CGM)) {
+if (llvm::GlobalVariable::isLinkOnceLinkage(VarLinkage))
+ return llvm::GlobalVariable::WeakAnyLinkage;
+return VarLinkage;
+ }
return llvm::GlobalValue::WeakODRLinkage;
}
@@ -1862,7 +1873,7 @@
llvm::Function::Create(FnTy, getThreadLocalWrapperLinkage(VD, CGM),
WrapperName.str(), &CGM.getModule());
// Always resolve references to the wrapper at link time.
- if (!Wrapper->hasLocalLinkage())
+ if (!Wrapper->hasLocalLinkage() && !isThreadWrapperReplaceable(VD, CGM))
Wrapper->setVisibility(llvm::GlobalValue::HiddenVisibility);
return Wrapper;
}
@@ -1874,6 +1885,12 @@
const VarDecl *VD = Decls[I].first;
llvm::GlobalVariable *Var = Decls[I].second;
+// Some targets require that all access to thread local variables go
through
+// the thread wrapper. This means that we cannot attempt to create a
thread
+// wrapper or a thread helper.
+if (isThreadWrapperReplaceable(VD, CGM) && !VD->hasDefinition())
+ continue;
+
// Mangle the name for the thread_local initialization function.
SmallString<256> InitFnName;
{
Index: test/CodeGenCXX/tls-init-funcs.cpp
===
--- test/CodeGenCXX/tls-init-funcs.cpp
+++ test/CodeGenCXX/tls-init-funcs.cpp
@@ -1,11 +1,30 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.8 -std=c++11 -S -emit-llvm %s
-o - | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.8 -std=c++1y -S -emit-llvm %s
-o - | FileCheck %s
// CHECK: @a = internal thread_local global
+// CHECK: @_Z2vtIiE = internal thread_local global i32 5
+// CHECK: @_ZZ3inlvE3loc = linkonce_odr thread_local global i32 0
// CHECK: @_tlv_atexit({{.*}}@_ZN1AD1Ev
-// CHECK: define weak hidden {{.*}} @_ZTW1a
+// CHECK: call i32* @_ZTW3ext()
+// CHECK: declare i32* @_ZTW3ext()
+// CHECK: define weak i32* @_ZTW2vtIiE()
+// CHECK: define {{.*}} @_ZTW1a
struct A {
~A();
};
thread_local A a;
+
+extern thread_local int ext;
+int &get_ext() { return ext; }
+
+template
+thread_local int vt = 5;
+
+int get_vt() { return vt; }
+
+inline int &inl() {
+ thread_local int loc;
+ return loc;
+}
+int &use_inl() { return inl(); }
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -1818,6 +1818,15 @@
CGF.registerGlobalDtorWithAtExit(D, dtor, addr);
}
+static bool isThreadWrapperReplaceable(const VarDecl *VD,
+ CodeGen::CodeGenModule &CGM) {
+ assert(!VD->isStaticLocal() && "static local VarDecls don't need wrappers!");
+ // OS X prefers to have references to thread local variables to go through
+ // the thread wrapper instead of directly referencing the backing variable.
+ return VD->getTLSKind() == VarDecl::TLS_Dynamic &&
+ CGM.getTarget().getTriple().isMacOSX();
+}
+
/// Get the appropriate linkage for the wrapper function. This is essentially
/// the weak form of the variable's linkage; every translation unit which needs
/// the wrapper emits a copy, and we want the linker to merge them.
@@ -1830,12 +1839,14 @@
r212499 - [Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule
Author: samsonov
Date: Mon Jul 7 18:34:34 2014
New Revision: 212499
URL: http://llvm.org/viewvc/llvm-project?rev=212499&view=rev
Log:
[Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule
Get rid of cached CodeGenModule::SanOpts, which was used to turn off
sanitizer codegen options if current LLVM Module is blacklisted, and use
plain LangOpts.Sanitize instead.
1) Some codegen decisions (turning TBAA or writable strings on/off)
shouldn't depend on the contents of blacklist.
2) llvm.asan.globals should *always* be created, even if the module
is blacklisted - soon Clang's CodeGen where we read sanitizer
blacklist files, so we should properly report which globals are
blacklisted to the backend.
Modified:
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/test/CodeGen/asan-globals.cpp
Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=212499&r1=212498&r2=212499&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon Jul 7 18:34:34 2014
@@ -245,12 +245,14 @@ CreateGlobalInitOrDestructFunction(CodeG
if (!CGM.getLangOpts().Exceptions)
Fn->setDoesNotThrow();
- if (CGM.getSanOpts().Address)
-Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
- if (CGM.getSanOpts().Thread)
-Fn->addFnAttr(llvm::Attribute::SanitizeThread);
- if (CGM.getSanOpts().Memory)
-Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
+ if (!CGM.getSanitizerBlacklist().isIn(*Fn)) {
+if (CGM.getLangOpts().Sanitize.Address)
+ Fn->addFnAttr(llvm::Attribute::SanitizeAddress);
+if (CGM.getLangOpts().Sanitize.Thread)
+ Fn->addFnAttr(llvm::Attribute::SanitizeThread);
+if (CGM.getLangOpts().Sanitize.Memory)
+ Fn->addFnAttr(llvm::Attribute::SanitizeMemory);
+ }
return Fn;
}
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=212499&r1=212498&r2=212499&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Jul 7 18:34:34 2014
@@ -89,9 +89,7 @@ CodeGenModule::CodeGenModule(ASTContext
GenericBlockLiteralType(nullptr), LifetimeStartFn(nullptr),
LifetimeEndFn(nullptr),
SanitizerBlacklist(
- llvm::SpecialCaseList::createOrDie(CGO.SanitizerBlacklistFile)),
- SanOpts(SanitizerBlacklist->isIn(M) ? SanitizerOptions::Disabled
- : LangOpts.Sanitize) {
+ llvm::SpecialCaseList::createOrDie(CGO.SanitizerBlacklistFile)) {
// Initialize the type cache.
llvm::LLVMContext &LLVMContext = M.getContext();
@@ -122,7 +120,7 @@ CodeGenModule::CodeGenModule(ASTContext
createCUDARuntime();
// Enable TBAA unless it's suppressed. ThreadSanitizer needs TBAA even at O0.
- if (SanOpts.Thread ||
+ if (LangOpts.Sanitize.Thread ||
(!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0))
TBAA = new CodeGenTBAA(Context, VMContext, CodeGenOpts, getLangOpts(),
getCXXABI().getMangleContext());
@@ -735,14 +733,13 @@ void CodeGenModule::SetLLVMFunctionAttri
if (!SanitizerBlacklist->isIn(*F)) {
// When AddressSanitizer is enabled, set SanitizeAddress attribute
// unless __attribute__((no_sanitize_address)) is used.
-if (SanOpts.Address && !D->hasAttr())
+if (LangOpts.Sanitize.Address && !D->hasAttr())
B.addAttribute(llvm::Attribute::SanitizeAddress);
// Same for ThreadSanitizer and __attribute__((no_sanitize_thread))
-if (SanOpts.Thread && !D->hasAttr()) {
+if (LangOpts.Sanitize.Thread && !D->hasAttr())
B.addAttribute(llvm::Attribute::SanitizeThread);
-}
// Same for MemorySanitizer and __attribute__((no_sanitize_memory))
-if (SanOpts.Memory && !D->hasAttr())
+if (LangOpts.Sanitize.Memory && !D->hasAttr())
B.addAttribute(llvm::Attribute::SanitizeMemory);
}
@@ -1966,7 +1963,7 @@ void CodeGenModule::EmitGlobalVarDefinit
void CodeGenModule::reportGlobalToASan(llvm::GlobalVariable *GV,
SourceLocation Loc, bool IsDynInit) {
- if (!SanOpts.Address)
+ if (!LangOpts.Sanitize.Address)
return;
IsDynInit &= !SanitizerBlacklist->isIn(*GV, "init");
bool IsBlacklisted = SanitizerBlacklist->isIn(*GV);
@@ -2796,7 +2793,7 @@ CodeGenModule::GetAddrOfConstantStringFr
// Mangle the string literal if the ABI allows for it. However, we cannot
// do this if we are compiling with ASan or -fwritable-strings because they
// rely on strings having normal linkage.
- if (!LangOpts.WritableStrings && !SanOpts.Address &&
+ if (!LangOpts.Wr
Re: [PATCH] CodeGen: Let arrays be inputs to inline asm
- This is a Sema bug, not a CodeGen bug.
http://reviews.llvm.org/D4382
Files:
lib/CodeGen/CGExpr.cpp
lib/Sema/SemaStmtAsm.cpp
test/CodeGen/asm.c
test/CodeGen/x86-64-inline-asm.c
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -2781,7 +2781,6 @@
switch (E->getCastKind()) {
case CK_ToVoid:
case CK_BitCast:
- case CK_ArrayToPointerDecay:
case CK_FunctionToPointerDecay:
case CK_NullToMemberPointer:
case CK_NullToPointer:
@@ -2836,6 +2835,7 @@
return MakeAddrLValue(EmitDynamicCast(V, DCE), E->getType());
}
+ case CK_ArrayToPointerDecay:
case CK_ConstructorConversion:
case CK_UserDefinedConversion:
case CK_CPointerToObjCPointerCast:
Index: lib/Sema/SemaStmtAsm.cpp
===
--- lib/Sema/SemaStmtAsm.cpp
+++ lib/Sema/SemaStmtAsm.cpp
@@ -152,6 +152,12 @@
diag::err_asm_invalid_lvalue_in_input)
<< Info.getConstraintStr()
<< InputExpr->getSourceRange());
+} else {
+ ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
+ if (Result.isInvalid())
+return StmtError();
+
+ Exprs[i] = Result.get();
}
if (Info.allowsRegister()) {
@@ -163,11 +169,6 @@
}
}
-ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
-if (Result.isInvalid())
- return StmtError();
-
-Exprs[i] = Result.get();
InputConstraintInfos.push_back(Info);
const Type *Ty = Exprs[i]->getType().getTypePtr();
Index: test/CodeGen/asm.c
===
--- test/CodeGen/asm.c
+++ test/CodeGen/asm.c
@@ -239,3 +239,12 @@
// CHECK: call void asm sideeffect "/* $0 */",
"i|r,~{dirflag},~{fpsr},~{flags}"(i32 1)
}
+static unsigned t29_var[1];
+
+void t29(void) {
+ asm volatile("movl %%eax, %0"
+ :
+ : "m"(t29_var));
+ // CHECK: @t29
+ // CHECK: call void asm sideeffect "movl %eax, $0",
"*m,~{dirflag},~{fpsr},~{flags}"([1 x i32]* @t29_var)
+}
Index: test/CodeGen/x86-64-inline-asm.c
===
--- test/CodeGen/x86-64-inline-asm.c
+++ test/CodeGen/x86-64-inline-asm.c
@@ -10,3 +10,8 @@
// expected-error@-5 {{scale factor without index register is ignored}}
#endif
}
+
+static unsigned var[1] = {};
+void g(void) { asm volatile("movd %%xmm0, %0"
+:
+: "m"(var)); }
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -2781,7 +2781,6 @@
switch (E->getCastKind()) {
case CK_ToVoid:
case CK_BitCast:
- case CK_ArrayToPointerDecay:
case CK_FunctionToPointerDecay:
case CK_NullToMemberPointer:
case CK_NullToPointer:
@@ -2836,6 +2835,7 @@
return MakeAddrLValue(EmitDynamicCast(V, DCE), E->getType());
}
+ case CK_ArrayToPointerDecay:
case CK_ConstructorConversion:
case CK_UserDefinedConversion:
case CK_CPointerToObjCPointerCast:
Index: lib/Sema/SemaStmtAsm.cpp
===
--- lib/Sema/SemaStmtAsm.cpp
+++ lib/Sema/SemaStmtAsm.cpp
@@ -152,6 +152,12 @@
diag::err_asm_invalid_lvalue_in_input)
<< Info.getConstraintStr()
<< InputExpr->getSourceRange());
+} else {
+ ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
+ if (Result.isInvalid())
+return StmtError();
+
+ Exprs[i] = Result.get();
}
if (Info.allowsRegister()) {
@@ -163,11 +169,6 @@
}
}
-ExprResult Result = DefaultFunctionArrayLvalueConversion(Exprs[i]);
-if (Result.isInvalid())
- return StmtError();
-
-Exprs[i] = Result.get();
InputConstraintInfos.push_back(Info);
const Type *Ty = Exprs[i]->getType().getTypePtr();
Index: test/CodeGen/asm.c
===
--- test/CodeGen/asm.c
+++ test/CodeGen/asm.c
@@ -239,3 +239,12 @@
// CHECK: call void asm sideeffect "/* $0 */", "i|r,~{dirflag},~{fpsr},~{flags}"(i32 1)
}
+static unsigned t29_var[1];
+
+void t29(void) {
+ asm volatile("movl %%eax, %0"
+ :
+ : "m"(t29_var));
+ // CHECK: @t29
+ // CHECK: call void asm sideeffect "movl %eax, $0", "*m,~{dirflag},~{fpsr},~{flags}"([1 x i32]* @t29_var)
+}
Index: test/CodeGen/x86-64-inline-asm.c
===
--- test/CodeGen/x86-64-inline-asm.c
+++ test/CodeGen/x86-64-inline-asm.c
@@ -10,3 +10,8 @@
// expected-error@-5 {{scale factor without index register is ignored}}
#endif
}
+
+static unsigned var[1] = {};
+void g(void) { asm volatile("movd
Re: [PATCH] CodeGen: Let arrays be inputs to inline asm
2014-07-04 1:07 GMT-07:00 David Majnemer :
> Hi rsmith, rnk,
>
> An array showing up in an inline assembly input is accepted in ICC and
> GCC 4.8
>
> This fixes PR20201.
>
> http://reviews.llvm.org/D4382
>
> Files:
> lib/CodeGen/CGExpr.cpp
> test/CodeGen/asm.c
> test/CodeGen/x86-64-inline-asm.c
>
> Index: lib/CodeGen/CGExpr.cpp
> ===
> --- lib/CodeGen/CGExpr.cpp
> +++ lib/CodeGen/CGExpr.cpp
> @@ -2781,7 +2781,6 @@
>switch (E->getCastKind()) {
>case CK_ToVoid:
>case CK_BitCast:
> - case CK_ArrayToPointerDecay:
>
As discussed in person, I think this is addressing the symptom rather than
the cause. A memory operand expects an lvalue, and we're incorrectly
performing an lvalue-to-rvalue conversion on it in Sema.
>case CK_FunctionToPointerDecay:
>case CK_NullToMemberPointer:
>case CK_NullToPointer:
> @@ -2836,6 +2835,7 @@
> return MakeAddrLValue(EmitDynamicCast(V, DCE), E->getType());
>}
>
> + case CK_ArrayToPointerDecay:
>case CK_ConstructorConversion:
>case CK_UserDefinedConversion:
>case CK_CPointerToObjCPointerCast:
> Index: test/CodeGen/asm.c
> ===
> --- test/CodeGen/asm.c
> +++ test/CodeGen/asm.c
> @@ -239,3 +239,12 @@
> // CHECK: call void asm sideeffect "/* $0 */",
> "i|r,~{dirflag},~{fpsr},~{flags}"(i32 1)
> }
>
> +static unsigned t29_var[1];
> +
> +void t29(void) {
> + asm volatile("movl %%eax, %0"
> + :
> + : "m"(t29_var));
> + // CHECK: @t29
> + // CHECK: call void asm sideeffect "movl %eax, $0",
> "*m,~{dirflag},~{fpsr},~{flags}"([1 x i32]* @t29_var)
> +}
> Index: test/CodeGen/x86-64-inline-asm.c
> ===
> --- test/CodeGen/x86-64-inline-asm.c
> +++ test/CodeGen/x86-64-inline-asm.c
> @@ -10,3 +10,8 @@
> // expected-error@-5 {{scale factor without index register is ignored}}
> #endif
> }
> +
> +static unsigned var[1] = {};
> +void g(void) { asm volatile("movd %%xmm0, %0"
> +:
> +: "m"(var)); }
>
http://reviews.llvm.org/D4382
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] CodeGen: Let arrays be inputs to inline asm
2014-07-04 1:07 GMT-07:00 David Majnemer :
> Hi rsmith, rnk,
>
> An array showing up in an inline assembly input is accepted in ICC and
> GCC 4.8
>
> This fixes PR20201.
>
> http://reviews.llvm.org/D4382
>
> Files:
> lib/CodeGen/CGExpr.cpp
> test/CodeGen/asm.c
> test/CodeGen/x86-64-inline-asm.c
>
> Index: lib/CodeGen/CGExpr.cpp
> ===
> --- lib/CodeGen/CGExpr.cpp
> +++ lib/CodeGen/CGExpr.cpp
> @@ -2781,7 +2781,6 @@
>switch (E->getCastKind()) {
>case CK_ToVoid:
>case CK_BitCast:
> - case CK_ArrayToPointerDecay:
>
As discussed in person, I think this is addressing the symptom rather than
the cause. A memory operand expects an lvalue, and we're incorrectly
performing an lvalue-to-rvalue conversion on it in Sema.
>case CK_FunctionToPointerDecay:
>case CK_NullToMemberPointer:
>case CK_NullToPointer:
> @@ -2836,6 +2835,7 @@
> return MakeAddrLValue(EmitDynamicCast(V, DCE), E->getType());
>}
>
> + case CK_ArrayToPointerDecay:
>case CK_ConstructorConversion:
>case CK_UserDefinedConversion:
>case CK_CPointerToObjCPointerCast:
> Index: test/CodeGen/asm.c
> ===
> --- test/CodeGen/asm.c
> +++ test/CodeGen/asm.c
> @@ -239,3 +239,12 @@
> // CHECK: call void asm sideeffect "/* $0 */",
> "i|r,~{dirflag},~{fpsr},~{flags}"(i32 1)
> }
>
> +static unsigned t29_var[1];
> +
> +void t29(void) {
> + asm volatile("movl %%eax, %0"
> + :
> + : "m"(t29_var));
> + // CHECK: @t29
> + // CHECK: call void asm sideeffect "movl %eax, $0",
> "*m,~{dirflag},~{fpsr},~{flags}"([1 x i32]* @t29_var)
> +}
> Index: test/CodeGen/x86-64-inline-asm.c
> ===
> --- test/CodeGen/x86-64-inline-asm.c
> +++ test/CodeGen/x86-64-inline-asm.c
> @@ -10,3 +10,8 @@
> // expected-error@-5 {{scale factor without index register is ignored}}
> #endif
> }
> +
> +static unsigned var[1] = {};
> +void g(void) { asm volatile("movd %%xmm0, %0"
> +:
> +: "m"(var)); }
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Add support for CUDA unroll pragma
On Tue, Jul 1, 2014 at 5:36 PM, Richard Smith wrote:
> One question: you list the unroll count as 'n'. Must that be a constant
> integer? The clang pragma intends to allow an arbitrary integer constant
> expression there. That might be a good reason for us to introduce our own
> syntax for it, if we're providing a slightly more general form.
>
nvcc (CUDA) only supports a literal integer constant. icc seems to support
only literal constants as well. xlc supports integer constant expressions.
Given xlc and icc share the same syntax ("#pragma unroll (_value_)") there
is no way to be perfectly compatible with both icc and xlc so I'm inclined
to support expressions in "#pragma unroll" as planned with the other loop
pragmas and just be more permissive than nvcc and icc.
Mark
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212497 - libclang: pass return code out argument by reference
Author: alp
Date: Mon Jul 7 17:42:03 2014
New Revision: 212497
URL: http://llvm.org/viewvc/llvm-project?rev=212497&view=rev
Log:
libclang: pass return code out argument by reference
r212427 formalized the message-passing pattern by making these argument
structures const. This commit changes output arguments to get passed by
reference so we can eliminate mutable fields.
Modified:
cfe/trunk/tools/libclang/CIndex.cpp
cfe/trunk/tools/libclang/Indexing.cpp
Modified: cfe/trunk/tools/libclang/CIndex.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=212497&r1=212496&r2=212497&view=diff
==
--- cfe/trunk/tools/libclang/CIndex.cpp (original)
+++ cfe/trunk/tools/libclang/CIndex.cpp Mon Jul 7 17:42:03 2014
@@ -2736,7 +2736,7 @@ struct ParseTranslationUnitInfo {
ArrayRef unsaved_files;
unsigned options;
CXTranslationUnit *out_TU;
- mutable CXErrorCode result;
+ CXErrorCode &result;
};
static void clang_parseTranslationUnit_Impl(void *UserData) {
const ParseTranslationUnitInfo *PTUI =
@@ -2751,7 +2751,6 @@ static void clang_parseTranslationUnit_I
// Set up the initial return values.
if (out_TU)
*out_TU = nullptr;
- PTUI->result = CXError_Failure;
// Check arguments.
if (!CIdx || !out_TU) {
@@ -2898,6 +2897,7 @@ enum CXErrorCode clang_parseTranslationU
if (num_unsaved_files && !unsaved_files)
return CXError_InvalidArguments;
+ CXErrorCode result = CXError_Failure;
ParseTranslationUnitInfo PTUI = {
CIdx,
source_filename,
@@ -2906,7 +2906,7 @@ enum CXErrorCode clang_parseTranslationU
llvm::makeArrayRef(unsaved_files, num_unsaved_files),
options,
out_TU,
- CXError_Failure};
+ result};
llvm::CrashRecoveryContext CRC;
if (!RunSafely(CRC, clang_parseTranslationUnit_Impl, &PTUI)) {
@@ -2935,8 +2935,8 @@ enum CXErrorCode clang_parseTranslationU
if (CXTranslationUnit *TU = PTUI.out_TU)
PrintLibclangResourceUsage(*TU);
}
-
- return PTUI.result;
+
+ return result;
}
unsigned clang_defaultSaveOptions(CXTranslationUnit TU) {
@@ -3039,14 +3039,12 @@ struct ReparseTranslationUnitInfo {
CXTranslationUnit TU;
ArrayRef unsaved_files;
unsigned options;
- mutable int result;
+ CXErrorCode &result;
};
static void clang_reparseTranslationUnit_Impl(void *UserData) {
const ReparseTranslationUnitInfo *RTUI =
static_cast(UserData);
- RTUI->result = CXError_Failure;
-
CXTranslationUnit TU = RTUI->TU;
unsigned options = RTUI->options;
(void) options;
@@ -3099,13 +3097,14 @@ int clang_reparseTranslationUnit(CXTrans
if (num_unsaved_files && !unsaved_files)
return CXError_InvalidArguments;
+ CXErrorCode result = CXError_Failure;
ReparseTranslationUnitInfo RTUI = {
TU, llvm::makeArrayRef(unsaved_files, num_unsaved_files), options,
- CXError_Failure};
+ result};
if (getenv("LIBCLANG_NOTHREADS")) {
clang_reparseTranslationUnit_Impl(&RTUI);
-return RTUI.result;
+return result;
}
llvm::CrashRecoveryContext CRC;
@@ -3117,7 +3116,7 @@ int clang_reparseTranslationUnit(CXTrans
} else if (getenv("LIBCLANG_RESOURCE_USAGE"))
PrintLibclangResourceUsage(TU);
- return RTUI.result;
+ return result;
}
Modified: cfe/trunk/tools/libclang/Indexing.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/Indexing.cpp?rev=212497&r1=212496&r2=212497&view=diff
==
--- cfe/trunk/tools/libclang/Indexing.cpp (original)
+++ cfe/trunk/tools/libclang/Indexing.cpp Mon Jul 7 17:42:03 2014
@@ -475,7 +475,7 @@ struct IndexSourceFileInfo {
ArrayRef unsaved_files;
CXTranslationUnit *out_TU;
unsigned TU_options;
- mutable int result;
+ CXErrorCode &result;
};
} // anonymous namespace
@@ -494,9 +494,6 @@ static void clang_indexSourceFile_Impl(v
CXTranslationUnit *out_TU = ITUI->out_TU;
unsigned TU_options = ITUI->TU_options;
- // Set up the initial return value.
- ITUI->result = CXError_Failure;
-
if (out_TU)
*out_TU = nullptr;
bool requestedToGetTU = (out_TU != nullptr);
@@ -982,6 +979,7 @@ int clang_indexSourceFile(CXIndexAction
if (num_unsaved_files && !unsaved_files)
return CXError_InvalidArguments;
+ CXErrorCode result = CXError_Failure;
IndexSourceFileInfo ITUI = {
idxAction,
client_data,
@@ -994,11 +992,11 @@ int clang_indexSourceFile(CXIndexAction
llvm::makeArrayRef(unsaved_files, num_unsaved_files),
out_TU,
TU_options,
- CXError_Failure};
+ result};
if (getenv("LIBCLANG_NOTHREADS")) {
clang_indexSourceFile_Impl(&ITUI);
-return ITUI.result;
+return result;
}
llvm::CrashRecoveryContext CRC;
@@ -1029,8 +1027,8 @@ int clang_indexSourceFile(CXIndexAction
if (out_TU)
PrintLibclangResourceUsage(*out_TU);
}
-
[PATCH, v2] ARM: fix inline atomic handling
... forgot the actual patch, sorry for the noise.
Another try at allowing inline atomics whenever available, this time
including a testcase that checks for availability of some atomics on a
few targets. Enumerating all atomics for all platforms seems a bit
pointless because we already have tests for all supported atomics for
a number of targets, so availability checks should suffice.Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp (revision 212482)
+++ lib/Basic/Targets.cpp (working copy)
@@ -3475,27 +3475,14 @@
static const Builtin::Info BuiltinInfo[];
static bool shouldUseInlineAtomic(const llvm::Triple &T) {
-if (T.isOSWindows())
- return true;
-
-// On linux, binaries targeting old cpus call functions in libgcc to
-// perform atomic operations. The implementation in libgcc then calls into
-// the kernel which on armv6 and newer uses ldrex and strex. The net result
-// is that if we assume the kernel is at least as recent as the hardware,
-// it is safe to use atomic instructions on armv6 and newer.
-if (!T.isOSLinux() &&
-T.getOS() != llvm::Triple::FreeBSD &&
-T.getOS() != llvm::Triple::NetBSD &&
-T.getOS() != llvm::Triple::Bitrig)
- return false;
StringRef ArchName = T.getArchName();
if (T.getArch() == llvm::Triple::arm ||
T.getArch() == llvm::Triple::armeb) {
StringRef VersionStr;
if (ArchName.startswith("armv"))
-VersionStr = ArchName.substr(4);
+VersionStr = ArchName.substr(4, 1);
else if (ArchName.startswith("armebv"))
-VersionStr = ArchName.substr(6);
+VersionStr = ArchName.substr(6, 1);
else
return false;
unsigned Version;
@@ -3507,9 +3494,9 @@
T.getArch() == llvm::Triple::thumbeb);
StringRef VersionStr;
if (ArchName.startswith("thumbv"))
- VersionStr = ArchName.substr(6);
+ VersionStr = ArchName.substr(6, 1);
else if (ArchName.startswith("thumbebv"))
- VersionStr = ArchName.substr(8);
+ VersionStr = ArchName.substr(8, 1);
else
return false;
unsigned Version;
@@ -3854,6 +3841,13 @@
if (!getCPUDefineSuffix(Name))
return false;
+// Cortex M does not support 8 byte atomics, while general Thumb2 does.
+StringRef Profile = getCPUProfile(Name);
+if (Profile == "M" && MaxAtomicInlineWidth) {
+ MaxAtomicPromoteWidth = 32;
+ MaxAtomicInlineWidth = 32;
+}
+
CPU = Name;
return true;
}
Index: test/CodeGen/arm-atomics.c
===
--- test/CodeGen/arm-atomics.c (revision 0)
+++ test/CodeGen/arm-atomics.c (working copy)
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=thumbv7m-none--eabi -std=c11 | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=armv6-none--eabi -std=c11 | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=armv7-unknown-openbsd -std=c11 | FileCheck %s
+
+int i;
+
+typedef enum memory_order {
+ memory_order_relaxed, memory_order_consume, memory_order_acquire,
+ memory_order_release, memory_order_acq_rel, memory_order_seq_cst
+} memory_order;
+
+void test_presence(void)
+{
+ // CHECK-LABEL: @test_presence
+ // CHECK: atomicrmw add i32* {{.*}} seq_cst
+ __atomic_fetch_add(&i, 1, memory_order_seq_cst);
+ // CHECK: atomicrmw sub i32* {{.*}} seq_cst
+ __atomic_fetch_sub(&i, 1, memory_order_seq_cst);
+ // CHECK: load atomic i32* {{.*}} seq_cst
+ int r;
+ __atomic_load(&i, &r, memory_order_seq_cst);
+ // CHECK: store atomic i32 {{.*}} seq_cst
+ r = 0;
+ __atomic_store(&i, &r, memory_order_seq_cst);
+}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH v2 2/9] Add the initial TypoExpr AST node for delayed typo correction.
On Fri, Jun 27, 2014 at 10:42 AM, Kaelyn Takata wrote:
> On Fri, Jun 27, 2014 at 7:31 AM, Richard Smith
> wrote:
>
>> + TypoExpr(std::unique_ptr TCC,
>> + std::unique_ptr TDG);
>> + child_range children() { return child_range(); }
>> + SourceLocation getLocStart() const LLVM_READONLY { return
>> SourceLocation(); }
>> + SourceLocation getLocEnd() const LLVM_READONLY { return
>> SourceLocation(); }
>> +
>> + std::unique_ptr Consumer;
>> + std::unique_ptr DiagHandler;
>>
>> These unique_ptrs will be leaked; AST nodes don't get destroyed. Please
>> allocate your handlers on the ASTContext instead.
>>
>
> Well @#$%. I'm assuming that allocating these on the ASTContext would mean
> calling e.g. "new (SemaRef.Context) TypoCorrectionConsumer(...)" instead of
> "llvm::make_unique(...)" and passing around raw
> pointers instead of unique_ptrs?
>
ping
>
>>
>> +TypoExpr::TypoExpr(std::unique_ptr TCC,
>> + std::unique_ptr TDG)
>> +: Expr(TypoExprClass, TCC->getContext().DependentTy, VK_LValue,
>> OK_Ordinary,
>> + /*isTypeDependent*/ true,
>> + /*isValueDependent*/ true,
>> + /*isInstantiationDependent*/ true,
>> + /*containsUnexpandedParameterPack*/ false),
>>
>> Hmm, parameter packs are an interesting twist on this. Suppose we have:
>>
>> template void f(Thing ...thing) { g(rhing...); }
>>
>> if we set containsUnexpandedParameterPack to false, we'll reject this in
>> the initial parse. If we set it to true, we'll reject other stuff instead.
>> =( Maybe we should suppress diagnosing an unexpanded pack if we've got an
>> active typo correction?
>>
>
> Umm... yeah... having not really worked with parameter packs or looked at
> any (failing) typo-correction unit tests involving parameter packs yet, I
> don't know what the right answer is. Nor do I quite know where the boundary
> of containsUnexpandedParameterPack being true would fall relative to an
> expression placeholder that represents a possibly-qualified identifier and
> the hooks needed to expand the identifier into an expression that fits in
> where the identifier was seen.
>
>
>>
>> template
>> ExprResult
>> +TreeTransform::TransformTypoExpr(TypoExpr *E) {
>> + assert(getDerived().AlreadyTransformed(E->getType()) &&
>> + "typo-correction placeholder expression requires
>> transformation");
>> + return Owned(E);
>> +}
>>
>> Can we really not get here with a TypoExpr still in the tree? We have
>> enough TreeTransforms these days that I find this a bit surprising. Maybe
>> TreeTransform should just preserve TypoExprs by default.
>>
>
> D'oh, you're right. When I added all of the (Transform|Visit)TypoExpr
> methods to the various classes like this one and ASTStmtReader in order to
> make the compiler happy, I applied pretty much the same code or mentality
> to all of the methods: "a TypoExpr is internal to Sema so shouldn't ever
> hit these paths since it should never still be in the AST tree when the
> tree is serialized, deserialized, etc)". I've dropped the assert here (and
> the now-defunct call to Owned).
>
>
>>
>> +void ASTStmtReader::VisitTypoExpr(TypoExpr *E) {
>> + VisitExpr(E);
>> + // TODO: Figure out sane reader behavior for a TypoExpr, if necessary.
>> + assert(false && "Cannot read TypoExpr nodes");
>> +}
>>
>> I think this should be unreachable; if things have gone so badly wrong
>> that we couldn't resolve a TypoExpr, we shouldn't serialize it either.
>>
>
> I've replaced the three lines in the body with a call to
> llvm_unreachable().
>
>
>>
>> On Tue, Jun 17, 2014 at 5:29 PM, Kaelyn Takata wrote:
>>
>>> ---
>>> include/clang/AST/DataRecursiveASTVisitor.h | 1 +
>>> include/clang/AST/Expr.h| 17 +
>>> include/clang/AST/RecursiveASTVisitor.h | 1 +
>>> include/clang/Basic/StmtNodes.td| 1 +
>>> include/clang/Sema/SemaInternal.h | 3 +++
>>> include/clang/Sema/TypoCorrection.h | 5 +
>>> lib/AST/Expr.cpp| 1 +
>>> lib/AST/ExprClassification.cpp | 3 ++-
>>> lib/AST/ExprConstant.cpp| 1 +
>>> lib/AST/ItaniumMangle.cpp | 1 +
>>> lib/AST/StmtPrinter.cpp | 5 +
>>> lib/AST/StmtProfile.cpp | 4
>>> lib/Sema/SemaExceptionSpec.cpp | 1 +
>>> lib/Sema/SemaLookup.cpp | 11 +++
>>> lib/Sema/TreeTransform.h| 8
>>> lib/Serialization/ASTReaderStmt.cpp | 6 ++
>>> lib/Serialization/ASTWriterStmt.cpp | 6 ++
>>> lib/StaticAnalyzer/Core/ExprEngine.cpp | 1 +
>>> tools/libclang/CXCursor.cpp | 1 +
>>> 19 files changed, 76 insertions(+), 1 deletion(-)
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>>
>>
Re: [PATCH] Factor getObjCEncodingForPropertyType out of getObjCEncodingForPropertyDecl
Thanks Doug! Committed r212496. -Joe On Mon, Jul 7, 2014 at 3:25 PM, Douglas Gregor wrote: > LGTM > > > On Jul 7, 2014, at 11:14 AM, Joe Groff wrote: > > > > Hi everyone. I'd like to be able to get the type encoding of an ObjC > property by itself without forming an entire ObjCPropertyDecl. Here's a > small patch that factors ASTContext::getObjCEncodingForPropertyType out of > the larger getObjCEncodingForPropertyDecl method. > > > > -Joe > > > ___ > > cfe-commits mailing list > > cfe-commits@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212496 - ASTContext: Factor 'getObjCEncodingForPropertyType' as its own method.
Author: joe
Date: Mon Jul 7 17:25:15 2014
New Revision: 212496
URL: http://llvm.org/viewvc/llvm-project?rev=212496&view=rev
Log:
ASTContext: Factor 'getObjCEncodingForPropertyType' as its own method.
It is useful to get the property encoding for an ObjC type without a full
ObjCPropertyDecl.
Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/lib/AST/ASTContext.cpp
Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=212496&r1=212495&r2=212496&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Mon Jul 7 17:25:15 2014
@@ -1373,6 +1373,10 @@ public:
void getObjCEncodingForType(QualType T, std::string &S,
const FieldDecl *Field=nullptr) const;
+ /// \brief Emit the Objective-C property type encoding for the given
+ /// type \p T into \p S.
+ void getObjCEncodingForPropertyType(QualType T, std::string &S) const;
+
void getLegacyIntegralTypeEncoding(QualType &t) const;
/// \brief Put the string version of the type qualifiers \p QT into \p S.
Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=212496&r1=212495&r2=212496&view=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Mon Jul 7 17:25:15 2014
@@ -5022,9 +5022,7 @@ void ASTContext::getObjCEncodingForPrope
// Encode result type.
// GCC has some special rules regarding encoding of properties which
// closely resembles encoding of ivars.
- getObjCEncodingForTypeImpl(PD->getType(), S, true, true, nullptr,
- true /* outermost type */,
- true /* encoding for property */);
+ getObjCEncodingForPropertyType(PD->getType(), S);
if (PD->isReadOnly()) {
S += ",R";
@@ -5097,6 +5095,16 @@ void ASTContext::getObjCEncodingForType(
true /* outermost type */);
}
+void ASTContext::getObjCEncodingForPropertyType(QualType T,
+std::string& S) const {
+ // Encode result type.
+ // GCC has some special rules regarding encoding of properties which
+ // closely resembles encoding of ivars.
+ getObjCEncodingForTypeImpl(T, S, true, true, nullptr,
+ true /* outermost type */,
+ true /* encoding property */);
+}
+
static char getObjCEncodingForPrimitiveKind(const ASTContext *C,
BuiltinType::Kind kind) {
switch (kind) {
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Factor getObjCEncodingForPropertyType out of getObjCEncodingForPropertyDecl
LGTM > On Jul 7, 2014, at 11:14 AM, Joe Groff wrote: > > Hi everyone. I'd like to be able to get the type encoding of an ObjC property > by itself without forming an entire ObjCPropertyDecl. Here's a small patch > that factors ASTContext::getObjCEncodingForPropertyType out of the larger > getObjCEncodingForPropertyDecl method. > > -Joe > ___ > cfe-commits mailing list > cfe-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212494 - PlistSupport: make utility functions non-static inline to encourage linker dedup
Author: alp
Date: Mon Jul 7 16:57:42 2014
New Revision: 212494
URL: http://llvm.org/viewvc/llvm-project?rev=212494&view=rev
Log:
PlistSupport: make utility functions non-static inline to encourage linker dedup
Modified:
cfe/trunk/include/clang/Basic/PlistSupport.h
Modified: cfe/trunk/include/clang/Basic/PlistSupport.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/PlistSupport.h?rev=212494&r1=212493&r2=212494&view=diff
==
--- cfe/trunk/include/clang/Basic/PlistSupport.h (original)
+++ cfe/trunk/include/clang/Basic/PlistSupport.h Mon Jul 7 16:57:42 2014
@@ -19,8 +19,8 @@ namespace clang {
namespace markup {
typedef llvm::DenseMap FIDMap;
-static inline void AddFID(FIDMap &FIDs, SmallVectorImpl &V,
- const SourceManager &SM, SourceLocation L) {
+inline void AddFID(FIDMap &FIDs, SmallVectorImpl &V,
+ const SourceManager &SM, SourceLocation L) {
FileID FID = SM.getFileID(SM.getExpansionLoc(L));
FIDMap::iterator I = FIDs.find(FID);
if (I != FIDs.end())
@@ -29,21 +29,21 @@ static inline void AddFID(FIDMap &FIDs,
V.push_back(FID);
}
-static inline unsigned GetFID(const FIDMap &FIDs, const SourceManager &SM,
- SourceLocation L) {
+inline unsigned GetFID(const FIDMap &FIDs, const SourceManager &SM,
+ SourceLocation L) {
FileID FID = SM.getFileID(SM.getExpansionLoc(L));
FIDMap::const_iterator I = FIDs.find(FID);
assert(I != FIDs.end());
return I->second;
}
-static inline raw_ostream &Indent(raw_ostream &o, const unsigned indent) {
+inline raw_ostream &Indent(raw_ostream &o, const unsigned indent) {
for (unsigned i = 0; i < indent; ++i)
o << ' ';
return o;
}
-static inline raw_ostream &EmitPlistHeader(raw_ostream &o) {
+inline raw_ostream &EmitPlistHeader(raw_ostream &o) {
static const char *PlistHeader =
"\n"
"";
o << value;
o << "";
return o;
}
-static inline raw_ostream &EmitString(raw_ostream &o, StringRef s) {
+inline raw_ostream &EmitString(raw_ostream &o, StringRef s) {
o << "";
for (StringRef::const_iterator I = s.begin(), E = s.end(); I != E; ++I) {
char c = *I;
@@ -88,10 +88,10 @@ static inline raw_ostream &EmitString(ra
return o;
}
-static inline void EmitLocation(raw_ostream &o, const SourceManager &SM,
-const LangOptions &LangOpts, SourceLocation L,
-const FIDMap &FM, unsigned indent,
-bool extend = false) {
+inline void EmitLocation(raw_ostream &o, const SourceManager &SM,
+ const LangOptions &LangOpts, SourceLocation L,
+ const FIDMap &FM, unsigned indent,
+ bool extend = false) {
FullSourceLoc Loc(SM.getExpansionLoc(L), const_cast(SM));
// Add in the length of the token, so that we cover multi-char tokens.
@@ -108,9 +108,9 @@ static inline void EmitLocation(raw_ostr
Indent(o, indent) << "\n";
}
-static inline void EmitRange(raw_ostream &o, const SourceManager &SM,
- const LangOptions &LangOpts, CharSourceRange R,
- const FIDMap &FM, unsigned indent) {
+inline void EmitRange(raw_ostream &o, const SourceManager &SM,
+ const LangOptions &LangOpts, CharSourceRange R,
+ const FIDMap &FM, unsigned indent) {
Indent(o, indent) << "\n";
EmitLocation(o, SM, LangOpts, R.getBegin(), FM, indent + 1);
EmitLocation(o, SM, LangOpts, R.getEnd(), FM, indent + 1, R.isTokenRange());
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] gcc compatibility: silent -finline-limit=1234 & -finline-limit
One alternative is to recognize the flag, but warn on it. An easy way to do this with a poor diagnostic experience is to simply add it to our option table, don't put it into clang_ignored_f_Group, and don't check it in the driver. Clang will emit 'warning: argument unused during compilation '-finline-limit=1234''. For extra credit, we could have a diagnostic like "ignoring GCC optimization tuning flag" and use that for all GCC optimization flags that don't have analogues in Clang/LLVM. Comment at: include/clang/Driver/Options.td:1561 @@ -1560,2 +1560,3 @@ defm implicit_templates : BooleanFFlag<"implicit-templates">, Group; +def inline_limit_EQ : Joined<["-"], "finline-limit=">, Group; defm inline_limit : BooleanFFlag<"inline-limit">, Group; This should be finline_limit_EQ. http://reviews.llvm.org/D4376 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212452 - Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
On Mon, Jul 7, 2014 at 6:09 AM, Aaron Ballman wrote: > On Mon, Jul 7, 2014 at 9:07 AM, Manuel Klimek wrote: >> On Mon, Jul 7, 2014 at 3:06 PM, Aaron Ballman >> wrote: >>> >>> On Mon, Jul 7, 2014 at 8:55 AM, Manuel Klimek wrote: >>> > Author: klimek >>> > Date: Mon Jul 7 07:55:16 2014 >>> > New Revision: 212452 >>> > >>> > URL: http://llvm.org/viewvc/llvm-project?rev=212452&view=rev >>> > Log: >>> > Increase argument limit of anyOf, allOf and eachOf from 5 to 9. >>> >>> Can we simply use truly variadic templates now that we're using C++11 >>> features? >> >> >> See >> http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features >> >> Variadic templates are not supported by VS 2012. > > Ah crud, I knew that in the recesses of my brain. :-P Sorry about that. We do still use them in places, protected by LLVM_HAS_VARIADIC_TEMPLATES - usually providing a fallback non-variadic implementation. That way users with variadic support in their compilers get better error messages, etc, (and out-of-tree library users of any such APIs get the desired behavior without being limited by MSVC2012). - David > > ~Aaron > ___ > cfe-commits mailing list > cfe-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212436 - StaticAnalyzer: Silence a warning
It just silences a warning (thanks!). It'd be testable if we added CFG
construction support for SEH stuff.
On Mon, Jul 7, 2014 at 2:13 PM, David Blaikie wrote:
> Is this testable?
>
> On Sun, Jul 6, 2014 at 11:20 PM, David Majnemer
> wrote:
> > Author: majnemer
> > Date: Mon Jul 7 01:20:50 2014
> > New Revision: 212436
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=212436&view=rev
> > Log:
> > StaticAnalyzer: Silence a warning
> >
> > ExprEngine wasn't ready for SEHLeaveStmtClass. Handle it like all the
> > other SEH constructs by aborting.
> >
> > Modified:
> > cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
> >
> > Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp?rev=212436&r1=212435&r2=212436&view=diff
> >
> ==
> > --- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp (original)
> > +++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp Mon Jul 7 01:20:50
> 2014
> > @@ -699,6 +699,7 @@ void ExprEngine::Visit(const Stmt *S, Ex
> > case Stmt::FunctionParmPackExprClass:
> > case Stmt::SEHTryStmtClass:
> > case Stmt::SEHExceptStmtClass:
> > +case Stmt::SEHLeaveStmtClass:
> > case Stmt::LambdaExprClass:
> > case Stmt::SEHFinallyStmtClass: {
> >const ExplodedNode *node = Bldr.generateSink(S, Pred,
> Pred->getState());
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212436 - StaticAnalyzer: Silence a warning
Is this testable?
On Sun, Jul 6, 2014 at 11:20 PM, David Majnemer
wrote:
> Author: majnemer
> Date: Mon Jul 7 01:20:50 2014
> New Revision: 212436
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212436&view=rev
> Log:
> StaticAnalyzer: Silence a warning
>
> ExprEngine wasn't ready for SEHLeaveStmtClass. Handle it like all the
> other SEH constructs by aborting.
>
> Modified:
> cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp?rev=212436&r1=212435&r2=212436&view=diff
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp Mon Jul 7 01:20:50 2014
> @@ -699,6 +699,7 @@ void ExprEngine::Visit(const Stmt *S, Ex
> case Stmt::FunctionParmPackExprClass:
> case Stmt::SEHTryStmtClass:
> case Stmt::SEHExceptStmtClass:
> +case Stmt::SEHLeaveStmtClass:
> case Stmt::LambdaExprClass:
> case Stmt::SEHFinallyStmtClass: {
>const ExplodedNode *node = Bldr.generateSink(S, Pred,
> Pred->getState());
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212427 - libclang: refactor handling of unsaved_files
On Sun, Jul 6, 2014 at 6:23 PM, Alp Toker wrote:
> Author: alp
> Date: Sun Jul 6 20:23:14 2014
> New Revision: 212427
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212427&view=rev
> Log:
> libclang: refactor handling of unsaved_files
>
> Consolidate CXUnsavedFile argument handling in API functions to support a
> wider
> cleanup of various file remapping schemes in the frontend.
>
> Modified:
> cfe/trunk/tools/libclang/CIndex.cpp
> cfe/trunk/tools/libclang/CIndexCodeCompletion.cpp
> cfe/trunk/tools/libclang/CXString.h
> cfe/trunk/tools/libclang/Indexing.cpp
>
> Modified: cfe/trunk/tools/libclang/CIndex.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CIndex.cpp?rev=212427&r1=212426&r2=212427&view=diff
> ==
> --- cfe/trunk/tools/libclang/CIndex.cpp (original)
> +++ cfe/trunk/tools/libclang/CIndex.cpp Sun Jul 6 20:23:14 2014
> @@ -2727,21 +2727,18 @@ struct ParseTranslationUnitInfo {
>const char *source_filename;
>const char *const *command_line_args;
>int num_command_line_args;
> - struct CXUnsavedFile *unsaved_files;
> - unsigned num_unsaved_files;
> + ArrayRef unsaved_files;
>unsigned options;
>CXTranslationUnit *out_TU;
> - CXErrorCode result;
> + mutable CXErrorCode result;
I haven't looked at the code in detail - but is there a one-sentence
summary of why the right pivot/design here is to have this field
mutable? (& similarly for another field or two that are becoming
mutable in this change)
> };
> static void clang_parseTranslationUnit_Impl(void *UserData) {
> - ParseTranslationUnitInfo *PTUI =
> -static_cast(UserData);
> + const ParseTranslationUnitInfo *PTUI =
> + static_cast(UserData);
If you like, you could add "const" to the cast and just use "auto *"
(or even plain "auto") on the LHS. (& similarly with some other
changes in this commit)
>CXIndex CIdx = PTUI->CIdx;
>const char *source_filename = PTUI->source_filename;
>const char * const *command_line_args = PTUI->command_line_args;
>int num_command_line_args = PTUI->num_command_line_args;
> - struct CXUnsavedFile *unsaved_files = PTUI->unsaved_files;
> - unsigned num_unsaved_files = PTUI->num_unsaved_files;
>unsigned options = PTUI->options;
>CXTranslationUnit *out_TU = PTUI->out_TU;
>
> @@ -2751,8 +2748,7 @@ static void clang_parseTranslationUnit_I
>PTUI->result = CXError_Failure;
>
>// Check arguments.
> - if (!CIdx || !out_TU ||
> - (unsaved_files == nullptr && num_unsaved_files != 0)) {
> + if (!CIdx || !out_TU) {
> PTUI->result = CXError_InvalidArguments;
> return;
>}
> @@ -2789,12 +2785,10 @@ static void clang_parseTranslationUnit_I
>llvm::CrashRecoveryContextCleanupRegistrar<
> std::vector >
> RemappedCleanup(RemappedFiles.get());
>
> - for (unsigned I = 0; I != num_unsaved_files; ++I) {
> -StringRef Data(unsaved_files[I].Contents, unsaved_files[I].Length);
> -llvm::MemoryBuffer *Buffer =
> -llvm::MemoryBuffer::getMemBufferCopy(Data,
> unsaved_files[I].Filename);
> -RemappedFiles->push_back(std::make_pair(unsaved_files[I].Filename,
> -Buffer));
> + for (auto &UF : PTUI->unsaved_files) {
> +llvm::MemoryBuffer *MB =
> +llvm::MemoryBuffer::getMemBufferCopy(getContents(UF), UF.Filename);
> +RemappedFiles->push_back(std::make_pair(UF.Filename, MB));
>}
>
>std::unique_ptr> Args(
> @@ -2895,10 +2889,18 @@ enum CXErrorCode clang_parseTranslationU
>*Log << command_line_args[i] << " ";
>}
>
> - ParseTranslationUnitInfo PTUI = { CIdx, source_filename, command_line_args,
> -num_command_line_args, unsaved_files,
> -num_unsaved_files, options, out_TU,
> -CXError_Failure };
> + if (num_unsaved_files && !unsaved_files)
> +return CXError_InvalidArguments;
> +
> + ParseTranslationUnitInfo PTUI = {
> + CIdx,
> + source_filename,
> + command_line_args,
> + num_command_line_args,
> + llvm::makeArrayRef(unsaved_files, num_unsaved_files),
> + options,
> + out_TU,
> + CXError_Failure};
>llvm::CrashRecoveryContext CRC;
>
>if (!RunSafely(CRC, clang_parseTranslationUnit_Impl, &PTUI)) {
> @@ -3029,20 +3031,17 @@ unsigned clang_defaultReparseOptions(CXT
>
> struct ReparseTranslationUnitInfo {
>CXTranslationUnit TU;
> - unsigned num_unsaved_files;
> - struct CXUnsavedFile *unsaved_files;
> + ArrayRef unsaved_files;
>unsigned options;
> - int result;
> + mutable int result;
> };
>
> static void clang_reparseTranslationUnit_Impl(void *UserData) {
> - ReparseTranslationUnitInfo *RTUI =
> -static_cast(UserData);
> + const ReparseTranslationUnitInfo *RTUI =
> + static_cast(UserData);
>RTUI->result = CXError_Failure;
>
>CXTranslationUnit TU = RTUI->TU;
Re: r212396 - PlistSupport.h: avoid gcc 'defined but not used' warning
On Sun, Jul 6, 2014 at 12:59 AM, Alp Toker wrote:
> Author: alp
> Date: Sun Jul 6 02:59:14 2014
> New Revision: 212396
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212396&view=rev
> Log:
> PlistSupport.h: avoid gcc 'defined but not used' warning
Is this warning helpful? Should we just disable it? I assume Clang's
warning here is smart enough not to warn for things in headers?
> Modified:
> cfe/trunk/include/clang/Basic/PlistSupport.h
> cfe/trunk/lib/ARCMigrate/PlistReporter.cpp
> cfe/trunk/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
>
> Modified: cfe/trunk/include/clang/Basic/PlistSupport.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/PlistSupport.h?rev=212396&r1=212395&r2=212396&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/PlistSupport.h (original)
> +++ cfe/trunk/include/clang/Basic/PlistSupport.h Sun Jul 6 02:59:14 2014
> @@ -19,12 +19,6 @@ namespace clang {
> namespace markup {
> typedef llvm::DenseMap FIDMap;
>
> -static const char *PlistHeader =
> -"\n"
> -" -"\"http://www.apple.com/DTDs/PropertyList-1.0.dtd\";>\n"
> -"\n";
> -
> static inline void AddFID(FIDMap &FIDs, SmallVectorImpl &V,
>const SourceManager &SM, SourceLocation L) {
>FileID FID = SM.getFileID(SM.getExpansionLoc(L));
> @@ -49,6 +43,15 @@ static inline raw_ostream &Indent(raw_os
>return o;
> }
>
> +static inline raw_ostream &EmitPlistHeader(raw_ostream &o) {
I don't think this function needs to be static, does it? If it's just
"inline" then it can be deduped by the linker, etc. (if it happens to
not get inlined)
Also, it might be simpler just to have the function return the string
for use, rather than making it so the string can only be used for
ostream emission like this. Or should we just do the obvious fix and
declare the string in the header and define it in the implementation
file, as usual?
> + static const char *PlistHeader =
> + "\n"
> + " + "\"http://www.apple.com/DTDs/PropertyList-1.0.dtd\";>\n"
> + "\n";
> + return o << PlistHeader;
> +}
> +
> static inline raw_ostream &EmitInteger(raw_ostream &o, int64_t value) {
>o << "";
>o << value;
>
> Modified: cfe/trunk/lib/ARCMigrate/PlistReporter.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ARCMigrate/PlistReporter.cpp?rev=212396&r1=212395&r2=212396&view=diff
> ==
> --- cfe/trunk/lib/ARCMigrate/PlistReporter.cpp (original)
> +++ cfe/trunk/lib/ARCMigrate/PlistReporter.cpp Sun Jul 6 02:59:14 2014
> @@ -63,8 +63,7 @@ void arcmt::writeARCDiagsToPlist(const s
> return;
>}
>
> - // Write the plist header.
> - o << PlistHeader;
> + EmitPlistHeader(o);
>
>// Write the root object: a containing...
>// - "files", an mapping from FIDs to file names
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp?rev=212396&r1=212395&r2=212396&view=diff
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp Sun Jul 6
> 02:59:14 2014
> @@ -345,8 +345,7 @@ void PlistDiagnostics::FlushDiagnosticsI
> return;
>}
>
> - // Write the plist header.
> - o << PlistHeader;
> + EmitPlistHeader(o);
>
>// Write the root object: a containing...
>// - "clang_version", the string representation of clang version
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212388 - Use non-intrusive refcounting for TargetOptions
On Sat, Jul 5, 2014 at 10:26 PM, Alp Toker wrote:
> Author: alp
> Date: Sun Jul 6 00:26:44 2014
> New Revision: 212388
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212388&view=rev
> Log:
> Use non-intrusive refcounting for TargetOptions
Awesome - thanks! (love incremental improvement, especially around
ownership semantics)
> Modified:
> cfe/trunk/include/clang/Basic/TargetInfo.h
> cfe/trunk/include/clang/Basic/TargetOptions.h
> cfe/trunk/include/clang/Frontend/ASTUnit.h
> cfe/trunk/include/clang/Frontend/CompilerInvocation.h
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/lib/Frontend/ASTUnit.cpp
> cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp
> cfe/trunk/lib/Frontend/CompilerInstance.cpp
> cfe/trunk/unittests/Basic/SourceManagerTest.cpp
> cfe/trunk/unittests/Lex/LexerTest.cpp
> cfe/trunk/unittests/Lex/PPCallbacksTest.cpp
> cfe/trunk/unittests/Lex/PPConditionalDirectiveRecordTest.cpp
>
> Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=212388&r1=212387&r2=212388&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
> +++ cfe/trunk/include/clang/Basic/TargetInfo.h Sun Jul 6 00:26:44 2014
> @@ -47,7 +47,7 @@ namespace Builtin { struct Info; }
> /// \brief Exposes information about the current target.
> ///
> class TargetInfo : public RefCountedBase {
> - IntrusiveRefCntPtr TargetOpts;
> + std::shared_ptr TargetOpts;
>llvm::Triple Triple;
> protected:
>// Target values set by the ctor of the actual target implementation.
> Default
> @@ -94,8 +94,9 @@ public:
>/// \param Opts - The options to use to initialize the target. The target
> may
>/// modify the options to canonicalize the target feature information to
> match
>/// what the backend expects.
> - static TargetInfo* CreateTargetInfo(DiagnosticsEngine &Diags,
> - TargetOptions *Opts);
> + static TargetInfo *
> + CreateTargetInfo(DiagnosticsEngine &Diags,
> + const std::shared_ptr &Opts);
>
>virtual ~TargetInfo();
>
> @@ -105,10 +106,6 @@ public:
> return *TargetOpts;
>}
>
> - void setTargetOpts(TargetOptions *TargetOpts) {
> -this->TargetOpts = TargetOpts;
> - }
> -
>///=== Target Data Type Query Methods
> ---===//
>enum IntType {
> NoInt = 0,
>
> Modified: cfe/trunk/include/clang/Basic/TargetOptions.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetOptions.h?rev=212388&r1=212387&r2=212388&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/TargetOptions.h (original)
> +++ cfe/trunk/include/clang/Basic/TargetOptions.h Sun Jul 6 00:26:44 2014
> @@ -15,15 +15,13 @@
> #ifndef LLVM_CLANG_FRONTEND_TARGETOPTIONS_H
> #define LLVM_CLANG_FRONTEND_TARGETOPTIONS_H
>
> -#include "clang/Basic/LLVM.h"
> -#include "llvm/ADT/IntrusiveRefCntPtr.h"
> #include
> #include
>
> namespace clang {
>
> /// \brief Options for controlling the target.
> -class TargetOptions : public RefCountedBase {
> +class TargetOptions {
> public:
>/// If given, the name of the target triple to compile for. If not given
> the
>/// target will be selected to match the host.
>
> Modified: cfe/trunk/include/clang/Frontend/ASTUnit.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/ASTUnit.h?rev=212388&r1=212387&r2=212388&view=diff
> ==
> --- cfe/trunk/include/clang/Frontend/ASTUnit.h (original)
> +++ cfe/trunk/include/clang/Frontend/ASTUnit.h Sun Jul 6 00:26:44 2014
> @@ -91,7 +91,7 @@ private:
>IntrusiveRefCntPtr Target;
>IntrusiveRefCntPtrPP;
>IntrusiveRefCntPtr Ctx;
> - IntrusiveRefCntPtr TargetOpts;
> + std::shared_ptr TargetOpts;
>IntrusiveRefCntPtr HSOpts;
>IntrusiveRefCntPtr Reader;
>bool HadModuleLoaderFatalFailure;
>
> Modified: cfe/trunk/include/clang/Frontend/CompilerInvocation.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CompilerInvocation.h?rev=212388&r1=212387&r2=212388&view=diff
> ==
> --- cfe/trunk/include/clang/Frontend/CompilerInvocation.h (original)
> +++ cfe/trunk/include/clang/Frontend/CompilerInvocation.h Sun Jul 6 00:26:44
> 2014
> @@ -57,7 +57,7 @@ public:
>std::shared_ptr LangOpts;
>
>/// Options controlling the target.
> - IntrusiveRefCntPtr TargetOpts;
> + std::shared_ptr TargetOpts;
>
>/// Options controlling the diagnostic engine.
>IntrusiveRefCntPtr DiagnosticOpts;
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL:
> http://llvm.org/viewvc/llvm-
Re: [PATCH] Win64 ABI shouldn't extend integer type arguments.
lgtm For the record, mingw64 GCC does the same thing: _foobar: .seh_endprologue movzwl %cx, %eax ret .seh_endproc Comment at: test/CodeGen/2007-06-18-SextAttrAggregate.c:2 @@ -1,3 +1,3 @@ // RUN: %clang_cc1 %s -o - -emit-llvm | FileCheck %s -// XFAIL: aarch64, arm64 +// XFAIL: aarch64, arm64, x86_64-pc-win32 Let's just give this an explicit x86 triple. http://reviews.llvm.org/D4380 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] -verify enhancement to support matching "any" line in included files
We generally try not to test against system headers - such a test case
should just include a local file and then the line number would be
known.
Is there a particular need to test some behavior against a system header?
On Thu, Jul 3, 2014 at 6:32 AM, Andy Gibbs wrote:
> Hi,
>
> I have made an enhancement to the -verify function of clang to support
> matching diagnostics in included header files where the line number is not
> necessarily known (or constant).
>
> Currently, matching a diagnostic in an included file is done as in the
> following fragment:
>
> // expected-warning@+2 {{incompatible}} expected-warning@+2 {{literal}}
> // expected-note@stdio.h:359 {{here}}
> printf(12);
>
> Problem is, the line number inside stdio.h is dependent on the system, so
> the attached patch provides support for substituting the line number for
> '*', as in:
>
> // expected-note@stdio.h:* {{here}}
>
> so that the diagnostic is matched without the line number being known.
>
> I've intentially limited this feature to line numbers in external files only
> since the line numbers in the main source file should be always "known".
> While this change may not have an immediate and particular purpose for the
> clang test-suite itself, I personally feel it is a good and useful
> enhancement to -verify for people (like me!) who use this for testing
> 3rd-party library code.
>
> Please let me know if this has support/approval for being committed...
>
> Thanks
>
> Andy
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212481 - Driver: Produce crash diagnostics more often on Windows
Author: rnk
Date: Mon Jul 7 15:23:27 2014
New Revision: 212481
URL: http://llvm.org/viewvc/llvm-project?rev=212481&view=rev
Log:
Driver: Produce crash diagnostics more often on Windows
Assertion failures call abort(), which return an exit code of 3 on
Windows. The 'not' utility has the same check.
Unfortunately, the crash-report.c test requires a shell, so it does not
run for me locally, so I can only test this manually.
There's still more work to be done here: we should generate a batch
script instead of a shell script on Windows.
Modified:
cfe/trunk/tools/driver/driver.cpp
Modified: cfe/trunk/tools/driver/driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/driver.cpp?rev=212481&r1=212480&r2=212481&view=diff
==
--- cfe/trunk/tools/driver/driver.cpp (original)
+++ cfe/trunk/tools/driver/driver.cpp Mon Jul 7 15:23:27 2014
@@ -433,8 +433,13 @@ int main(int argc_, const char **argv_)
// If result status is < 0, then the driver command signalled an error.
// If result status is 70, then the driver command reported a fatal error.
-// In these cases, generate additional diagnostic information if possible.
-if (CommandRes < 0 || CommandRes == 70) {
+// On Windows, abort will return an exit code of 3. In these cases,
+// generate additional diagnostic information if possible.
+bool DiagnoseCrash = CommandRes < 0 || CommandRes == 70;
+#ifdef LLVM_ON_WIN32
+DiagnoseCrash |= CommandRes == 3;
+#endif
+if (DiagnoseCrash) {
TheDriver.generateCompilationDiagnostics(*C, FailingCommand);
break;
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH, resend] ARM: fix inline atomic handling ldrex/strex
Hi, I still think that this is pretty much the right solution: any environment compiling for an architecture that has ldrex/strex but doesn't want to use it should add some specific override. They seem to be in a massive minority. If they don't want to add their own OS to the triple they can try for a -mwhatever option (patches welcome, or at least grudgingly accepted). That said, this patch doesn't have any tests. We really need those to make sure no-one inadvertently changes this behaviour in future (if nothing else). Cheers. Tim. ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
Ah...then I'm glad we added the assertion. :-) Lifetime-extended temporaries aren't quite implemented correctly yet, but we should probably be removing or not even adding the state when the temporary is lifetime-extended. Unfortunately I don't have this paged in, but there's logic in processing auto destructors to handle this, and a bug (http://llvm.org/bugs/show_bug.cgi?id=19539) about how it's wrong. Jordan On Jul 7, 2014, at 13:13 , Manuel Klimek wrote: > Sigh. That triggers in Analysis/dtor.cpp for this CXXBindTemporaryExpr: > CXXBindTemporaryExpr 0x3c195d8 'class > LifetimeExtension::SaveOnVirtualDestruct' (CXXTemporary 0x3c195d0) > `-CXXTemporaryObjectExpr 0x3c19590 'class > LifetimeExtension::SaveOnVirtualDestruct' 'void (void)' > > I assume something fishy is going on for lifetime extended temporaries... > > > On Mon, Jul 7, 2014 at 8:38 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 11:37 , Manuel Klimek wrote: > >> On Mon, Jul 7, 2014 at 8:05 PM, Jordan Rose wrote: >> >> On Jul 7, 2014, at 10:50 , Manuel Klimek wrote: >> >>> On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose wrote: >>> >>> On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: >>> On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose wrote: On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: > >> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose >> wrote: >> Can you add an assertion at the end of a block that there are no >> outstanding temporary destructors in the current stack frame? That seems >> useful. >> >> Do you mean at the end of a VisitBlockDecl? > > No, during the path-sensitive run, so handleBlockExit. > > So you mean at the end of a CFG block? But here we might have outstanding > temporary dtors open (?) Oops, right. Was thinking too much in terms of AST structure. How about at the end of a function (inlined or not)? Could we say every time we transition from a block with a temp dtor terminator to a block that does not have a temp dtor terminator (or an unconditional terminator) we check? >>> >>> That sounds correct, but misses the case where we built the CFG wrong >>> (forgetting to add the branch in the correct place and thus never getting >>> to the temp dtor block at all). >>> >>> Makes sense. Do you have a hint where the right place on function exit to >>> check it would be? :) >> >> *checks* ExprEngine::processEndOfFunction. >> >> Hm, so we'll need to adjust the data structure to be indexed by stack frame >> somehow (use a map) instead of the pair? > > Eh, since it's an assertion I'd be fine with just iterating over it in a > helper function. Or better, using std::find_if (if it has proper begin/end > members). > ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[PATCH, resend] ARM: fix inline atomic handling ldrex/strex
Currently, clang emits atomic instructions only for Windows, Linux and
some BSDs, but not for other OSes (even if hardware supports atomics).
The test whether ldrex/strex are available at all is also a bit wrong
and excludes e.g. the entire M profile.
This patch allows atomics on hardware that supports them for all OSes,
including "no OS" (aka bare metal), which was excluded without good
reason. Instead of allowing inline atomics only on some OSes, let's
allow them everywhere and have those that *don't* want them explicitly
opt out.
Also, since the M profile does not support 8byte atomics, disable those
for that profile.
Previously, there was some disagreement about whether this should be
handled by adding more OSes to the list of allowed atomic users, but
that still excludes some profiles and unfairly excludes a lot of OSes
from fast atomics. I still think the "atomics/no atomics" decision
should not be this pessimistic.Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp (revision 210990)
+++ lib/Basic/Targets.cpp (working copy)
@@ -3457,27 +3457,14 @@
static const Builtin::Info BuiltinInfo[];
static bool shouldUseInlineAtomic(const llvm::Triple &T) {
-if (T.isOSWindows())
- return true;
-
-// On linux, binaries targeting old cpus call functions in libgcc to
-// perform atomic operations. The implementation in libgcc then calls into
-// the kernel which on armv6 and newer uses ldrex and strex. The net result
-// is that if we assume the kernel is at least as recent as the hardware,
-// it is safe to use atomic instructions on armv6 and newer.
-if (!T.isOSLinux() &&
-T.getOS() != llvm::Triple::FreeBSD &&
-T.getOS() != llvm::Triple::NetBSD &&
-T.getOS() != llvm::Triple::Bitrig)
- return false;
StringRef ArchName = T.getArchName();
if (T.getArch() == llvm::Triple::arm ||
T.getArch() == llvm::Triple::armeb) {
StringRef VersionStr;
if (ArchName.startswith("armv"))
-VersionStr = ArchName.substr(4);
+VersionStr = ArchName.substr(4, 1);
else if (ArchName.startswith("armebv"))
-VersionStr = ArchName.substr(6);
+VersionStr = ArchName.substr(6, 1);
else
return false;
unsigned Version;
@@ -3489,9 +3476,9 @@
T.getArch() == llvm::Triple::thumbeb);
StringRef VersionStr;
if (ArchName.startswith("thumbv"))
- VersionStr = ArchName.substr(6);
+ VersionStr = ArchName.substr(6, 1);
else if (ArchName.startswith("thumbebv"))
- VersionStr = ArchName.substr(8);
+ VersionStr = ArchName.substr(8, 1);
else
return false;
unsigned Version;
@@ -3835,6 +3822,13 @@
if (!getCPUDefineSuffix(Name))
return false;
+// Cortex M does not support 8 byte atomics, while general Thumb2 does.
+StringRef Profile = getCPUProfile(Name);
+if (Profile == "M" && MaxAtomicInlineWidth) {
+ MaxAtomicPromoteWidth = 32;
+ MaxAtomicInlineWidth = 32;
+}
+
CPU = Name;
return true;
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
Sigh. That triggers in Analysis/dtor.cpp for this CXXBindTemporaryExpr: CXXBindTemporaryExpr 0x3c195d8 'class LifetimeExtension::SaveOnVirtualDestruct' (CXXTemporary 0x3c195d0) `-CXXTemporaryObjectExpr 0x3c19590 'class LifetimeExtension::SaveOnVirtualDestruct' 'void (void)' I assume something fishy is going on for lifetime extended temporaries... On Mon, Jul 7, 2014 at 8:38 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 11:37 , Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 8:05 PM, Jordan Rose wrote: > >> >> On Jul 7, 2014, at 10:50 , Manuel Klimek wrote: >> >> On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose >> wrote: >> >>> >>> On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: >>> >>> On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose >>> wrote: >>> On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose > wrote: > >> Can you add an assertion at the end of a block that there are no >> outstanding temporary destructors in the current stack frame? That seems >> useful. >> > > Do you mean at the end of a VisitBlockDecl? > > > No, during the path-sensitive run, so handleBlockExit. > So you mean at the end of a CFG block? But here we might have outstanding temporary dtors open (?) Oops, right. Was thinking too much in terms of AST structure. How about at the end of a function (inlined or not)? >>> >>> Could we say every time we transition from a block with a temp dtor >>> terminator to a block that does not have a temp dtor terminator (or an >>> unconditional terminator) we check? >>> >>> >>> That sounds correct, but misses the case where we built the CFG wrong >>> (forgetting to add the branch in the correct place and thus never getting >>> to the temp dtor block at all). >>> >> >> Makes sense. Do you have a hint where the right place on function exit to >> check it would be? :) >> >> >> *checks* ExprEngine::processEndOfFunction. >> > > Hm, so we'll need to adjust the data structure to be indexed by stack > frame somehow (use a map) instead of the pair? > > > Eh, since it's an assertion I'd be fine with just iterating over it in a > helper function. Or better, using std::find_if (if it has proper begin/end > members). > ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] GCC compatibility: pass -z linker options to the linker
Sadly, I think if gcc documents it we should go ahead and copy that behavior. It's a bit annoying, but the precedent is there and passing it through doesn't harm anything or make it noticeably more difficult to handle. http://reviews.llvm.org/D4393 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[PATCH] Make pretty-print output valid OpenCL code
Pretty-printing OpenCL code from an AST does not produce valid,
compilable code. Making this possible is valuable for certain kinds of
source-to-source translation.
In this patch, I try to rectify two issues with the pretty-printed code.
Specifically:
1) The AST treats "local" variable declarations as having a special
storage class specifier, which pretty-prints as <> in
VisitVarDecl. As a result, these declarations give a syntax error when
one attempts to compile the pretty-printed code.
2) VisitFunctionDecl will print function attributes after the function
declaration, which is valid syntax for most attributes, but OpenCL
function attributes specifically must come before the function declaration.
Regards,
Paul Fox
diff --git lib/AST/DeclPrinter.cpp lib/AST/DeclPrinter.cpp
index e5e5130..85ee083 100644
--- lib/AST/DeclPrinter.cpp
+++ lib/AST/DeclPrinter.cpp
@@ -384,6 +384,11 @@ void DeclPrinter::VisitEnumConstantDecl(EnumConstantDecl *D) {
}
void DeclPrinter::VisitFunctionDecl(FunctionDecl *D) {
+ if(Policy.LangOpts.OpenCL && D->hasAttrs()) {
+prettyPrintAttributes(D);
+Out << ' ';
+ }
+
CXXConstructorDecl *CDecl = dyn_cast(D);
CXXConversionDecl *ConversionDecl = dyn_cast(D);
if (!Policy.SuppressSpecifiers) {
@@ -563,7 +568,8 @@ void DeclPrinter::VisitFunctionDecl(FunctionDecl *D) {
Ty.print(Out, Policy, Proto);
}
- prettyPrintAttributes(D);
+ if(!Policy.LangOpts.OpenCL)
+prettyPrintAttributes(D);
if (D->isPure())
Out << " = 0";
@@ -651,7 +657,7 @@ void DeclPrinter::VisitLabelDecl(LabelDecl *D) {
void DeclPrinter::VisitVarDecl(VarDecl *D) {
if (!Policy.SuppressSpecifiers) {
StorageClass SC = D->getStorageClass();
-if (SC != SC_None)
+if (SC != SC_None && SC != SC_OpenCLWorkGroupLocal)
Out << VarDecl::getStorageClassSpecifierString(SC) << " ";
switch (D->getTSCSpec()) {
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] GCC compatibility: pass -z linker options to the linker
>>! In D4393#5, @joerg wrote: > I'm against this. I haven't seen enough evidence of use to justify it, other > options like -R are certainly a lot more popular... FWIW I'm in favor. -z is not uncommon in my experience. That said, a principled way to handle this would be to forward exactly the set of flags that gcc documents: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options If you submit a patch to gcc to document -z as a linker option, then we can add it to clang and be done with it. =D http://reviews.llvm.org/D4393 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212425 - Add an AST node for __leave statements, hook it up.
On Sun, Jul 6, 2014 at 6:14 PM, Chandler Carruth wrote: > > On Sun, Jul 6, 2014 at 6:00 PM, Nico Weber wrote: > >> I didn't modify AddStmtExprs() in ASTWriter.cpp, since none of the SEH >> nodes are in there (and e.g. STMT_CXX_TRY isn't either). Does anyone know >> what this function is good for, and if it should be updated with STMTs that >> are currently missing from there? > > > It should be used as part of the AST serialization, specifically to build > up the types of expressions which can be serialized... Not sure why we're > missing so much from that, or why it is factored this way. Most of the > statement seralization is nicely factored into ASTWriterStmt.cpp but for > some reason this vestige remains. Maybe it is completely dead code now? We > may just not need the meta-records it is streaming > No tests fail if I comment out the call to WriteBlockInfoBlock. But the commit message from r125086 gives a hint: With these abbrevs, the output of `clang -cc1 -fms-extensions -emit-pch -o test.ast test.cc && llvm-bcanalyzer test.ast` is nicer to read. So we should probably add the missing entries, and a test that FileChecks llvm-bcanalyzer output. ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Jul 7, 2014, at 11:37 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 8:05 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:50 , Manuel Klimek wrote: > >> On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose wrote: >> >> On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: >> >>> On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose wrote: >>> >>> On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: >>> On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: > Can you add an assertion at the end of a block that there are no > outstanding temporary destructors in the current stack frame? That seems > useful. > > Do you mean at the end of a VisitBlockDecl? No, during the path-sensitive run, so handleBlockExit. So you mean at the end of a CFG block? But here we might have outstanding temporary dtors open (?) >>> >>> Oops, right. Was thinking too much in terms of AST structure. How about at >>> the end of a function (inlined or not)? >>> >>> Could we say every time we transition from a block with a temp dtor >>> terminator to a block that does not have a temp dtor terminator (or an >>> unconditional terminator) we check? >> >> That sounds correct, but misses the case where we built the CFG wrong >> (forgetting to add the branch in the correct place and thus never getting to >> the temp dtor block at all). >> >> Makes sense. Do you have a hint where the right place on function exit to >> check it would be? :) > > *checks* ExprEngine::processEndOfFunction. > > Hm, so we'll need to adjust the data structure to be indexed by stack frame > somehow (use a map) instead of the pair? Eh, since it's an assertion I'd be fine with just iterating over it in a helper function. Or better, using std::find_if (if it has proper begin/end members). ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Mon, Jul 7, 2014 at 8:05 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:50 , Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose wrote: > >> >> On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: >> >> On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose >> wrote: >> >>> >>> On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: >>> >>> On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose >>> wrote: >>> On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: > Can you add an assertion at the end of a block that there are no > outstanding temporary destructors in the current stack frame? That seems > useful. > Do you mean at the end of a VisitBlockDecl? No, during the path-sensitive run, so handleBlockExit. >>> >>> So you mean at the end of a CFG block? But here we might have >>> outstanding temporary dtors open (?) >>> >>> >>> Oops, right. Was thinking too much in terms of AST structure. How about >>> at the end of a function (inlined or not)? >>> >> >> Could we say every time we transition from a block with a temp dtor >> terminator to a block that does not have a temp dtor terminator (or an >> unconditional terminator) we check? >> >> >> That sounds correct, but misses the case where we built the CFG wrong >> (forgetting to add the branch in the correct place and thus never getting >> to the temp dtor block at all). >> > > Makes sense. Do you have a hint where the right place on function exit to > check it would be? :) > > > *checks* ExprEngine::processEndOfFunction. > Hm, so we'll need to adjust the data structure to be indexed by stack frame somehow (use a map) instead of the pair? ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[PATCH] Factor getObjCEncodingForPropertyType out of getObjCEncodingForPropertyDecl
Hi everyone. I'd like to be able to get the type encoding of an ObjC
property by itself without forming an entire ObjCPropertyDecl. Here's a
small patch that factors ASTContext::getObjCEncodingForPropertyType out of
the larger getObjCEncodingForPropertyDecl method.
-Joe
diff --git a/include/clang/AST/ASTContext.h b/include/clang/AST/ASTContext.h
index b0de90c..4f78862 100644
--- a/include/clang/AST/ASTContext.h
+++ b/include/clang/AST/ASTContext.h
@@ -1373,6 +1373,10 @@ public:
void getObjCEncodingForType(QualType T, std::string &S,
const FieldDecl *Field=nullptr) const;
+ /// \brief Emit the Objective-C property type encoding for the given
+ /// type \p T into \p S.
+ void getObjCEncodingForPropertyType(QualType T, std::string &S) const;
+
void getLegacyIntegralTypeEncoding(QualType &t) const;
/// \brief Put the string version of the type qualifiers \p QT into \p S.
diff --git a/lib/AST/ASTContext.cpp b/lib/AST/ASTContext.cpp
index 4250850..6526a77 100644
--- a/lib/AST/ASTContext.cpp
+++ b/lib/AST/ASTContext.cpp
@@ -5022,9 +5022,7 @@ void ASTContext::getObjCEncodingForPropertyDecl(const
ObjCPropertyDecl *PD,
// Encode result type.
// GCC has some special rules regarding encoding of properties which
// closely resembles encoding of ivars.
- getObjCEncodingForTypeImpl(PD->getType(), S, true, true, nullptr,
- true /* outermost type */,
- true /* encoding for property */);
+ getObjCEncodingForPropertyType(PD->getType(), S);
if (PD->isReadOnly()) {
S += ",R";
@@ -5097,6 +5095,16 @@ void ASTContext::getObjCEncodingForType(QualType T,
std::string& S,
true /* outermost type */);
}
+void ASTContext::getObjCEncodingForPropertyType(QualType T,
+std::string& S) const {
+ // Encode result type.
+ // GCC has some special rules regarding encoding of properties which
+ // closely resembles encoding of ivars.
+ getObjCEncodingForTypeImpl(T, S, true, true, nullptr,
+ true /* outermost type */,
+ true /* encoding property */);
+}
+
static char getObjCEncodingForPrimitiveKind(const ASTContext *C,
BuiltinType::Kind kind) {
switch (kind) {
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212060 - Consider module depedencies when checking a preamble in libclang
Ben Langmuir wrote on 07.07.2014 19:03:33: > I’ll fix the test to specify a unique module cache path. Thanks, that will certainly fix the test case problem! > In general, we use llvm::sys::path::system_temp_dir to create > the default module cache location. On Darwin, we use > DARWIN_USER_CACHE_DIR, which is user-specific so this isn’t an > issue. On Linux, we seem to honour the environment variable TMPDIR, > before falling back to /var/tmp. I don’t know if this is correct for > Linux; perhaps you know of a better way? I'm not really an expert here ... One option might be to include the user name in the temp directory name; I see for example /var/tmp/kdecache-uweigand (owned by my uweigand user ID) on my desktop machine ... Bye, Ulrich ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[libclc] r212470 - prepare-builtins: Fix broken build due to recent LLVM API change
Author: tstellar
Date: Mon Jul 7 12:46:45 2014
New Revision: 212470
URL: http://llvm.org/viewvc/llvm-project?rev=212470&view=rev
Log:
prepare-builtins: Fix broken build due to recent LLVM API change
Modified:
libclc/trunk/utils/prepare-builtins.cpp
Modified: libclc/trunk/utils/prepare-builtins.cpp
URL:
http://llvm.org/viewvc/llvm-project/libclc/trunk/utils/prepare-builtins.cpp?rev=212470&r1=212469&r2=212470&view=diff
==
--- libclc/trunk/utils/prepare-builtins.cpp (original)
+++ libclc/trunk/utils/prepare-builtins.cpp Mon Jul 7 12:46:45 2014
@@ -47,8 +47,15 @@ int main(int argc, char **argv) {
std::auto_ptr M;
{
+#if LLVM_350_AND_NEWER
+ErrorOr> BufferOrErr =
+ MemoryBuffer::getFile(InputFilename);
+std::unique_ptr &BufferPtr = BufferOrErr.get();
+if (std::error_code ec = BufferOrErr.getError())
+#else
UNIQUE_PTR BufferPtr;
if (ERROR_CODE ec = MemoryBuffer::getFileOrSTDIN(InputFilename, BufferPtr))
+#endif
ErrorMessage = ec.message();
else {
#if LLVM_VERSION_MAJOR > 3 || (LLVM_VERSION_MAJOR == 3 && LLVM_VERSION_MINOR >
4)
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Jul 7, 2014, at 10:50 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: > >> On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose wrote: >> >> On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: >> >>> On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: >>> >>> On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: >>> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: Can you add an assertion at the end of a block that there are no outstanding temporary destructors in the current stack frame? That seems useful. Do you mean at the end of a VisitBlockDecl? >>> >>> No, during the path-sensitive run, so handleBlockExit. >>> >>> So you mean at the end of a CFG block? But here we might have outstanding >>> temporary dtors open (?) >> >> Oops, right. Was thinking too much in terms of AST structure. How about at >> the end of a function (inlined or not)? >> >> Could we say every time we transition from a block with a temp dtor >> terminator to a block that does not have a temp dtor terminator (or an >> unconditional terminator) we check? > > That sounds correct, but misses the case where we built the CFG wrong > (forgetting to add the branch in the correct place and thus never getting to > the temp dtor block at all). > > Makes sense. Do you have a hint where the right place on function exit to > check it would be? :) *checks* ExprEngine::processEndOfFunction. ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Mon, Jul 7, 2014 at 7:42 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose wrote: > >> >> On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: >> >> On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose >> wrote: >> >>> >>> On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: >>> >>> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose >>> wrote: >>> Can you add an assertion at the end of a block that there are no outstanding temporary destructors in the current stack frame? That seems useful. >>> >>> Do you mean at the end of a VisitBlockDecl? >>> >>> >>> No, during the path-sensitive run, so handleBlockExit. >>> >> >> So you mean at the end of a CFG block? But here we might have outstanding >> temporary dtors open (?) >> >> >> Oops, right. Was thinking too much in terms of AST structure. How about >> at the end of a function (inlined or not)? >> > > Could we say every time we transition from a block with a temp dtor > terminator to a block that does not have a temp dtor terminator (or an > unconditional terminator) we check? > > > That sounds correct, but misses the case where we built the CFG wrong > (forgetting to add the branch in the correct place and thus never getting > to the temp dtor block at all). > Makes sense. Do you have a hint where the right place on function exit to check it would be? :) ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Generate warning when explicitly specified vectorization fails
On Thu, Jul 3, 2014 at 9:23 AM, Diego Novillo wrote: > This change is raising the severity of this diagnostic. Do we really want > to cause build failures in this situation when the code is built with > -Werror? > > I think I would be fine with it, if this diagnostic was only triggered > when the user specified a #pragma, but if the failure is in the vectorizer, > with no hints from the user, then I think a warning is too strong. Even > when using #pragma, I'm not sure I'd like a warning here. > I'd put my vote in for having a warning if a #pragma optimization directive could not be followed. This assumes the warning is instructive enough that the user can easily fix the issue. I added support for loop unrolling pragmas (following Tyler's vectorization work) so the focus for us is loop unrolling. For the target we care about (CUDA/GPU) a missed loop unroll can be a massive performance loss and the user should know about it. Whatever is decided, I'll make the diagnostic severity of loop unrolling pragma diagnostics match that of the vectorization ones. Mark > > return false; >> } >> >> @@ -1276,8 +1292,7 @@ >>emitOptimizationRemarkAnalysis( >>F->getContext(), DEBUG_TYPE, *F, L->getStartLoc(), >>"loop not vectorized due to NoImplicitFloat attribute"); >> - emitOptimizationRemarkMissed(F->getContext(), DEBUG_TYPE, *F, >> - L->getStartLoc(), Hints.emitRemark()); >> + emitMissedWarning(F, L, Hints); >> > > Likewise. > > > Diego. > ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212060 - Consider module depedencies when checking a preamble in libclang
> On Jul 7, 2014, at 10:03 AM, Ben Langmuir wrote:
>
>>
>> On Jul 7, 2014, at 9:27 AM, Ulrich Weigand wrote:
>>
>> Ben Langmuir wrote on 07.07.2014 18:12:21:
>>
And indeed running clang directly against the temporary files created
>> by
the test case I get:
uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
-fmodules
>> -I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
/tmp/libclang-test-6a8ede/MFile.m:2:25: error: variable has incomplete
>> type
'struct Foo'
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^
/tmp/libclang-test-6a8ede/MFile.m:2:21: note: forward declaration of
'struct Foo'
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^
1 error generated.
>>>
>>> Could you try this again with the additional flags -Wmodule-build -
>>> Wauto-import as a sanity check that the module is being found? It
>>> looks like the module isn’t being imported properly...
>>
>> Hmm, interesting. I get:
>>
>> uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
>> -fmodules -I /tmp/libclang-test-75f2f2 /tmp/libclang-test-75f2f2/MFile.m
>> -Wmodule-build -Wauto-import
>> /tmp/libclang-test-75f2f2/MFile.m:1:1: warning: treating #include as an
>> import of module 'A' [-Wauto-import]
>> #include "HeaderFile.h"
>> ^~~
>> @import A;
>> /tmp/libclang-test-75f2f2/MFile.m:1:2: remark: building module 'A' as
>> '/var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T/A-25ZFQ1VWL2WP7.pcm'
>> [-Rmodule-build]
>>
>> #include "HeaderFile.h"
>> ^
>> /tmp/libclang-test-75f2f2/MFile.m:2:25: error: variable has incomplete type
>> 'struct Foo'
>> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>> ^
>> /tmp/libclang-test-75f2f2/MFile.m:2:21: note: forward declaration of
>> 'struct Foo'
>> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>> ^
>> 1 warning and 1 error generated.
>>
>> However, the really interesting fact is that afterwards,
>> there is no /var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T
>> directory -- and there cannot be, because there is a
>> /var/tmp/org.llvm.clang/ModuleCache directory, owned
>> by another user on the system, and my user ID does not
>> have the privileges to create subdirectories there ...
>>
>>
>> After I've removed that directory, the test case now passes!
>> (But it will presumably fail for other users now …)
>>
>> How is this supposed to work on a multi-user machine?
>
> I’ll fix the test to specify a unique module cache path.
r212467
> In general, we use llvm::sys::path::system_temp_dir to create the default
> module cache location. On Darwin, we use DARWIN_USER_CACHE_DIR, which is
> user-specific so this isn’t an issue. On Linux, we seem to honour the
> environment variable TMPDIR, before falling back to /var/tmp. I don’t know if
> this is correct for Linux; perhaps you know of a better way?
>
> Ben
>
>>
>> Bye,
>> Ulrich
>
>
> ___
> cfe-commits mailing list
> cfe-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212468 - Driver: Fix think-o in adding -ivfsoverlay flag to crashdumps
Author: bogner
Date: Mon Jul 7 12:34:40 2014
New Revision: 212468
URL: http://llvm.org/viewvc/llvm-project?rev=212468&view=rev
Log:
Driver: Fix think-o in adding -ivfsoverlay flag to crashdumps
If there isn't a VFS to overlay we shouldn't be adding a -ivfsoverlay
flag.
Modified:
cfe/trunk/lib/Driver/Driver.cpp
Modified: cfe/trunk/lib/Driver/Driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=212468&r1=212467&r2=212468&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Mon Jul 7 12:34:40 2014
@@ -550,9 +550,11 @@ void Driver::generateCompilationDiagnost
E = I + OldFilename.size();
I = Cmd.rfind(" ", I) + 1;
Cmd.replace(I, E - I, NewFilename.data(), NewFilename.size());
-// Add the VFS overlay to the reproduction script.
-I += NewFilename.size();
-Cmd.insert(I, std::string(" -ivfsoverlay ") + VFS.c_str());
+if (!VFS.empty()) {
+ // Add the VFS overlay to the reproduction script.
+ I += NewFilename.size();
+ Cmd.insert(I, std::string(" -ivfsoverlay ") + VFS.c_str());
+}
ScriptOS << Cmd;
Diag(clang::diag::note_drv_command_failed_diag_msg) << Script;
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: > >> >> On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: >> >> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose >> wrote: >> >>> Can you add an assertion at the end of a block that there are no >>> outstanding temporary destructors in the current stack frame? That seems >>> useful. >>> >> >> Do you mean at the end of a VisitBlockDecl? >> >> >> No, during the path-sensitive run, so handleBlockExit. >> > > So you mean at the end of a CFG block? But here we might have outstanding > temporary dtors open (?) > > > Oops, right. Was thinking too much in terms of AST structure. How about at > the end of a function (inlined or not)? > Could we say every time we transition from a block with a temp dtor terminator to a block that does not have a temp dtor terminator (or an unconditional terminator) we check? ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Jul 7, 2014, at 10:41 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 7:38 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: > >> On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: >> >> On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: >> >>> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: >>> Can you add an assertion at the end of a block that there are no >>> outstanding temporary destructors in the current stack frame? That seems >>> useful. >>> >>> Do you mean at the end of a VisitBlockDecl? >> >> No, during the path-sensitive run, so handleBlockExit. >> >> So you mean at the end of a CFG block? But here we might have outstanding >> temporary dtors open (?) > > Oops, right. Was thinking too much in terms of AST structure. How about at > the end of a function (inlined or not)? > > Could we say every time we transition from a block with a temp dtor > terminator to a block that does not have a temp dtor terminator (or an > unconditional terminator) we check? That sounds correct, but misses the case where we built the CFG wrong (forgetting to add the branch in the correct place and thus never getting to the temp dtor block at all). ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212467 - Use temporary module cache in test
Author: benlangmuir
Date: Mon Jul 7 12:34:37 2014
New Revision: 212467
URL: http://llvm.org/viewvc/llvm-project?rev=212467&view=rev
Log:
Use temporary module cache in test
Modified:
cfe/trunk/unittests/libclang/LibclangTest.cpp
Modified: cfe/trunk/unittests/libclang/LibclangTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/libclang/LibclangTest.cpp?rev=212467&r1=212466&r2=212467&view=diff
==
--- cfe/trunk/unittests/libclang/LibclangTest.cpp (original)
+++ cfe/trunk/unittests/libclang/LibclangTest.cpp Mon Jul 7 12:34:37 2014
@@ -434,7 +434,9 @@ TEST_F(LibclangReparseTest, ReparseWithM
WriteFile(HeaderName, std::string(HeaderTop) + HeaderBottom);
WriteFile(ModName, ModFile);
- const char *Args[] = { "-fmodules", "-I", TestDir.c_str() };
+ std::string ModulesCache = std::string("-fmodules-cache-path=") + TestDir;
+ const char *Args[] = { "-fmodules", ModulesCache.c_str(),
+ "-I", TestDir.c_str() };
int NumArgs = sizeof(Args) / sizeof(Args[0]);
ClangTU = clang_parseTranslationUnit(Index, MName.c_str(), Args, NumArgs,
nullptr, 0, TUFlags);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Jul 7, 2014, at 10:37 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: > >> On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: >> Can you add an assertion at the end of a block that there are no outstanding >> temporary destructors in the current stack frame? That seems useful. >> >> Do you mean at the end of a VisitBlockDecl? > > No, during the path-sensitive run, so handleBlockExit. > > So you mean at the end of a CFG block? But here we might have outstanding > temporary dtors open (?) Oops, right. Was thinking too much in terms of AST structure. How about at the end of a function (inlined or not)? ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Mon, Jul 7, 2014 at 7:29 PM, Jordan Rose wrote: > > On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: > >> Can you add an assertion at the end of a block that there are no >> outstanding temporary destructors in the current stack frame? That seems >> useful. >> > > Do you mean at the end of a VisitBlockDecl? > > > No, during the path-sensitive run, so handleBlockExit. > So you mean at the end of a CFG block? But here we might have outstanding temporary dtors open (?) ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Jul 7, 2014, at 10:28 , Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote: > Can you add an assertion at the end of a block that there are no outstanding > temporary destructors in the current stack frame? That seems useful. > > Do you mean at the end of a VisitBlockDecl? No, during the path-sensitive run, so handleBlockExit. ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
On Mon, Jul 7, 2014 at 6:48 PM, Jordan Rose wrote:
> Can you add an assertion at the end of a block that there are no
> outstanding temporary destructors in the current stack frame? That seems
> useful.
>
Do you mean at the end of a VisitBlockDecl?
>
>
> Comment at: lib/Analysis/CFG.cpp:3583
> @@ -3512,4 +3582,3 @@
> if (Stmt *Child = *I)
> - if (CFGBlock *R = VisitForTemporaryDtors(Child))
> -B = R;
> + if (CFGBlock *R = VisitForTemporaryDtors(Child, false, Context)) B
> = R;
>}
>
> Lost a newline here.
>
>
> Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:681-686
> @@ -663,1 +680,8 @@
>QualType varType = D.getBindTemporaryExpr()->getSubExpr()->getType();
> + for (ExplodedNode *Node : CleanDtorState) {
> +// FIXME: Inlining of temporary destructors is not supported yet
> anyway, so
> +// we just put a NULL region for now. This will need to be changed
> later.
> +VisitCXXDestructor(varType, nullptr, D.getBindTemporaryExpr(),
> + /*IsBase=*/false, Node, Dst);
> + }
> +}
>
> I'm not sure you're supposed to reuse `Dst` with multiple builders.
> However, you know there's only one node in `CleanDtorState`, so you should
> be able to just skip the loop.
>
> http://reviews.llvm.org/D3627
>
>
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212466 - Fix memory leak in FileSystemStatCache.
Author: klimek
Date: Mon Jul 7 12:00:49 2014
New Revision: 212466
URL: http://llvm.org/viewvc/llvm-project?rev=212466&view=rev
Log:
Fix memory leak in FileSystemStatCache.
Patch by Guochun Shi.
Modified:
cfe/trunk/lib/Basic/FileSystemStatCache.cpp
Modified: cfe/trunk/lib/Basic/FileSystemStatCache.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileSystemStatCache.cpp?rev=212466&r1=212465&r2=212466&view=diff
==
--- cfe/trunk/lib/Basic/FileSystemStatCache.cpp (original)
+++ cfe/trunk/lib/Basic/FileSystemStatCache.cpp Mon Jul 7 12:00:49 2014
@@ -111,6 +111,7 @@ bool FileSystemStatCache::get(const char
// If not, close the file if opened.
if (F && *F) {
(*F)->close();
+ delete *F;
*F = nullptr;
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212060 - Consider module depedencies when checking a preamble in libclang
> On Jul 7, 2014, at 9:27 AM, Ulrich Weigand wrote:
>
> Ben Langmuir wrote on 07.07.2014 18:12:21:
>
>>> And indeed running clang directly against the temporary files created
> by
>>> the test case I get:
>>> uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
>>> -fmodules
> -I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
>>> /tmp/libclang-test-6a8ede/MFile.m:2:25: error: variable has incomplete
> type
>>> 'struct Foo'
>>> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>>> ^
>>> /tmp/libclang-test-6a8ede/MFile.m:2:21: note: forward declaration of
>>> 'struct Foo'
>>> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>>> ^
>>> 1 error generated.
>>
>> Could you try this again with the additional flags -Wmodule-build -
>> Wauto-import as a sanity check that the module is being found? It
>> looks like the module isn’t being imported properly...
>
> Hmm, interesting. I get:
>
> uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
> -fmodules -I /tmp/libclang-test-75f2f2 /tmp/libclang-test-75f2f2/MFile.m
> -Wmodule-build -Wauto-import
> /tmp/libclang-test-75f2f2/MFile.m:1:1: warning: treating #include as an
> import of module 'A' [-Wauto-import]
> #include "HeaderFile.h"
> ^~~
> @import A;
> /tmp/libclang-test-75f2f2/MFile.m:1:2: remark: building module 'A' as
> '/var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T/A-25ZFQ1VWL2WP7.pcm'
> [-Rmodule-build]
>
> #include "HeaderFile.h"
> ^
> /tmp/libclang-test-75f2f2/MFile.m:2:25: error: variable has incomplete type
> 'struct Foo'
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>^
> /tmp/libclang-test-75f2f2/MFile.m:2:21: note: forward declaration of
> 'struct Foo'
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>^
> 1 warning and 1 error generated.
>
> However, the really interesting fact is that afterwards,
> there is no /var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T
> directory -- and there cannot be, because there is a
> /var/tmp/org.llvm.clang/ModuleCache directory, owned
> by another user on the system, and my user ID does not
> have the privileges to create subdirectories there ...
>
>
> After I've removed that directory, the test case now passes!
> (But it will presumably fail for other users now …)
>
> How is this supposed to work on a multi-user machine?
I’ll fix the test to specify a unique module cache path. In general, we use
llvm::sys::path::system_temp_dir to create the default module cache location.
On Darwin, we use DARWIN_USER_CACHE_DIR, which is user-specific so this isn’t
an issue. On Linux, we seem to honour the environment variable TMPDIR, before
falling back to /var/tmp. I don’t know if this is correct for Linux; perhaps
you know of a better way?
Ben
>
> Bye,
> Ulrich
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Proposal on how to fix temporary dtors.
Can you add an assertion at the end of a block that there are no outstanding
temporary destructors in the current stack frame? That seems useful.
Comment at: lib/Analysis/CFG.cpp:3583
@@ -3512,4 +3582,3 @@
if (Stmt *Child = *I)
- if (CFGBlock *R = VisitForTemporaryDtors(Child))
-B = R;
+ if (CFGBlock *R = VisitForTemporaryDtors(Child, false, Context)) B = R;
}
Lost a newline here.
Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:681-686
@@ -663,1 +680,8 @@
QualType varType = D.getBindTemporaryExpr()->getSubExpr()->getType();
+ for (ExplodedNode *Node : CleanDtorState) {
+// FIXME: Inlining of temporary destructors is not supported yet anyway, so
+// we just put a NULL region for now. This will need to be changed later.
+VisitCXXDestructor(varType, nullptr, D.getBindTemporaryExpr(),
+ /*IsBase=*/false, Node, Dst);
+ }
+}
I'm not sure you're supposed to reuse `Dst` with multiple builders. However,
you know there's only one node in `CleanDtorState`, so you should be able to
just skip the loop.
http://reviews.llvm.org/D3627
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212138 - Driver: Handle /GR- in a compatible way with MSVC
I think either this or r212125 broke "check-asan" and Chromium build but it
was hidden by another build failure (r211216).
Can you please take a look at "TestCases/Windows/dll_cerr.cc" (or Chromium
failures) ?
2014-07-02 2:24 GMT+04:00 David Majnemer :
> Author: majnemer
> Date: Tue Jul 1 17:24:56 2014
> New Revision: 212138
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212138&view=rev
> Log:
> Driver: Handle /GR- in a compatible way with MSVC
>
> There are slight differences between /GR- and -fno-rtti which made
> mapping one to the other inappropriate.
>
> -fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
> information for the v-table.
>
> /GR- does not generate complete object locators and thus will not
> reference them in vftables. However, constructs like dynamic_cast and
> typeid are permitted.
>
> This should bring our implementation of RTTI up to semantic parity with
> MSVC modulo bugs.
>
> Added:
> cfe/trunk/test/CodeGenCXX/microsoft-no-rtti-data.cpp
> Modified:
> cfe/trunk/include/clang/Basic/LangOptions.def
> cfe/trunk/include/clang/Driver/CC1Options.td
> cfe/trunk/include/clang/Driver/CLCompatOptions.td
> cfe/trunk/lib/AST/VTableBuilder.cpp
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> cfe/trunk/lib/CodeGen/MicrosoftRTTI.cpp
> cfe/trunk/lib/Driver/Tools.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/test/Driver/cl-fallback.c
> cfe/trunk/test/Driver/cl-options.c
>
> Modified: cfe/trunk/include/clang/Basic/LangOptions.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=212138&r1=212137&r2=212138&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/LangOptions.def (original)
> +++ cfe/trunk/include/clang/Basic/LangOptions.def Tue Jul 1 17:24:56 2014
> @@ -84,6 +84,7 @@ LANGOPT(CXXExceptions , 1, 0, "C++ e
> LANGOPT(SjLjExceptions, 1, 0, "setjmp-longjump exception handling")
> LANGOPT(TraditionalCPP, 1, 0, "traditional CPP emulation")
> LANGOPT(RTTI , 1, 1, "run-time type information")
> +LANGOPT(RTTIData , 1, 1, "emit run-time type information data")
> LANGOPT(MSBitfields , 1, 0, "Microsoft-compatible structure layout")
> LANGOPT(Freestanding, 1, 0, "freestanding implementation")
> LANGOPT(NoBuiltin , 1, 0, "disable builtin functions")
>
> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=212138&r1=212137&r2=212138&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
> +++ cfe/trunk/include/clang/Driver/CC1Options.td Tue Jul 1 17:24:56 2014
> @@ -484,6 +484,8 @@ def fobjc_subscripting_legacy_runtime :
>HelpText<"Allow Objective-C array and dictionary subscripting in legacy
> runtime">;
> def vtordisp_mode_EQ : Joined<["-"], "vtordisp-mode=">,
>HelpText<"Control vtordisp placement on win32 targets">;
> +def fno_rtti_data : Flag<["-"], "fno-rtti-data">,
> + HelpText<"Control emission of RTTI data">;
>
>
>
> //===--===//
> // Header Search Options
>
> Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=212138&r1=212137&r2=212138&view=diff
>
> ==
> --- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
> +++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Jul 1 17:24:56
> 2014
> @@ -58,8 +58,8 @@ def _SLASH_c : CLFlag<"c">, HelpText<"Co
> def _SLASH_D : CLJoinedOrSeparate<"D">, HelpText<"Define macro">,
>MetaVarName<"">, Alias;
> def _SLASH_E : CLFlag<"E">, HelpText<"Preprocess to stdout">, Alias;
> -def _SLASH_GR : CLFlag<"GR">, HelpText<"Enable RTTI">, Alias;
> -def _SLASH_GR_ : CLFlag<"GR-">, HelpText<"Disable RTTI">, Alias;
> +def _SLASH_GR : CLFlag<"GR">, HelpText<"Enable emission of RTTI data">;
> +def _SLASH_GR_ : CLFlag<"GR-">, HelpText<"Disable emission of RTTI data">;
> def _SLASH_GF_ : CLFlag<"GF-">, HelpText<"Disable string pooling">,
>Alias;
> def _SLASH_Gy : CLFlag<"Gy">, HelpText<"Put each function in its own
> section">,
>
> Modified: cfe/trunk/lib/AST/VTableBuilder.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/VTableBuilder.cpp?rev=212138&r1=212137&r2=212138&view=diff
>
> ==
> --- cfe/trunk/lib/AST/VTableBuilder.cpp (original)
> +++ cfe/trunk/lib/AST/VTableBuilder.cpp Tue Jul 1 17:24:56 2014
> @@ -2579,7 +2579,7 @@ public:
> Overriders(MostDerivedClass, CharUnits(), MostDerivedClass) {
>
Re: r211216 - CodeGen: improve ms instrincics support
I fixed this in r212465.
It's very sad the bug has hidden a few other bugs being introduced into the
codebase over the last couple of weeks...
2014-06-21 0:38 GMT+04:00 Reid Kleckner :
> Remember how I said it'd be OK if we provided
> _InterlockedCompareExchangePointer on x86? Well, doing that broke the
> sanitizers. Do 'check-asan' on 32-bit Windows to reproduce.
>
> This is the problematic code:
> inline static void *_InterlockedCompareExchangePointer(
> void *volatile *Destination,
> void *Exchange, void *Comparand) {
> return reinterpret_cast(
> _InterlockedCompareExchange(
> reinterpret_cast(Destination), // NOLINT
> reinterpret_cast(Exchange), // NOLINT
> reinterpret_cast(Comparand)));// NOLINT
> }
>
>
> On Wed, Jun 18, 2014 at 1:51 PM, Saleem Abdulrasool > wrote:
>
>> Author: compnerd
>> Date: Wed Jun 18 15:51:10 2014
>> New Revision: 211216
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=211216&view=rev
>> Log:
>> CodeGen: improve ms instrincics support
>>
>> Add support for _InterlockedCompareExchangePointer,
>> _InterlockExchangePointer,
>> _InterlockExchange. These are available as a compiler intrinsic on ARM
>> and x86.
>> These are used directly by the Windows SDK headers without use of the
>> intrin
>> header.
>>
>> Added:
>> cfe/trunk/test/CodeGen/ms-intrinsics.c
>> Modified:
>> cfe/trunk/include/clang/Basic/Builtins.def
>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> cfe/trunk/lib/Headers/Intrin.h
>>
>> Modified: cfe/trunk/include/clang/Basic/Builtins.def
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=211216&r1=211215&r2=211216&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/Builtins.def (original)
>> +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Jun 18 15:51:10 2014
>> @@ -683,9 +683,12 @@ LANGBUILTIN(__noop, "v.", "n", AL
>> LANGBUILTIN(__debugbreak, "v", "n", ALL_MS_LANGUAGES)
>> LANGBUILTIN(__va_start, "vc**.", "nt", ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedCompareExchange, "LiLiD*LiLi", "n",
>> ALL_MS_LANGUAGES)
>> +LANGBUILTIN(_InterlockedCompareExchangePointer, "v*v*D*v*v*", "n",
>> ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedIncrement, "LiLiD*", "n", ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedDecrement, "LiLiD*", "n", ALL_MS_LANGUAGES)
>> LANGBUILTIN(_InterlockedExchangeAdd, "LiLiD*Li", "n", ALL_MS_LANGUAGES)
>> +LANGBUILTIN(_InterlockedExchangePointer, "v*v*D*v*", "n",
>> ALL_MS_LANGUAGES)
>> +LANGBUILTIN(_InterlockedExchange, "LiLiD*Li", "n", ALL_MS_LANGUAGES)
>>
>> // C99 library functions
>> // C99 stdlib.h
>>
>> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=211216&r1=211215&r2=211216&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Jun 18 15:51:10 2014
>> @@ -1516,6 +1516,35 @@ RValue CodeGenFunction::EmitBuiltinExpr(
>> E->getArg(0), true);
>>case Builtin::BI__noop:
>> return RValue::get(nullptr);
>> + case Builtin::BI_InterlockedExchange:
>> + case Builtin::BI_InterlockedExchangePointer:
>> +return EmitBinaryAtomic(*this, llvm::AtomicRMWInst::Xchg, E);
>> + case Builtin::BI_InterlockedCompareExchangePointer: {
>> +llvm::Type *RTy;
>> +llvm::IntegerType *IntType =
>> + IntegerType::get(getLLVMContext(),
>> + getContext().getTypeSize(E->getType()));
>> +llvm::Type *IntPtrType = IntType->getPointerTo();
>> +
>> +llvm::Value *Destination =
>> + Builder.CreateBitCast(EmitScalarExpr(E->getArg(0)), IntPtrType);
>> +
>> +llvm::Value *Exchange = EmitScalarExpr(E->getArg(1));
>> +RTy = Exchange->getType();
>> +Exchange = Builder.CreatePtrToInt(Exchange, IntType);
>> +
>> +llvm::Value *Comparand =
>> + Builder.CreatePtrToInt(EmitScalarExpr(E->getArg(2)), IntType);
>> +
>> +auto Result = Builder.CreateAtomicCmpXchg(Destination, Comparand,
>> Exchange,
>> + SequentiallyConsistent,
>> + SequentiallyConsistent);
>> +Result->setVolatile(true);
>> +
>> +return
>> RValue::get(Builder.CreateIntToPtr(Builder.CreateExtractValue(Result,
>> +
>> 0),
>> + RTy));
>> + }
>>case Builtin::BI_InterlockedCompareExchange: {
>> AtomicCmpXchgInst *CXI = Builder.CreateAtomicCmpXchg(
>> EmitScalarExpr(E->getArg(0)),
>>
>> Modified: cfe/trunk/lib/Headers/Intrin.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/Intrin.h?rev=211216&r1=211215&r2=211216&view=diff
>>
>> ===
Re: r212060 - Consider module depedencies when checking a preamble in libclang
Ben Langmuir wrote on 07.07.2014 18:12:21:
> > And indeed running clang directly against the temporary files created
by
> > the test case I get:
> > uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
> > -fmodules
-I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
> > /tmp/libclang-test-6a8ede/MFile.m:2:25: error: variable has incomplete
type
> > 'struct Foo'
> > int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
> >^
> > /tmp/libclang-test-6a8ede/MFile.m:2:21: note: forward declaration of
> > 'struct Foo'
> > int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
> >^
> > 1 error generated.
>
> Could you try this again with the additional flags -Wmodule-build -
> Wauto-import as a sanity check that the module is being found? It
> looks like the module isn’t being imported properly...
Hmm, interesting. I get:
uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
-fmodules -I /tmp/libclang-test-75f2f2 /tmp/libclang-test-75f2f2/MFile.m
-Wmodule-build -Wauto-import
/tmp/libclang-test-75f2f2/MFile.m:1:1: warning: treating #include as an
import of module 'A' [-Wauto-import]
#include "HeaderFile.h"
^~~
@import A;
/tmp/libclang-test-75f2f2/MFile.m:1:2: remark: building module 'A' as
'/var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T/A-25ZFQ1VWL2WP7.pcm'
[-Rmodule-build]
#include "HeaderFile.h"
^
/tmp/libclang-test-75f2f2/MFile.m:2:25: error: variable has incomplete type
'struct Foo'
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^
/tmp/libclang-test-75f2f2/MFile.m:2:21: note: forward declaration of
'struct Foo'
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^
1 warning and 1 error generated.
However, the really interesting fact is that afterwards,
there is no /var/tmp/org.llvm.clang/ModuleCache/1MXAFKYV64X0T
directory -- and there cannot be, because there is a
/var/tmp/org.llvm.clang/ModuleCache directory, owned
by another user on the system, and my user ID does not
have the privileges to create subdirectories there ...
After I've removed that directory, the test case now passes!
(But it will presumably fail for other users now ...)
How is this supposed to work on a multi-user machine?
Bye,
Ulrich
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [RFC] PR20146 - Cannot return void with qualifiers
Thanks for the comments. I have:
- Cleaned up the code
- Made the warning an error
- Moved the check into diagnoseIgnoredFunctionQualifiers()
- Added 3 test cases to test/Sema/function.c
On Thu, Jul 3, 2014 at 4:41 PM, Alp Toker wrote:
>
> On 03/07/2014 22:08, Zach Davis wrote:
>>
>> As reported in bug 20146, a function cannot have a return type of
>> 'void' with qualifiers.
>>
>> Clang does emit a warning that the qualifiers are ignored
>> [-Wignored-qualifiers] (off by default), but according to [1] this
>> code is non-conforming.
>>
>> The attached patch makes Clang issue a more specific warning like so:
>>
>> test3.c:8:18: warning: return type of void cannot be qualified
>> 'volatile void'
>> volatile void baz(void) { return; }
>>^
>>
>> [1]http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_113.html
>
>
> It seems fine to make this a hard error instead of a warning for C, and
> probably C++ too. Richard?
>
>>
>> 20146_return_qual_void.patch
>>
>>
>> Index: lib/Sema/SemaType.cpp
>> ===
>> --- lib/Sema/SemaType.cpp (revision 212275)
>> +++ lib/Sema/SemaType.cpp (working copy)
>> @@ -2741,6 +2741,15 @@
>> D.setInvalidType(true);
>> }
>> + // C99 6.9.1/3: The return type of a function shall be void or
>> + // an object type other than array type.
>> + // A return type of void cannot be qualified.
>> + if (T->isVoidType() && T.getCVRQualifiers()) {
>> + unsigned diagID = diag::warn_func_returning_qualified_void;
>
>
> Just pass the ID directly to Diag().
>
>> + S.Diag(DeclType.Loc, diagID) << T;
>> + D.setInvalidType(true);
>> + }
>> +
>
>
> How about placing this check with an early return at the top of
> diagnoseIgnoredFunctionQualifiers()?
>
>> // Do not allow returning half FP value.
>> // FIXME: This really should be in BuildFunctionType.
>> if (T->isHalfType()) {
>> Index: include/clang/Basic/DiagnosticSemaKinds.td
>> ===
>> --- include/clang/Basic/DiagnosticSemaKinds.td (revision 212275)
>> +++ include/clang/Basic/DiagnosticSemaKinds.td (working copy)
>> @@ -4160,6 +4160,8 @@
>> def err_func_returning_array_function : Error<
>> "function cannot return %select{array|function}0 type %1">;
>> +def warn_func_returning_qualified_void : Warning<
>> + "return type of void cannot be qualified %0">;
>
>
> (Warnings need to have a diagnostic group / -W flag, though it doesn't
> matter if you go ahead and make it an error.)
>
>> def err_field_declared_as_function : Error<"field %0 declared as a
>> function">;
>> def err_field_incomplete : Error<"field has incomplete type %0">;
>> def ext_variable_sized_type_in_struct : ExtWarn<
>
>
> Test case?
>
> Alp.
>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
> --
> http://www.nuanti.com
> the browser experts
>
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp (revision 212275)
+++ lib/Sema/SemaType.cpp (working copy)
@@ -2043,6 +2043,16 @@
static void diagnoseIgnoredFunctionQualifiers(Sema &S, QualType RetTy,
Declarator &D,
unsigned FunctionChunkIndex) {
+
+ // C99 6.9.1/3: The return type of a function shall be void or
+ // an object type other than array type.
+ // A return type of void cannot be qualified.
+ if (RetTy->isVoidType() && RetTy.getCVRQualifiers()) {
+S.Diag(D.getIdentifierLoc(),
+ diag::err_func_returning_qualified_void) << RetTy;
+return;
+ }
+
if (D.getTypeObject(FunctionChunkIndex).Fun.hasTrailingReturnType()) {
// FIXME: TypeSourceInfo doesn't preserve location information for
// qualifiers.
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td (revision 212275)
+++ include/clang/Basic/DiagnosticSemaKinds.td (working copy)
@@ -4160,6 +4160,8 @@
def err_func_returning_array_function : Error<
"function cannot return %select{array|function}0 type %1">;
+def err_func_returning_qualified_void : Error<
+ "return type of void cannot be qualified %0">;
def err_field_declared_as_function : Error<"field %0 declared as a function">;
def err_field_incomplete : Error<"field has incomplete type %0">;
def ext_variable_sized_type_in_struct : ExtWarn<
Index: test/Sema/function.c
===
--- test/Sema/function.c (revision 212275)
+++ test/Sema/function.c (working copy)
@@ -113,3 +113,7 @@
decays(array);
no_decay(array);
}
+
+const void pr20146_1(); // expected-error {{return
Re: r212060 - Consider module depedencies when checking a preamble in libclang
> On Jul 7, 2014, at 8:17 AM, Ulrich Weigand wrote:
>
>
> Ben Langmuir wrote:
>
> +TEST_F(LibclangReparseTest, ReparseWithModule) {
>
> This new test has been failing for me on powerpc64-linux:
>
> [ RUN ] LibclangReparseTest.ReparseWithModule
> /home/uweigand/llvm/llvm-head/tools/clang/unittests/libclang/LibclangTest.cpp:454:
> Failure
> Value of: clang_getNumDiagnostics(ClangTU)
> Actual: 1
> Expected: 0U
> Which is: 0
> [ FAILED ] LibclangReparseTest.ReparseWithModule (74 ms)
>
>
> When I look at the diagnostics, I get:
> "/tmp/libclang-test-6a8ede/MFile.m:2: error: variable has incomplete type
> 'struct Foo'"
>
>
> And indeed running clang directly against the temporary files created by
> the test case I get:
> uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
> -fmodules -I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
> /tmp/libclang-test-6a8ede/MFile.m:2:25: error: variable has incomplete type
> 'struct Foo'
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>^
> /tmp/libclang-test-6a8ede/MFile.m:2:21: note: forward declaration of
> 'struct Foo'
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
>^
> 1 error generated.
Could you try this again with the additional flags -Wmodule-build -Wauto-import
as a sanity check that the module is being found? It looks like the module
isn’t being imported properly...
>
> Note that when I omit the -fmodules flag, I get another error, which is
> presumably the one the test actually expects:
> uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
> -I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
> /tmp/libclang-test-6a8ede/MFile.m:2:47: error: no member named 'baz' in
> 'struct Foo'; did you mean 'bar'?
> int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
> ^~~
> bar
> /tmp/libclang-test-6a8ede/HeaderFile.h:3:18: note: 'bar' declared here
> struct Foo { int bar;
> ^
> 1 error generated.
Right, this is the expected error.
>
>
> I have no idea why this behavior would be in any way platform-specific ...
> any thoughts?
>
Nope, this looks really weird to me!
Ben
>
>
> Mit freundlichen Gruessen / Best Regards
>
> Ulrich Weigand
>
> --
> Dr. Ulrich Weigand | Phone: +49-7031/16-3727
> STSM, GNU/Linux compilers and toolchain
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
> Wittkopp
> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
> Stuttgart, HRB 243294
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[PATCH] [Patch] UBsan: Type-based blacklisting
Hi samsonov, rsmith, kcc,
This is a Clang side patch for type-based blacklisting in Ubsan. As this patch
is depending on llvm-side patch, please see http://reviews.llvm.org/D4406 for
more details.
Although the diff looks more complicated than it has to be, this patch only
adds a simple branch if (!CGM.getSanitizerBlacklist().isIn(Out.str())).
http://reviews.llvm.org/D4407
Files:
lib/CodeGen/CGExpr.cpp
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -539,44 +539,47 @@
llvm::raw_svector_ostream Out(MangledName);
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty.getUnqualifiedType(),
Out);
-llvm::hash_code TypeHash = hash_value(Out.str());
-// Load the vptr, and compute hash_16_bytes(TypeHash, vptr).
-llvm::Value *Low = llvm::ConstantInt::get(Int64Ty, TypeHash);
-llvm::Type *VPtrTy = llvm::PointerType::get(IntPtrTy, 0);
-llvm::Value *VPtrAddr = Builder.CreateBitCast(Address, VPtrTy);
-llvm::Value *VPtrVal = Builder.CreateLoad(VPtrAddr);
-llvm::Value *High = Builder.CreateZExt(VPtrVal, Int64Ty);
+// Blacklist based on the mangled types
+if (!CGM.getSanitizerBlacklist().isIn(Out.str())) {
+ llvm::hash_code TypeHash = hash_value(Out.str());
-llvm::Value *Hash = emitHash16Bytes(Builder, Low, High);
-Hash = Builder.CreateTrunc(Hash, IntPtrTy);
+ // Load the vptr, and compute hash_16_bytes(TypeHash, vptr).
+ llvm::Value *Low = llvm::ConstantInt::get(Int64Ty, TypeHash);
+ llvm::Type *VPtrTy = llvm::PointerType::get(IntPtrTy, 0);
+ llvm::Value *VPtrAddr = Builder.CreateBitCast(Address, VPtrTy);
+ llvm::Value *VPtrVal = Builder.CreateLoad(VPtrAddr);
+ llvm::Value *High = Builder.CreateZExt(VPtrVal, Int64Ty);
-// Look the hash up in our cache.
-const int CacheSize = 128;
-llvm::Type *HashTable = llvm::ArrayType::get(IntPtrTy, CacheSize);
-llvm::Value *Cache = CGM.CreateRuntimeVariable(HashTable,
- "__ubsan_vptr_type_cache");
-llvm::Value *Slot = Builder.CreateAnd(Hash,
- llvm::ConstantInt::get(IntPtrTy,
- CacheSize-1));
-llvm::Value *Indices[] = { Builder.getInt32(0), Slot };
-llvm::Value *CacheVal =
- Builder.CreateLoad(Builder.CreateInBoundsGEP(Cache, Indices));
+ llvm::Value *Hash = emitHash16Bytes(Builder, Low, High);
+ Hash = Builder.CreateTrunc(Hash, IntPtrTy);
-// If the hash isn't in the cache, call a runtime handler to perform the
-// hard work of checking whether the vptr is for an object of the right
-// type. This will either fill in the cache and return, or produce a
-// diagnostic.
-llvm::Constant *StaticData[] = {
- EmitCheckSourceLocation(Loc),
- EmitCheckTypeDescriptor(Ty),
- CGM.GetAddrOfRTTIDescriptor(Ty.getUnqualifiedType()),
- llvm::ConstantInt::get(Int8Ty, TCK)
-};
-llvm::Value *DynamicData[] = { Address, Hash };
-EmitCheck(Builder.CreateICmpEQ(CacheVal, Hash),
- "dynamic_type_cache_miss", StaticData, DynamicData,
- CRK_AlwaysRecoverable);
+ // Look the hash up in our cache.
+ const int CacheSize = 128;
+ llvm::Type *HashTable = llvm::ArrayType::get(IntPtrTy, CacheSize);
+ llvm::Value *Cache = CGM.CreateRuntimeVariable(HashTable,
+
"__ubsan_vptr_type_cache");
+ llvm::Value *Slot =
+Builder.CreateAnd(Hash,llvm::ConstantInt::get(IntPtrTy, CacheSize-1));
+ llvm::Value *Indices[] = { Builder.getInt32(0), Slot };
+ llvm::Value *CacheVal =
+Builder.CreateLoad(Builder.CreateInBoundsGEP(Cache, Indices));
+
+ // If the hash isn't in the cache, call a runtime handler to perform the
+ // hard work of checking whether the vptr is for an object of the right
+ // type. This will either fill in the cache and return, or produce a
+ // diagnostic.
+ llvm::Constant *StaticData[] = {
+EmitCheckSourceLocation(Loc),
+EmitCheckTypeDescriptor(Ty),
+CGM.GetAddrOfRTTIDescriptor(Ty.getUnqualifiedType()),
+llvm::ConstantInt::get(Int8Ty, TCK)
+ };
+ llvm::Value *DynamicData[] = { Address, Hash };
+ EmitCheck(Builder.CreateICmpEQ(CacheVal, Hash),
+"dynamic_type_cache_miss", StaticData, DynamicData,
+CRK_AlwaysRecoverable);
+}
}
if (Done) {
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -539,44 +539,47 @@
llvm::raw_svector_ostream Out(MangledName);
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty.getUnqualifiedType(),
r212464 - Handle __builtin_clzs and __builtin_ctzs in the constant expression evaluator.
Author: andersca
Date: Mon Jul 7 10:53:44 2014
New Revision: 212464
URL: http://llvm.org/viewvc/llvm-project?rev=212464&view=rev
Log:
Handle __builtin_clzs and __builtin_ctzs in the constant expression evaluator.
Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/Sema/constant-builtins-2.c
Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=212464&r1=212463&r2=212464&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Jul 7 10:53:44 2014
@@ -6053,7 +6053,8 @@ bool IntExprEvaluator::VisitCallExpr(con
case Builtin::BI__builtin_clz:
case Builtin::BI__builtin_clzl:
- case Builtin::BI__builtin_clzll: {
+ case Builtin::BI__builtin_clzll:
+ case Builtin::BI__builtin_clzs: {
APSInt Val;
if (!EvaluateInteger(E->getArg(0), Val, Info))
return false;
@@ -6068,7 +6069,8 @@ bool IntExprEvaluator::VisitCallExpr(con
case Builtin::BI__builtin_ctz:
case Builtin::BI__builtin_ctzl:
- case Builtin::BI__builtin_ctzll: {
+ case Builtin::BI__builtin_ctzll:
+ case Builtin::BI__builtin_ctzs: {
APSInt Val;
if (!EvaluateInteger(E->getArg(0), Val, Info))
return false;
Modified: cfe/trunk/test/Sema/constant-builtins-2.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/constant-builtins-2.c?rev=212464&r1=212463&r2=212464&view=diff
==
--- cfe/trunk/test/Sema/constant-builtins-2.c (original)
+++ cfe/trunk/test/Sema/constant-builtins-2.c Mon Jul 7 10:53:44 2014
@@ -112,49 +112,53 @@ char isnormal_snan [!__builtin_isnorma
//long double g21 = __builtin_powil(2.0L, 4);
#define BITSIZE(x) (sizeof(x) * 8)
-char g22[__builtin_clz(1) == BITSIZE(int) - 1 ? 1 : -1];
-char g23[__builtin_clz(7) == BITSIZE(int) - 3 ? 1 : -1];
-char g24[__builtin_clz(1 << (BITSIZE(int) - 1)) == 0 ? 1 : -1];
-int g25 = __builtin_clz(0); // expected-error {{not a compile-time constant}}
-char g26[__builtin_clzl(0xFL) == BITSIZE(long) - 4 ? 1 : -1];
-char g27[__builtin_clzll(0xFFLL) == BITSIZE(long long) - 8 ? 1 : -1];
-
-char g28[__builtin_ctz(1) == 0 ? 1 : -1];
-char g29[__builtin_ctz(8) == 3 ? 1 : -1];
-char g30[__builtin_ctz(1 << (BITSIZE(int) - 1)) == BITSIZE(int) - 1 ? 1 : -1];
-int g31 = __builtin_ctz(0); // expected-error {{not a compile-time constant}}
-char g32[__builtin_ctzl(0x10L) == 4 ? 1 : -1];
-char g33[__builtin_ctzll(0x100LL) == 8 ? 1 : -1];
-
-char g34[__builtin_popcount(0) == 0 ? 1 : -1];
-char g35[__builtin_popcount(0xF0F0) == 8 ? 1 : -1];
-char g36[__builtin_popcount(~0) == BITSIZE(int) ? 1 : -1];
-char g37[__builtin_popcount(~0L) == BITSIZE(int) ? 1 : -1];
-char g38[__builtin_popcountl(0L) == 0 ? 1 : -1];
-char g39[__builtin_popcountl(0xF0F0L) == 8 ? 1 : -1];
-char g40[__builtin_popcountl(~0L) == BITSIZE(long) ? 1 : -1];
-char g41[__builtin_popcountll(0LL) == 0 ? 1 : -1];
-char g42[__builtin_popcountll(0xF0F0LL) == 8 ? 1 : -1];
-char g43[__builtin_popcountll(~0LL) == BITSIZE(long long) ? 1 : -1];
-
-char g44[__builtin_parity(0) == 0 ? 1 : -1];
-char g45[__builtin_parity(0xb821) == 0 ? 1 : -1];
-char g46[__builtin_parity(0xb822) == 0 ? 1 : -1];
-char g47[__builtin_parity(0xb823) == 1 ? 1 : -1];
-char g48[__builtin_parity(0xb824) == 0 ? 1 : -1];
-char g49[__builtin_parity(0xb825) == 1 ? 1 : -1];
-char g50[__builtin_parity(0xb826) == 1 ? 1 : -1];
-char g51[__builtin_parity(~0) == 0 ? 1 : -1];
-char g52[__builtin_parityl(1L << (BITSIZE(long) - 1)) == 1 ? 1 : -1];
-char g53[__builtin_parityll(1LL << (BITSIZE(long long) - 1)) == 1 ? 1 : -1];
-
-char g54[__builtin_ffs(0) == 0 ? 1 : -1];
-char g55[__builtin_ffs(1) == 1 ? 1 : -1];
-char g56[__builtin_ffs(0xfbe71) == 1 ? 1 : -1];
-char g57[__builtin_ffs(0xfbe70) == 5 ? 1 : -1];
-char g58[__builtin_ffs(1U << (BITSIZE(int) - 1)) == BITSIZE(int) ? 1 : -1];
-char g59[__builtin_ffsl(0x10L) == 5 ? 1 : -1];
-char g60[__builtin_ffsll(0x100LL) == 9 ? 1 : -1];
+char clz1[__builtin_clz(1) == BITSIZE(int) - 1 ? 1 : -1];
+char clz2[__builtin_clz(7) == BITSIZE(int) - 3 ? 1 : -1];
+char clz3[__builtin_clz(1 << (BITSIZE(int) - 1)) == 0 ? 1 : -1];
+int clz4 = __builtin_clz(0); // expected-error {{not a compile-time constant}}
+char clz5[__builtin_clzl(0xFL) == BITSIZE(long) - 4 ? 1 : -1];
+char clz6[__builtin_clzll(0xFFLL) == BITSIZE(long long) - 8 ? 1 : -1];
+char clz7[__builtin_clzs(0x1) == BITSIZE(short) - 1 ? 1 : -1];
+char clz8[__builtin_clzs(0xf) == BITSIZE(short) - 4 ? 1 : -1];
+char clz9[__builtin_clzs(0xfff) == BITSIZE(short) - 12 ? 1 : -1];
+
+char ctz1[__builtin_ctz(1) == 0 ? 1 : -1];
+char ctz2[__builtin_ctz(8) == 3 ? 1 : -1];
+char ctz3[__builtin_ctz(1 << (BITSIZE(int) - 1)) == BITSIZE(int) - 1 ? 1 : -1];
+int ctz4 = __builtin_ctz(0); // expected-error {{not a compile-time constant}}
+char ctz5[__builtin_ctzl(0x10L) == 4 ? 1 : -1];
+char ctz
r212462 - Fix comment typo.
Author: majnemer Date: Mon Jul 7 10:29:10 2014 New Revision: 212462 URL: http://llvm.org/viewvc/llvm-project?rev=212462&view=rev Log: Fix comment typo. No functionality changed. Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=212462&r1=212461&r2=212462&view=diff == --- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original) +++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Mon Jul 7 10:29:10 2014 @@ -2728,10 +2728,11 @@ MSRTTIBuilder::getBaseClassArray(SmallVe // mode) bytes of padding. We provide a pointer sized amount of padding by // adding +1 to Classes.size(). The sections have pointer alignment and are // marked pick-any so it shouldn't matter. - auto PtrType = ABI.getImageRelativeType( + llvm::Type *PtrType = ABI.getImageRelativeType( ABI.getBaseClassDescriptorType()->getPointerTo()); - auto ArrayType = llvm::ArrayType::get(PtrType, Classes.size() + 1); - auto BCA = new llvm::GlobalVariable(Module, ArrayType, + auto *ArrType = llvm::ArrayType::get(PtrType, Classes.size() + 1); + auto *BCA = new llvm::GlobalVariable( + Module, ArrType, /*Constant=*/true, Linkage, /*Initializer=*/nullptr, MangledName.c_str()); // Initialize the BaseClassArray. @@ -2740,7 +2741,7 @@ MSRTTIBuilder::getBaseClassArray(SmallVe BaseClassArrayData.push_back( ABI.getImageRelativeConstant(getBaseClassDescriptor(Class))); BaseClassArrayData.push_back(llvm::Constant::getNullValue(PtrType)); - BCA->setInitializer(llvm::ConstantArray::get(ArrayType, BaseClassArrayData)); + BCA->setInitializer(llvm::ConstantArray::get(ArrType, BaseClassArrayData)); return BCA; } @@ -2764,7 +2765,7 @@ MSRTTIBuilder::getBaseClassDescriptor(co Class.Flags, Out); } - // Check to see if we've already declared declared this object. + // Check to see if we've already declared this object. if (auto BCD = Module.getNamedGlobal(MangledName)) return BCD; ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212463 - MS ABI: Don't unnecessarily use CGM abstraction
Author: majnemer
Date: Mon Jul 7 10:29:16 2014
New Revision: 212463
URL: http://llvm.org/viewvc/llvm-project?rev=212463&view=rev
Log:
MS ABI: Don't unnecessarily use CGM abstraction
If we are in MicrosoftCXXABI, we don't need to use CGM to get a
TypeDescriptor.
Modified:
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=212463&r1=212462&r2=212463&view=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Mon Jul 7 10:29:16 2014
@@ -2778,7 +2778,7 @@ MSRTTIBuilder::getBaseClassDescriptor(co
// Initialize the BaseClassDescriptor.
llvm::Constant *Fields[] = {
ABI.getImageRelativeConstant(
- CGM.GetAddrOfRTTIDescriptor(Context.getTypeDeclType(Class.RD))),
+ ABI.getAddrOfRTTIDescriptor(Context.getTypeDeclType(Class.RD))),
llvm::ConstantInt::get(CGM.IntTy, Class.NumBases),
llvm::ConstantInt::get(CGM.IntTy, Class.OffsetInVBase),
llvm::ConstantInt::get(CGM.IntTy, VBPtrOffset),
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212060 - Consider module depedencies when checking a preamble in libclang
Ben Langmuir wrote:
+TEST_F(LibclangReparseTest, ReparseWithModule) {
This new test has been failing for me on powerpc64-linux:
[ RUN ] LibclangReparseTest.ReparseWithModule
/home/uweigand/llvm/llvm-head/tools/clang/unittests/libclang/LibclangTest.cpp:454:
Failure
Value of: clang_getNumDiagnostics(ClangTU)
Actual: 1
Expected: 0U
Which is: 0
[ FAILED ] LibclangReparseTest.ReparseWithModule (74 ms)
When I look at the diagnostics, I get:
"/tmp/libclang-test-6a8ede/MFile.m:2: error: variable has incomplete type
'struct Foo'"
And indeed running clang directly against the temporary files created by
the test case I get:
uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
-fmodules -I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
/tmp/libclang-test-6a8ede/MFile.m:2:25: error: variable has incomplete type
'struct Foo'
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^
/tmp/libclang-test-6a8ede/MFile.m:2:21: note: forward declaration of
'struct Foo'
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^
1 error generated.
Note that when I omit the -fmodules flag, I get another error, which is
presumably the one the test actually expects:
uweigand@bns:~> ./llvm/build/llvm-head-debug/Debug+Asserts/bin/clang
-I /tmp/libclang-test-6a8ede /tmp/libclang-test-6a8ede/MFile.m
/tmp/libclang-test-6a8ede/MFile.m:2:47: error: no member named 'baz' in
'struct Foo'; did you mean 'bar'?
int main() { struct Foo foo; foo.bar = 7; foo.baz = 8; }
^~~
bar
/tmp/libclang-test-6a8ede/HeaderFile.h:3:18: note: 'bar' declared here
struct Foo { int bar;
^
1 error generated.
I have no idea why this behavior would be in any way platform-specific ...
any thoughts?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU/Linux compilers and toolchain
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Fix for libc++ bug #20096 http://llvm.org/bugs/show_bug.cgi?id=20096
Eric - I believe that invoking the destructor in this case is not well formed, because the destructor has been explicitly deleted. See section 8.4.2/2: A program that refers to a deleted function implicitly or explicitly, other than to declare it, is ill-formed. [ Note: This includes calling the function implicitly or explicitly and forming a pointer or pointer-to-member to the function. It applies even for references in expressions that are not potentially-evaluated. If a function is overloaded, it is referenced only if the function is selected by overload resolution. — end note ] http://reviews.llvm.org/D4306 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212458 - PTHInternals.rst: PCH is now a thing, update docs to reflect it
Author: alp Date: Mon Jul 7 09:02:39 2014 New Revision: 212458 URL: http://llvm.org/viewvc/llvm-project?rev=212458&view=rev Log: PTHInternals.rst: PCH is now a thing, update docs to reflect it Modified: cfe/trunk/docs/PTHInternals.rst Modified: cfe/trunk/docs/PTHInternals.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/PTHInternals.rst?rev=212458&r1=212457&r2=212458&view=diff == --- cfe/trunk/docs/PTHInternals.rst (original) +++ cfe/trunk/docs/PTHInternals.rst Mon Jul 7 09:02:39 2014 @@ -135,11 +135,11 @@ copy-on-write pages, the approach itself an algorithmic level, especially when one considers header files of arbitrary size. -There are plans to potentially implement an complementary PCH -implementation for Clang based on the lazy deserialization of ASTs. This -approach would theoretically have the same constant-time algorithmic -advantages just mentioned but would also retain some of the strengths of -PTH such as reduced memory pressure (ideal for multi-core builds). +There is also a PCH implementation for Clang based on the lazy +deserialization of ASTs. This approach theoretically has the same +constant-time algorithmic advantages just mentioned but also retains some +of the strengths of PTH such as reduced memory pressure (ideal for +multi-core builds). Internal PTH Optimizations -- ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212457 - PTH: use a variable instead of a macro
Author: alp
Date: Mon Jul 7 09:01:37 2014
New Revision: 212457
URL: http://llvm.org/viewvc/llvm-project?rev=212457&view=rev
Log:
PTH: use a variable instead of a macro
Cleanup only.
Modified:
cfe/trunk/lib/Lex/PTHLexer.cpp
Modified: cfe/trunk/lib/Lex/PTHLexer.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PTHLexer.cpp?rev=212457&r1=212456&r2=212457&view=diff
==
--- cfe/trunk/lib/Lex/PTHLexer.cpp (original)
+++ cfe/trunk/lib/Lex/PTHLexer.cpp Mon Jul 7 09:01:37 2014
@@ -29,7 +29,7 @@
#include
using namespace clang;
-#define DISK_TOKEN_SIZE (1+1+2+4+4)
+static const unsigned StoredTokenSize = 1 + 1 + 2 + 4 + 4;
//===--===//
// PTHLexer methods.
@@ -110,7 +110,7 @@ bool PTHLexer::Lex(Token& Tok) {
}
if (TKind == tok::hash && Tok.isAtStartOfLine()) {
-LastHashTokPtr = CurPtr - DISK_TOKEN_SIZE;
+LastHashTokPtr = CurPtr - StoredTokenSize;
assert(!LexingRawMode);
PP->HandleDirective(Tok);
@@ -179,7 +179,7 @@ void PTHLexer::DiscardToEndOfLine() {
if (y & Token::StartOfLine) break;
// Skip to the next token.
-p += DISK_TOKEN_SIZE;
+p += StoredTokenSize;
}
CurPtr = p;
@@ -255,10 +255,10 @@ bool PTHLexer::SkipBlock() {
// already points 'elif'. Just return.
if (CurPtr > HashEntryI) {
-assert(CurPtr == HashEntryI + DISK_TOKEN_SIZE);
+assert(CurPtr == HashEntryI + StoredTokenSize);
// Did we reach a #endif? If so, go ahead and consume that token as well.
if (isEndif)
- CurPtr += DISK_TOKEN_SIZE*2;
+ CurPtr += StoredTokenSize * 2;
else
LastHashTokPtr = HashEntryI;
@@ -274,10 +274,12 @@ bool PTHLexer::SkipBlock() {
// Skip the '#' token.
assert(((tok::TokenKind)*CurPtr) == tok::hash);
- CurPtr += DISK_TOKEN_SIZE;
+ CurPtr += StoredTokenSize;
// Did we reach a #endif? If so, go ahead and consume that token as well.
- if (isEndif) { CurPtr += DISK_TOKEN_SIZE*2; }
+ if (isEndif) {
+CurPtr += StoredTokenSize * 2;
+ }
return isEndif;
}
@@ -290,7 +292,7 @@ SourceLocation PTHLexer::getSourceLocati
// NOTE: This is a virtual function; hence it is defined out-of-line.
using namespace llvm::support;
- const unsigned char *OffsetPtr = CurPtr + (DISK_TOKEN_SIZE - 4);
+ const unsigned char *OffsetPtr = CurPtr + (StoredTokenSize - 4);
uint32_t Offset = endian::readNext(OffsetPtr);
return FileStartLoc.getLocWithOffset(Offset);
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212452 - Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
On Mon, Jul 7, 2014 at 3:09 PM, Aaron Ballman wrote: > On Mon, Jul 7, 2014 at 9:07 AM, Manuel Klimek wrote: > > On Mon, Jul 7, 2014 at 3:06 PM, Aaron Ballman > > wrote: > >> > >> On Mon, Jul 7, 2014 at 8:55 AM, Manuel Klimek > wrote: > >> > Author: klimek > >> > Date: Mon Jul 7 07:55:16 2014 > >> > New Revision: 212452 > >> > > >> > URL: http://llvm.org/viewvc/llvm-project?rev=212452&view=rev > >> > Log: > >> > Increase argument limit of anyOf, allOf and eachOf from 5 to 9. > >> > >> Can we simply use truly variadic templates now that we're using C++11 > >> features? > > > > > > See > > > http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features > > > > Variadic templates are not supported by VS 2012. > > Ah crud, I knew that in the recesses of my brain. :-P Sorry about that. > I also wished so hard for it to be true that I believed it was true before cross-checking ... Sigh... Oh well, we'll just have to wait another 1-2 years. > > ~Aaron > ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212452 - Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
On Mon, Jul 7, 2014 at 9:07 AM, Manuel Klimek wrote: > On Mon, Jul 7, 2014 at 3:06 PM, Aaron Ballman > wrote: >> >> On Mon, Jul 7, 2014 at 8:55 AM, Manuel Klimek wrote: >> > Author: klimek >> > Date: Mon Jul 7 07:55:16 2014 >> > New Revision: 212452 >> > >> > URL: http://llvm.org/viewvc/llvm-project?rev=212452&view=rev >> > Log: >> > Increase argument limit of anyOf, allOf and eachOf from 5 to 9. >> >> Can we simply use truly variadic templates now that we're using C++11 >> features? > > > See > http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features > > Variadic templates are not supported by VS 2012. Ah crud, I knew that in the recesses of my brain. :-P Sorry about that. ~Aaron ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212452 - Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
On Mon, Jul 7, 2014 at 3:06 PM, Aaron Ballman
wrote:
> On Mon, Jul 7, 2014 at 8:55 AM, Manuel Klimek wrote:
> > Author: klimek
> > Date: Mon Jul 7 07:55:16 2014
> > New Revision: 212452
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=212452&view=rev
> > Log:
> > Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
>
> Can we simply use truly variadic templates now that we're using C++11
> features?
>
See
http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features
Variadic templates are not supported by VS 2012.
>
> ~Aaron
>
> >
> > Patch by Alexey Sokolov.
> >
> > Modified:
> > cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> >
> > Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=212452&r1=212451&r2=212452&view=diff
> >
> ==
> > --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> > +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jul 7
> 07:55:16 2014
> > @@ -1126,16 +1126,25 @@ struct VariadicOperatorNoArg {};
> > template >typename P3 = VariadicOperatorNoArg,
> >typename P4 = VariadicOperatorNoArg,
> > - typename P5 = VariadicOperatorNoArg>
> > + typename P5 = VariadicOperatorNoArg,
> > + typename P6 = VariadicOperatorNoArg,
> > + typename P7 = VariadicOperatorNoArg,
> > + typename P8 = VariadicOperatorNoArg,
> > + typename P9 = VariadicOperatorNoArg>
> > class VariadicOperatorMatcher {
> > public:
> >VariadicOperatorMatcher(VariadicOperatorFunction Func, const P1
> &Param1,
> >const P2 &Param2 = VariadicOperatorNoArg(),
> >const P3 &Param3 = VariadicOperatorNoArg(),
> >const P4 &Param4 = VariadicOperatorNoArg(),
> > - const P5 &Param5 = VariadicOperatorNoArg())
> > + const P5 &Param5 = VariadicOperatorNoArg(),
> > + const P6 &Param6 = VariadicOperatorNoArg(),
> > + const P7 &Param7 = VariadicOperatorNoArg(),
> > + const P8 &Param8 = VariadicOperatorNoArg(),
> > + const P9 &Param9 = VariadicOperatorNoArg())
> >: Func(Func), Param1(Param1), Param2(Param2), Param3(Param3),
> > -Param4(Param4), Param5(Param5) {}
> > +Param4(Param4), Param5(Param5), Param6(Param6), Param7(Param7),
> > +Param8(Param8), Param9(Param9) {}
> >
> >template operator Matcher() const {
> > std::vector Matchers;
> > @@ -1144,6 +1153,10 @@ public:
> > addMatcher(Param3, Matchers);
> > addMatcher(Param4, Matchers);
> > addMatcher(Param5, Matchers);
> > +addMatcher(Param6, Matchers);
> > +addMatcher(Param7, Matchers);
> > +addMatcher(Param8, Matchers);
> > +addMatcher(Param9, Matchers);
> > return Matcher(
> > new VariadicOperatorMatcherInterface(Func,
> std::move(Matchers)));
> >}
> > @@ -1166,12 +1179,16 @@ private:
> >const P3 Param3;
> >const P4 Param4;
> >const P5 Param5;
> > + const P6 Param6;
> > + const P7 Param7;
> > + const P8 Param8;
> > + const P9 Param9;
> > };
> >
> > /// \brief Overloaded function object to generate
> VariadicOperatorMatcher
> > /// objects from arbitrary matchers.
> > ///
> > -/// It supports 1-5 argument overloaded operator(). More can be added
> if needed.
> > +/// It supports 1-9 argument overloaded operator(). More can be added
> if needed.
> > template
> > struct VariadicOperatorMatcherFunc {
> >VariadicOperatorFunction Func;
> > @@ -1208,6 +1225,43 @@ struct VariadicOperatorMatcherFunc {
> > return VariadicOperatorMatcher(Func, P1, P2,
> P3, P4,
> > P5);
> >}
> > + template typename M5,
> > +typename M6>
> > + typename EnableIfValidArity<
> > + 6, VariadicOperatorMatcher >::type
> > + operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
> > + const M5 &P5, const M6 &P6) const {
> > +return VariadicOperatorMatcher(
> > +Func, P1, P2, P3, P4, P5, P6);
> > + }
> > + template typename M5,
> > +typename M6, typename M7>
> > + typename EnableIfValidArity<
> > + 7, VariadicOperatorMatcher >::type
> > + operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
> > + const M5 &P5, const M6 &P6, const M7 &P7) const {
> > +return VariadicOperatorMatcher(
> > +Func, P1, P2, P3, P4, P5, P6, P7);
> > + }
> > + template typename M5,
> > +typename M6, typename M7, typename M8>
> > + typename EnableIfValidArity<
> > + 8, VariadicOperatorMatcher >::type
> > + operator()(const M1 &P1
Re: r212452 - Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
On Mon, Jul 7, 2014 at 8:55 AM, Manuel Klimek wrote:
> Author: klimek
> Date: Mon Jul 7 07:55:16 2014
> New Revision: 212452
>
> URL: http://llvm.org/viewvc/llvm-project?rev=212452&view=rev
> Log:
> Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
Can we simply use truly variadic templates now that we're using C++11 features?
~Aaron
>
> Patch by Alexey Sokolov.
>
> Modified:
> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=212452&r1=212451&r2=212452&view=diff
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jul 7
> 07:55:16 2014
> @@ -1126,16 +1126,25 @@ struct VariadicOperatorNoArg {};
> template typename P3 = VariadicOperatorNoArg,
>typename P4 = VariadicOperatorNoArg,
> - typename P5 = VariadicOperatorNoArg>
> + typename P5 = VariadicOperatorNoArg,
> + typename P6 = VariadicOperatorNoArg,
> + typename P7 = VariadicOperatorNoArg,
> + typename P8 = VariadicOperatorNoArg,
> + typename P9 = VariadicOperatorNoArg>
> class VariadicOperatorMatcher {
> public:
>VariadicOperatorMatcher(VariadicOperatorFunction Func, const P1 &Param1,
>const P2 &Param2 = VariadicOperatorNoArg(),
>const P3 &Param3 = VariadicOperatorNoArg(),
>const P4 &Param4 = VariadicOperatorNoArg(),
> - const P5 &Param5 = VariadicOperatorNoArg())
> + const P5 &Param5 = VariadicOperatorNoArg(),
> + const P6 &Param6 = VariadicOperatorNoArg(),
> + const P7 &Param7 = VariadicOperatorNoArg(),
> + const P8 &Param8 = VariadicOperatorNoArg(),
> + const P9 &Param9 = VariadicOperatorNoArg())
>: Func(Func), Param1(Param1), Param2(Param2), Param3(Param3),
> -Param4(Param4), Param5(Param5) {}
> +Param4(Param4), Param5(Param5), Param6(Param6), Param7(Param7),
> +Param8(Param8), Param9(Param9) {}
>
>template operator Matcher() const {
> std::vector Matchers;
> @@ -1144,6 +1153,10 @@ public:
> addMatcher(Param3, Matchers);
> addMatcher(Param4, Matchers);
> addMatcher(Param5, Matchers);
> +addMatcher(Param6, Matchers);
> +addMatcher(Param7, Matchers);
> +addMatcher(Param8, Matchers);
> +addMatcher(Param9, Matchers);
> return Matcher(
> new VariadicOperatorMatcherInterface(Func, std::move(Matchers)));
>}
> @@ -1166,12 +1179,16 @@ private:
>const P3 Param3;
>const P4 Param4;
>const P5 Param5;
> + const P6 Param6;
> + const P7 Param7;
> + const P8 Param8;
> + const P9 Param9;
> };
>
> /// \brief Overloaded function object to generate VariadicOperatorMatcher
> /// objects from arbitrary matchers.
> ///
> -/// It supports 1-5 argument overloaded operator(). More can be added if
> needed.
> +/// It supports 1-9 argument overloaded operator(). More can be added if
> needed.
> template
> struct VariadicOperatorMatcherFunc {
>VariadicOperatorFunction Func;
> @@ -1208,6 +1225,43 @@ struct VariadicOperatorMatcherFunc {
> return VariadicOperatorMatcher(Func, P1, P2, P3, P4,
> P5);
>}
> + template +typename M6>
> + typename EnableIfValidArity<
> + 6, VariadicOperatorMatcher >::type
> + operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
> + const M5 &P5, const M6 &P6) const {
> +return VariadicOperatorMatcher(
> +Func, P1, P2, P3, P4, P5, P6);
> + }
> + template +typename M6, typename M7>
> + typename EnableIfValidArity<
> + 7, VariadicOperatorMatcher >::type
> + operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
> + const M5 &P5, const M6 &P6, const M7 &P7) const {
> +return VariadicOperatorMatcher(
> +Func, P1, P2, P3, P4, P5, P6, P7);
> + }
> + template +typename M6, typename M7, typename M8>
> + typename EnableIfValidArity<
> + 8, VariadicOperatorMatcher >::type
> + operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
> + const M5 &P5, const M6 &P6, const M7 &P7, const M8 &P8) const {
> +return VariadicOperatorMatcher(
> +Func, P1, P2, P3, P4, P5, P6, P7, P8);
> + }
> + template +typename M6, typename M7, typename M8, typename M9>
> + typename EnableIfValidArity<
> + 9, VariadicOperatorMatcher >::type
> + operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
> + con
Re: [PATCH] Increase argument limit for anyOf, allOf, eachOf from 5 to 9
Committed as r212452. On Fri, Jul 4, 2014 at 3:42 PM, Manuel Klimek wrote: > LG. > > http://reviews.llvm.org/D4390 > > > ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212452 - Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
Author: klimek
Date: Mon Jul 7 07:55:16 2014
New Revision: 212452
URL: http://llvm.org/viewvc/llvm-project?rev=212452&view=rev
Log:
Increase argument limit of anyOf, allOf and eachOf from 5 to 9.
Patch by Alexey Sokolov.
Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=212452&r1=212451&r2=212452&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Jul 7
07:55:16 2014
@@ -1126,16 +1126,25 @@ struct VariadicOperatorNoArg {};
template
+ typename P5 = VariadicOperatorNoArg,
+ typename P6 = VariadicOperatorNoArg,
+ typename P7 = VariadicOperatorNoArg,
+ typename P8 = VariadicOperatorNoArg,
+ typename P9 = VariadicOperatorNoArg>
class VariadicOperatorMatcher {
public:
VariadicOperatorMatcher(VariadicOperatorFunction Func, const P1 &Param1,
const P2 &Param2 = VariadicOperatorNoArg(),
const P3 &Param3 = VariadicOperatorNoArg(),
const P4 &Param4 = VariadicOperatorNoArg(),
- const P5 &Param5 = VariadicOperatorNoArg())
+ const P5 &Param5 = VariadicOperatorNoArg(),
+ const P6 &Param6 = VariadicOperatorNoArg(),
+ const P7 &Param7 = VariadicOperatorNoArg(),
+ const P8 &Param8 = VariadicOperatorNoArg(),
+ const P9 &Param9 = VariadicOperatorNoArg())
: Func(Func), Param1(Param1), Param2(Param2), Param3(Param3),
-Param4(Param4), Param5(Param5) {}
+Param4(Param4), Param5(Param5), Param6(Param6), Param7(Param7),
+Param8(Param8), Param9(Param9) {}
template operator Matcher() const {
std::vector Matchers;
@@ -1144,6 +1153,10 @@ public:
addMatcher(Param3, Matchers);
addMatcher(Param4, Matchers);
addMatcher(Param5, Matchers);
+addMatcher(Param6, Matchers);
+addMatcher(Param7, Matchers);
+addMatcher(Param8, Matchers);
+addMatcher(Param9, Matchers);
return Matcher(
new VariadicOperatorMatcherInterface(Func, std::move(Matchers)));
}
@@ -1166,12 +1179,16 @@ private:
const P3 Param3;
const P4 Param4;
const P5 Param5;
+ const P6 Param6;
+ const P7 Param7;
+ const P8 Param8;
+ const P9 Param9;
};
/// \brief Overloaded function object to generate VariadicOperatorMatcher
/// objects from arbitrary matchers.
///
-/// It supports 1-5 argument overloaded operator(). More can be added if
needed.
+/// It supports 1-9 argument overloaded operator(). More can be added if
needed.
template
struct VariadicOperatorMatcherFunc {
VariadicOperatorFunction Func;
@@ -1208,6 +1225,43 @@ struct VariadicOperatorMatcherFunc {
return VariadicOperatorMatcher(Func, P1, P2, P3, P4,
P5);
}
+ template
+ typename EnableIfValidArity<
+ 6, VariadicOperatorMatcher >::type
+ operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
+ const M5 &P5, const M6 &P6) const {
+return VariadicOperatorMatcher(
+Func, P1, P2, P3, P4, P5, P6);
+ }
+ template
+ typename EnableIfValidArity<
+ 7, VariadicOperatorMatcher >::type
+ operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
+ const M5 &P5, const M6 &P6, const M7 &P7) const {
+return VariadicOperatorMatcher(
+Func, P1, P2, P3, P4, P5, P6, P7);
+ }
+ template
+ typename EnableIfValidArity<
+ 8, VariadicOperatorMatcher >::type
+ operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
+ const M5 &P5, const M6 &P6, const M7 &P7, const M8 &P8) const {
+return VariadicOperatorMatcher(
+Func, P1, P2, P3, P4, P5, P6, P7, P8);
+ }
+ template
+ typename EnableIfValidArity<
+ 9, VariadicOperatorMatcher >::type
+ operator()(const M1 &P1, const M2 &P2, const M3 &P3, const M4 &P4,
+ const M5 &P5, const M6 &P6, const M7 &P7, const M8 &P8,
+ const M9 &P9) const {
+return VariadicOperatorMatcher(
+Func, P1, P2, P3, P4, P5, P6, P7, P8, P9);
+ }
};
/// @}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Canonicalize the variadic template alias with multiple ellipsis.
Ping?
This patch tries to fix an assertion failure related to the template alias
with two (or more) parameter packs. For example,
template struct tuple;
template struct extract_;
template using extract = typename extract_::type;
template
inline auto test(tuple&& xs, B&&... ys) -> extract { }
Please have a look, and feel free to let me know if there is any problem.
Thanks!
Sincerely,
Logan
On Mon, Jun 30, 2014 at 1:10 AM, Logan Chien
wrote:
> Hi rsmith,
>
> If the template has two variadic formal parameters, then the type
> might not be canonical. We have call ASTContext.getCanonicalType()
> to canonicalize the type; otherwise, an assertion failure will be
> raised.
>
> This patch fix this issue by adding getCanonicalType() in
> TransformTemplateTypeParmType.
>
> http://reviews.llvm.org/D4343
>
> Files:
> lib/Sema/SemaTemplateInstantiate.cpp
> test/SemaTemplate/alias-templates.cpp
>
> Index: lib/Sema/SemaTemplateInstantiate.cpp
> ===
> --- lib/Sema/SemaTemplateInstantiate.cpp
> +++ lib/Sema/SemaTemplateInstantiate.cpp
> @@ -1376,7 +1376,7 @@
> assert(Arg.getKind() == TemplateArgument::Type &&
> "Template argument kind mismatch");
>
> -QualType Replacement = Arg.getAsType();
> +QualType Replacement =
> getSema().Context.getCanonicalType(Arg.getAsType());
>
> // TODO: only do this uniquing once, at the start of instantiation.
> QualType Result
> Index: test/SemaTemplate/alias-templates.cpp
> ===
> --- test/SemaTemplate/alias-templates.cpp
> +++ test/SemaTemplate/alias-templates.cpp
> @@ -201,3 +201,17 @@
>template
>using derived2 = ::PR16904::base::template derived; //
> expected-error {{expected a type}} expected-error {{expected ';'}}
> }
> +
> +namespace VariadicTemplateAlias {
> + template struct tuple;
> + template struct extract_;
> +
> + // Note: Both the template alias and the concatenation of variadic
> template
> + // arguments A and B are required to trigger the assertion failure.
> +
> + template
> + using extract = typename extract_::type;
> +
> + template
> + inline auto test(tuple&& xs, B&&... ys) -> extract
> { }
> +}
>
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r212408 - Update for llvm api change.
> And it's no longer possible to do if (std::error_code EC = ...) which makes > error-checking an explicit step that's easy to forget. Quite the opposite. The main advantage of ErrorOr is that it makes error checking mandatory. Whet EC is the return type, it is possible to not check it and access the "actual return" type. With ErrorOr there is an assert that prevents one from getting the value if there is an error_code instead. That is true for any value returning function, but without c++11 ErrorOr was too cumbersome to use, which is not longer the case. Cheers, Rafael ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212451 - Move ChainedIncludesSource into the implementation
Author: alp
Date: Mon Jul 7 06:07:10 2014
New Revision: 212451
URL: http://llvm.org/viewvc/llvm-project?rev=212451&view=rev
Log:
Move ChainedIncludesSource into the implementation
This doesn't need to be in the headers.
Removed:
cfe/trunk/include/clang/Frontend/ChainedIncludesSource.h
Modified:
cfe/trunk/include/clang/Frontend/Utils.h
cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp
cfe/trunk/lib/Frontend/FrontendAction.cpp
Removed: cfe/trunk/include/clang/Frontend/ChainedIncludesSource.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/ChainedIncludesSource.h?rev=212450&view=auto
==
--- cfe/trunk/include/clang/Frontend/ChainedIncludesSource.h (original)
+++ cfe/trunk/include/clang/Frontend/ChainedIncludesSource.h (removed)
@@ -1,75 +0,0 @@
-//===- ChainedIncludesSource.h - Chained PCHs in Memory -*- C++
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This file defines the ChainedIncludesSource class, which converts headers
-// to chained PCHs in memory, mainly used for testing.
-//
-//===--===//
-#ifndef LLVM_CLANG_SERIALIZATION_CHAINEDINCLUDESSOURCE_H
-#define LLVM_CLANG_SERIALIZATION_CHAINEDINCLUDESSOURCE_H
-
-#include "clang/Sema/ExternalSemaSource.h"
-#include
-
-namespace clang {
- class CompilerInstance;
-
-class ChainedIncludesSource : public ExternalSemaSource {
-public:
- virtual ~ChainedIncludesSource();
-
- static IntrusiveRefCntPtr create(CompilerInstance
&CI);
-
- ExternalSemaSource &getFinalReader() const { return *FinalReader; }
-
-private:
- std::vector CIs;
- IntrusiveRefCntPtr FinalReader;
-
-
-protected:
-
-//===--===//
-// ExternalASTSource interface.
-//===--===//
-
- Decl *GetExternalDecl(uint32_t ID) override;
- Selector GetExternalSelector(uint32_t ID) override;
- uint32_t GetNumExternalSelectors() override;
- Stmt *GetExternalDeclStmt(uint64_t Offset) override;
- CXXBaseSpecifier *GetExternalCXXBaseSpecifiers(uint64_t Offset) override;
- bool FindExternalVisibleDeclsByName(const DeclContext *DC,
- DeclarationName Name) override;
- ExternalLoadResult FindExternalLexicalDecls(const DeclContext *DC,
-bool (*isKindWeWant)(Decl::Kind),
-SmallVectorImpl &Result) override;
- void CompleteType(TagDecl *Tag) override;
- void CompleteType(ObjCInterfaceDecl *Class) override;
- void StartedDeserializing() override;
- void FinishedDeserializing() override;
- void StartTranslationUnit(ASTConsumer *Consumer) override;
- void PrintStats() override;
-
- /// Return the amount of memory used by memory buffers, breaking down
- /// by heap-backed versus mmap'ed memory.
- void getMemoryBufferSizes(MemoryBufferSizes &sizes) const override;
-
-//===--===//
-// ExternalSemaSource interface.
-//===--===//
-
- void InitializeSema(Sema &S) override;
- void ForgetSema() override;
- void ReadMethodPool(Selector Sel) override;
- bool LookupUnqualified(LookupResult &R, Scope *S) override;
-};
-
-}
-
-#endif
Modified: cfe/trunk/include/clang/Frontend/Utils.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/Utils.h?rev=212451&r1=212450&r2=212451&view=diff
==
--- cfe/trunk/include/clang/Frontend/Utils.h (original)
+++ cfe/trunk/include/clang/Frontend/Utils.h Mon Jul 7 06:07:10 2014
@@ -39,6 +39,7 @@ class Decl;
class DependencyOutputOptions;
class DiagnosticsEngine;
class DiagnosticOptions;
+class ExternalSemaSource;
class FileManager;
class HeaderSearch;
class HeaderSearchOptions;
@@ -162,6 +163,12 @@ void AttachHeaderIncludeGen(Preprocessor
/// a seekable stream.
void CacheTokens(Preprocessor &PP, llvm::raw_fd_ostream* OS);
+/// The ChainedIncludesSource class converts headers to chained PCHs in
+/// memory, mainly for testing.
+IntrusiveRefCntPtr
+createChainedIncludesSource(CompilerInstance &CI,
+IntrusiveRefCntPtr &Reader);
+
/// createInvocationFromCommandLine - Construct a compiler invocation object
for
/// a command line argument vector.
///
Modified: cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp?rev=212451&r1=212450&r2=212451&view=diff
=
r212450 - ChainedIncludesSource: avoid copying n*(n+1)/2 file contents into memory
Author: alp
Date: Mon Jul 7 06:06:51 2014
New Revision: 212450
URL: http://llvm.org/viewvc/llvm-project?rev=212450&view=rev
Log:
ChainedIncludesSource: avoid copying n*(n+1)/2 file contents into memory
Just reference the data instead with shallow MemoryBuffer instances.
Modified:
cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp
Modified: cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp?rev=212450&r1=212449&r2=212450&view=diff
==
--- cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp (original)
+++ cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp Mon Jul 7 06:06:51 2014
@@ -126,17 +126,14 @@ ChainedIncludesSource::create(CompilerIn
} else {
assert(!serialBufs.empty());
SmallVector bufs;
- for (unsigned si = 0, se = serialBufs.size(); si != se; ++si) {
-bufs.push_back(llvm::MemoryBuffer::getMemBufferCopy(
- StringRef(serialBufs[si]->getBufferStart(),
-
serialBufs[si]->getBufferSize(;
- }
+ // TODO: Pass through the existing MemoryBuffer instances instead of
+ // allocating new ones.
+ for (auto *SB : serialBufs)
+bufs.push_back(llvm::MemoryBuffer::getMemBuffer(SB->getBuffer()));
std::string pchName = includes[i-1];
llvm::raw_string_ostream os(pchName);
os << ".pch" << i-1;
- os.flush();
-
- serialBufNames.push_back(pchName);
+ serialBufNames.push_back(os.str());
IntrusiveRefCntPtr Reader;
Reader = createASTReader(*Clang, pchName, bufs, serialBufNames,
@@ -151,11 +148,8 @@ ChainedIncludesSource::create(CompilerIn
return nullptr;
ParseAST(Clang->getSema());
-OS.flush();
Clang->getDiagnosticClient().EndSourceFile();
-serialBufs.push_back(
- llvm::MemoryBuffer::getMemBufferCopy(StringRef(serialAST.data(),
- serialAST.size(;
+serialBufs.push_back(llvm::MemoryBuffer::getMemBufferCopy(OS.str()));
source->CIs.push_back(Clang.release());
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212447 - PointerLoc does not exist anymore.
Author: yrnkrn
Date: Mon Jul 7 04:52:31 2014
New Revision: 212447
URL: http://llvm.org/viewvc/llvm-project?rev=212447&view=rev
Log:
PointerLoc does not exist anymore.
SourceLocation is available from TypeLoc member functions.
Modified:
cfe/trunk/include/clang/AST/Decl.h
Modified: cfe/trunk/include/clang/AST/Decl.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=212447&r1=212446&r2=212447&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Mon Jul 7 04:52:31 2014
@@ -52,8 +52,7 @@ class VarTemplateDecl;
/// A client can read the relevant info using TypeLoc wrappers, e.g:
/// @code
/// TypeLoc TL = TypeSourceInfo->getTypeLoc();
-/// if (PointerLoc *PL = dyn_cast(&TL))
-/// PL->getStarLoc().print(OS, SrcMgr);
+/// TL.getStartLoc().print(OS, SrcMgr);
/// @endcode
///
class TypeSourceInfo {
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r212446 - Revert "Add lib/Codgen/[CGRTTI|MicrosoftRTTI].cpp to CMakeLists.txt (r212445)"
Author: grosser Date: Mon Jul 7 04:39:09 2014 New Revision: 212446 URL: http://llvm.org/viewvc/llvm-project?rev=212446&view=rev Log: Revert "Add lib/Codgen/[CGRTTI|MicrosoftRTTI].cpp to CMakeLists.txt (r212445)" I misidentified the problem and did not test suffifiently. The files had correctly been removed, but for some reason they still remained in my git checkout. Not adding the files back to CMakeLists.txt, but rather removing the stale files was the solution. Sorry for the unnecessary noise. Modified: cfe/trunk/lib/CodeGen/CMakeLists.txt Modified: cfe/trunk/lib/CodeGen/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CMakeLists.txt?rev=212446&r1=212445&r2=212446&view=diff == --- cfe/trunk/lib/CodeGen/CMakeLists.txt (original) +++ cfe/trunk/lib/CodeGen/CMakeLists.txt Mon Jul 7 04:39:09 2014 @@ -46,7 +46,6 @@ add_clang_library(clangCodeGen CGOpenCLRuntime.cpp CGOpenMPRuntime.cpp CGRecordLayoutBuilder.cpp - CGRTTI.cpp CGStmt.cpp CGStmtOpenMP.cpp CGVTT.cpp @@ -60,7 +59,6 @@ add_clang_library(clangCodeGen CodeGenTypes.cpp ItaniumCXXABI.cpp MicrosoftCXXABI.cpp - MicrosoftRTTI.cpp ModuleBuilder.cpp TargetInfo.cpp ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
